DORA Compliance Mapping¶
MazeVault Alignment with Digital Operational Resilience Act (EU 2022/2554)
Document ID: MV-LEG-021
Version: 1.0.0
Classification: Internal
Owner: Chief Information Security Officer (CISO)
Last Updated: 2026-05-01
Review Cycle: Annual
Approved By: CEO / Board of Directors
1. Regulatory Overview¶
1.1 Digital Operational Resilience Act (DORA)¶
Regulation (EU) 2022/2554 — the Digital Operational Resilience Act ("DORA") — establishes a comprehensive framework for the management of information and communication technology (ICT) risk in the financial sector. DORA entered into application on 17 January 2025 and directly applies across all EU Member States without national transposition.
Key regulatory parameters:
| Aspect | Description |
|---|---|
| Legal basis | Regulation (EU) 2022/2554 of 14 December 2022 |
| Application date | 17 January 2025 |
| Scope | 21 types of financial entities + ICT third-party service providers |
| Supervisory authorities | EBA, ESMA, EIOPA (jointly via Joint Committee); national competent authorities |
| Lead Overseer | Designated by ESAs for Critical Third-Party Providers (CTPPs) |
| Delegated/Implementing Acts | RTS and ITS adopted by European Commission based on ESA drafts |
| Penalties | Determined by national competent authorities; periodic penalty payments for CTPPs |
| Cross-references | NIS2 (2022/2555), GDPR (2016/679), MiFID II, PSD2, Solvency II |
1.2 Entities in Scope¶
DORA applies to 21 categories of financial entities, including:
- Credit institutions (banks)
- Payment institutions
- Account information service providers
- Electronic money institutions
- Investment firms
- Crypto-asset service providers
- Central securities depositories
- Central counterparties
- Trading venues
- Trade repositories
- Managers of alternative investment funds (AIFMs)
- Management companies (UCITS)
- Data reporting service providers
- Insurance and reinsurance undertakings
- Insurance intermediaries
- Institutions for occupational retirement provision
- Credit rating agencies
- Administrators of critical benchmarks
- Crowdfunding service providers
- Securitisation repositories
- ICT third-party service providers (designated as critical — CTPPs)
1.3 Regulatory Architecture¶
DORA is structured in five substantive chapters:
| Chapter | Title | Articles | Key Requirements |
|---|---|---|---|
| II | ICT Risk Management | Art. 5-16 | Comprehensive ICT risk management framework |
| III | ICT-related Incident Management | Art. 17-23 | Incident classification, management, and reporting |
| IV | Digital Operational Resilience Testing | Art. 24-27 | Testing programme including TLPT |
| V | ICT Third-party Risk | Art. 28-44 | Third-party oversight framework |
| VI | Information Sharing | Art. 45 | Voluntary threat intelligence sharing |
1.4 Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS)¶
The following delegated and implementing regulations supplement DORA:
- RTS on ICT risk management framework (Commission Delegated Regulation 2024/1774)
- RTS on classification of ICT-related incidents (Commission Delegated Regulation 2024/1772)
- ITS on reporting of major ICT-related incidents (Commission Implementing Regulation 2024/1773)
- RTS on subcontracting ICT services (Commission Delegated Regulation 2024/1775)
- RTS on TLPT (Commission Delegated Regulation 2024/1776)
- RTS on criteria for CTPP designation (Commission Delegated Regulation 2024/1777)
- ITS on register of information (Commission Implementing Regulation 2024/1778)
2. MazeVault's DORA Position¶
2.1 Classification¶
MazeVault is classified as an ICT third-party service provider under DORA Article 3(21):
"ICT third-party service provider means an undertaking providing ICT services"
MazeVault's services qualifying as ICT services under DORA:
| Service | DORA Relevance | Criticality |
|---|---|---|
| Certificate lifecycle management | ICT service supporting authentication and encryption infrastructure | Important/Critical (customer-dependent) |
| Secrets management | ICT service managing cryptographic materials and credentials | Critical |
| PKI services (CA, OCSP) | ICT service providing trust infrastructure | Critical |
| Key management (HSM integration) | ICT service managing cryptographic key lifecycle | Critical |
| MazeVault Agent | ICT service deployed on customer infrastructure | Important |
| MazeVault Gateway | ICT service enabling connectivity and certificate distribution | Important |
2.2 CTPP Designation Assessment¶
MazeVault is not currently designated as a Critical Third-Party Provider (CTPP) by the ESAs. The criteria for CTPP designation under Article 31 include:
- Systemic importance to financial entities
- Degree of substitutability
- Degree of reliance by financial entities
- Number and type of financial entities served
MazeVault's assessment: Below CTPP designation thresholds. However, MazeVault maintains readiness for potential future designation and voluntarily implements controls aligned with CTPP oversight expectations.
2.3 Contractual Position¶
MazeVault's obligations under DORA arise primarily through contractual requirements imposed by financial entity customers pursuant to Chapter V (Articles 28-30). Financial entities must:
- Adopt and regularly review an ICT third-party risk strategy
- Maintain a register of information on all ICT third-party arrangements
- Ensure contractual provisions meet Article 30 requirements
- Conduct due diligence before and during engagement
- Report to competent authorities on third-party arrangements
MazeVault's contractual framework is designed to satisfy all Article 30 requirements without requiring customer-specific negotiation of standard security provisions.
3. Chapter II — ICT Risk Management (Articles 5-16)¶
3.1 Mapping Table¶
| Article | Requirement | MazeVault Implementation | Evidence |
|---|---|---|---|
| Art. 5 — Governance and organisation | Management body defines, approves, oversees ICT risk management framework. Appropriate independence of control functions. | CISO role with direct CEO reporting. Board approval of ISP (MV-LEG-001). Separation between development and security oversight. Risk committee governance. | Board approval records, CISO appointment, organizational chart, risk committee minutes |
| Art. 6 — ICT risk management framework | Comprehensive, documented ICT risk management framework. Strategies, policies, procedures, tools. At least annual review. | Complete ISMS: Information Security Policy (MV-LEG-001), Risk Management Policy (MV-LEG-002), 10+ subordinate policies. Annual review cycle. ComplianceReportService for continuous monitoring. | Policy library, annual review records, compliance reports, ISMS scope documentation |
| Art. 7 — ICT systems, protocols and tools | Use and maintain updated ICT systems, protocols and tools. Appropriate to scope and complexity. | SSDLC with security gates. Per-build vulnerability scanning (Trivy, govulncheck). Patching SLAs (Critical ≤48h). Automated dependency updates. Container image lifecycle management. | CI/CD pipeline configuration, vulnerability scan results, patching records, update logs |
| Art. 8 — Identification | Identify, classify, document all ICT assets. Map interconnections. Identify dependencies. At least annual review. | database_health.go ExpectedTables for system asset identification. Configuration management. Service dependency mapping. Data flow documentation. Asset classification per MV-LEG-005. | Asset inventory, dependency maps, data flow diagrams, configuration database, annual review records |
| Art. 9 — Protection and prevention | Implement ICT security policies, procedures, tools. Access control, authentication, encryption. | RBAC (8 roles, 50+ permissions). MFA enforcement. AES-256-GCM encryption. TLS 1.2+ mandatory. HSM integration. Network segmentation. Security headers. Input validation. | Access Control Policy (MV-LEG-003), Cryptography Policy (MV-LEG-004), TLS configuration, HSM audit logs, permission matrix |
| Art. 10 — Detection | Mechanisms to detect anomalous activities. Multiple layers of control. | AnomalyDetectionService with behavioral analysis and ML-based pattern detection. 17 SIEM-ready detection rules. Prometheus alerting (CPU, memory, latency, error rate). Chain-hashed audit log monitoring. Real-time dashboards. | SIEM rule configuration, Prometheus alert rules, anomaly detection logs, dashboard configuration, alert history |
| Art. 11 — Response and recovery | ICT business continuity policy. BCP and DRP. Response and recovery procedures. | BCP/DRP (MV-LEG-008). Multi-datacenter deployment. Gateway failover (active/passive). Database replication. Automated failover procedures. Defined RTO/RPO targets. Backup and restore automation. | BCP/DRP document, failover test results, DR exercise reports, RTO/RPO measurement records, backup verification logs |
| Art. 12 — Backup policies | Backup and restoration policies. Scope, frequency, methods for backup. Separation from primary. Periodic testing. | Daily full PostgreSQL backups. 15-minute transaction log backups. Encryption key backup to secondary HSM. Vault configuration daily backup. Geographically separated backup storage. Encrypted backup data. Monthly restoration testing. | Backup policy, backup execution logs, restoration test results, geographic separation documentation |
| Art. 13 — Learning and evolving | Post-incident review. Lessons learned. Knowledge sharing. Framework updates based on incidents and testing. | Mandatory post-incident review for all P1/P2 incidents. Lessons learned documentation. Policy updates triggered by findings. Security architecture review after significant incidents. Knowledge base maintenance. | Post-incident reports, lesson learned documents, policy change history, knowledge base entries |
| Art. 14 — Communication | Crisis communication plans. Internal and external communication procedures. Designated spokesperson. | Incident communication procedures in IRP (MV-LEG-007). Designated communication channels per severity. Customer notification procedures. Regulatory authority communication workflow. External communication approval process. | Communication plan, notification templates, contact lists, communication logs |
| Art. 15 — Further harmonisation of ICT risk management tools, methods, processes and policies | Application of RTS on ICT risk management framework details. | Implementation aligned with Commission Delegated Regulation 2024/1774 requirements for ICT risk management framework elements. | RTS compliance checklist, gap analysis documentation |
| Art. 16 — Simplified ICT risk management framework | Proportionate framework for entities meeting Art. 16(1) criteria. | Not applicable. MazeVault implements the full ICT risk management framework, exceeding simplified requirements. All financial entity customers benefit from full framework implementation regardless of their own proportionality assessment. | N/A (full framework documented) |
3.2 ICT Risk Management Framework Components¶
MazeVault's ICT risk management framework consists of:
┌─────────────────────────────────────────────────────────┐
│ GOVERNANCE & OVERSIGHT │
│ Board Approval │ CISO Ownership │ Risk Committee │
├─────────────────────────────────────────────────────────┤
│ POLICIES & STANDARDS │
│ ISP (MV-LEG-001) │ Risk Policy │ 10+ Sub-policies │
├─────────────────────────────────────────────────────────┤
│ TECHNICAL CONTROLS │
│ 5-Layer Security Architecture │
│ Network → Application → AuthN → AuthZ → Data │
├─────────────────────────────────────────────────────────┤
│ OPERATIONAL PROCESSES │
│ Monitoring │ Incident Response │ Change Management │
├─────────────────────────────────────────────────────────┤
│ CONTINUOUS IMPROVEMENT │
│ Risk Reviews │ Audit │ Testing │ Lessons Learned │
└─────────────────────────────────────────────────────────┘
4. Chapter III — ICT-related Incident Management (Articles 17-23)¶
4.1 Mapping Table¶
| Article | Requirement | MazeVault Implementation | Evidence |
|---|---|---|---|
| Art. 17 — ICT-related incident management process | Define, establish, and implement ICT-related incident management process. Early warning indicators. Classification. Response procedures. | IncidentService implementing full incident lifecycle: Detection → Triage → Classification → Containment → Eradication → Recovery → Post-incident review. Defined response times per severity (P1: ≤15 min, P2: ≤1h, P3: ≤4h, P4: ≤24h). | Incident Response Plan (MV-LEG-007), IncidentService implementation, incident records, response time metrics |
| Art. 18 — Classification of ICT-related incidents and cyber threats | Classify based on: affected clients, data loss, geographic spread, duration, economic impact, criticality. Significant cyber threats classified separately. | 4-tier severity classification (P1-P4). Multi-dimensional impact assessment: Confidentiality, Integrity, Availability, Scope, Duration, Economic impact. CVSS scoring for vulnerability-related incidents. Threat classification per MITRE ATT&CK. | Classification matrix, incident records with classification, CVSS assessments, threat intelligence reports |
| Art. 19 — Reporting of major ICT-related incidents and significant cyber threats | Report major incidents to competent authority: initial notification (4h from classification), intermediate report (72h), final report (1 month). | MazeVault enables customer reporting by: (1) Immediate internal detection and classification, (2) Customer notification within 4h of detecting customer-impacting incident, (3) Structured incident data aligned with ITS reporting format, (4) Timeline and evidence for customer's own regulatory report. | Customer notification logs, structured incident reports, timeline documentation, evidence packages |
| Art. 20 — Harmonised reporting content and templates | Report content per ITS templates: identification, classification, impact, root cause, resolution, lessons learned. | Incident reports structured per Commission Implementing Regulation 2024/1773 format. Fields include: incident ID, classification, affected systems, business impact, root cause, timeline, remediation. Customer receives pre-formatted evidence. | Incident report templates, completed reports, ITS field mapping documentation |
| Art. 23 — Operational or security payment-related incidents | Credit institutions, payment institutions: report operational/security payment incidents per PSD2. | MazeVault does not process payments. However, MazeVault's PKI/certificate services support the security of payment systems. MazeVault provides evidence to support customers' payment incident reporting where MazeVault services are a contributing factor. | N/A for direct reporting; supporting evidence available for customer payment incident reports |
4.2 Incident Classification Alignment with DORA Art. 18¶
Per Commission Delegated Regulation 2024/1772, incidents are classified as "major" based on:
| Classification Criterion | Threshold | MazeVault Measurement |
|---|---|---|
| Clients affected | >10% of clients or >100,000 clients | Customer notification triggers at any customer impact |
| Data integrity/confidentiality loss | Any confirmed loss of C/I | Immediate P1 classification for any data breach |
| Criticality of services affected | Critical or important functions | Certificate/secret management = critical by default |
| Economic impact | >€100,000 direct losses | Impact assessment in incident report |
| Duration of incident | >24 hours (or >2h for critical functions) | Real-time duration tracking in IncidentService |
| Geographical spread | >2 Member States | Scope assessment in incident classification |
4.3 MazeVault Notification Timeline¶
Incident Detection (T=0)
│
├── T+15 min: Internal triage and classification (P1)
│
├── T+1h: Containment initiated
│
├── T+4h: Customer notification (preliminary)
│ [Enables customer's 4h initial notification to authority]
│
├── T+12h: Detailed customer notification
│
├── T+48h: Intermediate report to customer
│ [Enables customer's 72h intermediate report]
│
├── T+14d: Final report to customer
│ [Enables customer's 1-month final report]
│
└── T+30d: Post-incident review completed
5. Chapter IV — Digital Operational Resilience Testing (Articles 24-27)¶
5.1 Mapping Table¶
| Article | Requirement | MazeVault Implementation | Evidence |
|---|---|---|---|
| Art. 24 — General requirements for digital operational resilience testing | Establish, maintain, review sound digital operational resilience testing programme. Proportionate to size and risk. | Comprehensive testing programme: continuous automated scanning, periodic manual testing, annual penetration testing, DR exercises. Testing covers all critical ICT systems supporting certificate/secret management. | Testing programme documentation, test schedule, test results archive |
| Art. 25 — Testing of ICT tools and systems | Range of tests: vulnerability assessments, open source analyses, network security, gap analyses, physical security reviews, scanning, source code reviews, scenario-based tests, compatibility, performance, end-to-end testing. | Vulnerability assessments: govulncheck (Go), Trivy (containers), npm audit (Node.js). Open source analysis: SBOM generation (CycloneDX), license compliance. Network security: TLS scanning, port analysis. Source code reviews: mandatory PR code review, SAST. Scenario-based tests: integration testing, chaos engineering. Performance testing: load testing, stress testing. End-to-end testing: automated E2E test suites. | Scan reports, SBOM, TLS test results, PR review records, test suite results, performance test reports |
| Art. 26 — Advanced testing of ICT tools, systems and processes based on TLPT | Threat-led penetration testing (TLPT) for significant financial entities. ICT third-party providers may be included in scope. At least every 3 years. | MazeVault supports and cooperates with customer TLPT engagements: (1) Provides scoping information for threat intelligence phase, (2) Enables controlled testing against MazeVault components, (3) Provides log access during red team exercises, (4) Participates in post-TLPT remediation. MazeVault does not unilaterally conduct TLPT but cooperates when customers include MazeVault in their TLPT scope. | TLPT cooperation records, scoping documentation, log provision records, remediation evidence |
| Art. 27 — Requirements for testers | External testers: highest suitability and reputability. Expertise in threat intelligence, penetration testing, red team testing. Professional certifications. Covered by professional indemnity insurance. | MazeVault's annual penetration test conducted by qualified third-party firm meeting Art. 27 criteria: CREST/OSCP certified testers, professional indemnity insurance, established reputation, independence confirmed. | Tester qualification documentation, certifications, insurance certificates, engagement contracts |
5.2 Testing Programme Overview¶
| Test Type | Tool/Method | Frequency | Scope | Standard |
|---|---|---|---|---|
| Container vulnerability scan | Trivy | Per build (continuous) | All container images | CVE database |
| Go dependency scan | govulncheck | Per build (continuous) | All Go dependencies | Go vulnerability DB |
| Frontend dependency scan | npm audit | Per build (continuous) | All Node.js dependencies | npm advisory DB |
| SAST (static analysis) | Go vet, staticcheck, ESLint | Per build (continuous) | All source code | Language-specific rules |
| SBOM generation | CycloneDX | Per release | Complete software inventory | CycloneDX 1.5 |
| TLS configuration scan | testssl.sh / SSL Labs | Monthly | All external endpoints | Mozilla TLS guidelines |
| Penetration test | Third-party firm | Annual (Q4) | Full scope (network, application, API) | OWASP, PTES |
| DR exercise | Internal team | Annual | Full failover and recovery | BCP/DRP procedures |
| Backup restoration test | Automated + manual | Monthly | All backup types | Backup policy |
| Incident response exercise | Tabletop | Annual | All severity levels | IRP procedures |
| Red team / TLPT (customer) | Customer-directed | Per customer requirement | As scoped by customer | TIBER-EU / DORA RTS |
5.3 TLPT Cooperation Framework¶
When a financial entity customer includes MazeVault in their TLPT scope (per Art. 26):
- Scoping phase: MazeVault provides system architecture information, attack surface documentation, and API specifications to the threat intelligence provider
- Testing phase: MazeVault provides a controlled testing environment or coordinates live testing with appropriate safeguards
- Detection validation: MazeVault's detection capabilities (AnomalyDetectionService, SIEM rules) are tested without advance notice to SOC personnel
- Evidence phase: Full log access provided to TLPT team for timeline reconstruction
- Remediation phase: Findings incorporated into vulnerability management process with agreed remediation timelines
- Reporting phase: MazeVault contributes to purple team report and joint remediation plan
6. Chapter V — ICT Third-party Risk (Articles 28-44)¶
6.1 Overview¶
Chapter V is the most directly applicable DORA chapter for MazeVault's relationship with financial entity customers. It establishes:
- Principles for managing ICT third-party risk (Art. 28)
- Preliminary assessment and ongoing due diligence requirements (Art. 29)
- Mandatory contractual provisions (Art. 30)
- Oversight framework for CTPPs (Art. 31-44)
6.2 Article 28 — General Principles¶
| Requirement | MazeVault Response |
|---|---|
| Financial entity remains fully responsible for compliance | MazeVault acknowledges customer's ultimate responsibility; provides tools and evidence to support compliance |
| ICT third-party risk strategy at entity level | MazeVault supports customer strategy by providing comprehensive risk documentation |
| Register of information on all contractual arrangements | MazeVault provides all information needed for customer's register (see Section 7) |
| Proportionate management of ICT concentration risk | MazeVault supports multi-deployment options (on-prem, Azure, hybrid) to reduce concentration |
| Due diligence prior to and throughout engagement | Full documentation package available; ongoing compliance evidence provided |
6.3 Article 29 — Preliminary Assessment¶
MazeVault provides the following for customer's preliminary assessment:
| Assessment Dimension | Documentation/Evidence Provided |
|---|---|
| Appropriateness of the provider | Service capability documentation, customer references, track record |
| Potential risks (operational, legal, regulatory) | Risk assessment documentation, regulatory compliance mapping (this document) |
| Provider's ability to ensure continuity | BCP/DRP (MV-LEG-008), DR test results, architecture redundancy documentation |
| Quality of security measures | ISO 27001 aligned ISMS, penetration test results, vulnerability scan reports |
| Substitutability assessment | Standard protocols, data portability, documented APIs, exit strategy |
| Data protection compliance | DPA, GDPR compliance report, privacy impact assessment |
| Location of data processing | EU-based processing, customer-controlled data residency |
| Subcontracting arrangements | Subprocessor list, subprocessor governance documentation |
| Provider's financial position | Company registration, financial stability indicators |
| Compliance with regulatory requirements | This DORA compliance mapping, NIS2 compliance mapping (MV-LEG-020) |
6.4 Article 30 — Key Contractual Provisions¶
Article 30 mandates specific provisions in contracts between financial entities and ICT third-party providers. MazeVault's contractual framework addresses each requirement:
6.4.1 Art. 30(2) — General Provisions (All ICT Services)¶
| Art. 30(2) Requirement | MazeVault Contractual Provision | Document Reference |
|---|---|---|
| (a) Clear and complete description of all functions and ICT services | Detailed service description including: certificate lifecycle management, secrets management, PKI services, agent deployment, gateway operation, OCSP responder. Specifies criticality classification. | Service Schedule (Annex A to Master Agreement) |
| (b) Locations where contracted/subcontracted functions will be provided and data processed | EU-based processing. Specific locations documented: primary Azure region (EU), disaster recovery region (EU). Customer on-premise option. Subprocessor locations disclosed. | Data Processing Agreement §4, Subprocessor List |
| (c) Provisions on availability, authenticity, integrity, confidentiality of data | AES-256-GCM encryption (confidentiality/integrity). Chain-hashed audit logs (authenticity/integrity). Multi-DC availability architecture. SLA uptime targets. | Security Annex §3, SLA §2 |
| (d) Provisions on ensuring access, recovery and return of data | Data export in standard formats (JSON, PEM, PKCS#12). API-based bulk export. Secure deletion confirmation. Transition assistance period. | Exit Strategy Annex, DPA §7 |
| (e) Service level descriptions including quantitative and qualitative targets | Uptime SLA (99.9% minimum). Response time SLAs. Incident notification SLA (≤4h). Vulnerability remediation SLAs. Performance metrics. | SLA document (comprehensive metrics) |
| (f) Assistance in case of ICT incident at no additional cost | Incident notification, evidence provision, forensic cooperation, timeline reporting — all included in base service. No additional charges for incident response cooperation. | Security Annex §6, Incident Response provisions |
| (g) Obligation to cooperate with competent authorities | Full cooperation with NÚKIB (Czech), CNB, ECB, EBA, and other competent authorities. No restriction on regulator access to information about MazeVault's services. | Master Agreement §12, Regulatory Cooperation clause |
| (h) Termination rights | Customer may terminate with cause (material breach, security incident, regulatory order). Minimum 6-month notice for convenience termination. No lock-in beyond notice period. | Master Agreement §15, Termination provisions |
6.4.2 Art. 30(3) — Provisions for Critical/Important Functions¶
| Art. 30(3) Requirement | MazeVault Contractual Provision | Document Reference |
|---|---|---|
| (a) Full SLA with precise quantitative and qualitative targets | Comprehensive SLA: availability (99.9%), latency (p95 <500ms), incident response (P1: 15 min), certificate issuance (<5s), OCSP response (<200ms). Penalties for SLA breach. | SLA document with measurable KPIs |
| (b) Notice periods and reporting obligations | 30-day advance notice for material changes. Monthly operational reports. Quarterly compliance reports. Immediate notification of incidents and security events. | SLA §5 (Reporting), Security Annex §4 (Notification) |
| (c) ICT security requirements | Full security requirements per Security Annex: encryption standards, access control, vulnerability management, monitoring, incident response, testing, personnel security. | Security Annex (comprehensive) |
| (d) BCP and ICT disaster recovery testing | Annual BCP/DRP review. Annual DR test with results shared. Customer may observe DR exercises upon request. Notification of BCP/DRP material changes. | BCP/DRP Annex, DR Test Reports |
| (e) Participation in testing (including TLPT) | Unrestricted cooperation with customer's operational resilience testing programme. Support for TLPT engagements. Controlled testing environment available. Log access for red team exercises. | Testing Cooperation clause, TLPT cooperation framework |
| (f) Unrestricted audit and inspection rights | Right to audit with 30-day notice (routine) or immediate (cause). Physical or remote access. No cap on audit frequency (reasonable). Third-party auditor permitted. Full documentation access. | Audit Rights clause (Security Annex §5) |
| (g) Exit strategies | Comprehensive exit strategy: transition planning, data export, knowledge transfer, parallel run period, secure deletion, cooperation during transition. Minimum 6-month transition support. | Exit Strategy Annex |
6.4.3 Art. 30(4-5) — Subcontracting¶
| Requirement | MazeVault Provision |
|---|---|
| Right to object to subcontracting of critical functions | Yes. Customer has right to object to new subprocessors within 30 days of notification. |
| Prior consent for subcontracting critical/important functions | MazeVault obtains explicit consent before engaging subprocessors for critical service components. |
| Information on subcontractors | Complete subprocessor list provided: entity name, jurisdiction, service provided, criticality. |
| Same contractual requirements flow to subcontractors | Security requirements contractually flowed down to all subprocessors. |
| Notification of intended subcontracting changes | 30-day advance written notification of any subprocessor addition or change. |
6.5 Articles 31-44 — Oversight Framework (CTPP)¶
MazeVault is not currently designated as a Critical Third-Party Provider (CTPP). However, MazeVault maintains awareness of and preparedness for the oversight framework:
| Oversight Element | MazeVault Preparedness |
|---|---|
| Designation criteria monitoring | Annual self-assessment against Art. 31 criteria |
| Lead Overseer cooperation | Designated regulatory contact; cooperation procedures documented |
| Information provision | Capability to provide all information requested under Art. 37 |
| General investigations/inspections | Audit-ready documentation; regulatory cooperation policy |
| Recommendations compliance | Process for implementing oversight recommendations within prescribed timelines |
| Periodic penalty payments risk | Compliance management to avoid non-compliance triggering penalties |
7. Register of Information (Art. 28(3))¶
7.1 Overview¶
Financial entities must maintain a register of information on all contractual arrangements with ICT third-party providers (per Commission Implementing Regulation 2024/1778). MazeVault provides all information necessary for customer's register entry.
7.2 Information Provided for Customer's Register¶
| Register Field | MazeVault Information |
|---|---|
| Provider identification | MazeVault s.r.o., IČO: [registered], registered office: Czech Republic |
| LEI | [Legal Entity Identifier — available upon request] |
| Service description | Certificate lifecycle management, secrets management, PKI services (CA, OCSP), key management, agent-based certificate provisioning, gateway connectivity |
| Service classification | ICT service supporting security and cryptographic infrastructure |
| Criticality assessment | Customer-determined; MazeVault provides impact assessment inputs |
| Start date of arrangement | Per customer contract execution date |
| Contract duration | Per Master Agreement terms (typically annual renewal) |
| Notice period | 6 months (minimum) |
| Data processing locations | EU — specific Azure region per deployment; on-premise option at customer's location |
| Data storage locations | Same as processing locations (no separate storage jurisdictions) |
| Subcontracting | Subprocessor list provided (see Section 9) |
| Substitutability assessment | Standard APIs (ACME, EST, CMP); data exportable in standard formats; documented migration path |
| Reason for non-substitutability | N/A — MazeVault is designed for substitutability with documented exit procedures |
| Date of last audit | [Per audit schedule — annual minimum] |
| Contractual guarantees | Security Annex, DPA, SLA, Exit Strategy, Audit Rights, BCP/DRP provisions |
| Risk concentration | MazeVault supports multi-provider strategies; on-premise deployment eliminates cloud concentration |
7.3 Annual Register Update¶
MazeVault provides updated register information to customers: - Annually — proactive update of all register fields - Upon change — immediate notification of material changes (within 30 days of change) - Upon request — within 10 business days of customer request
8. Exit Strategy Provisions (Art. 28(8))¶
8.1 Regulatory Requirement¶
Article 28(8) requires financial entities to put in place exit strategies taking into account: - Risks arising from ICT third-party provider failure - Deterioration of quality of services - Business disruption from inappropriate or failed service transition - Limitation of understanding of risk from complex subcontracting chains
8.2 MazeVault Exit Strategy¶
MazeVault provides a comprehensive, documented exit strategy:
| Exit Phase | Duration | Activities | MazeVault Obligations |
|---|---|---|---|
| Notice | Month 0 | Customer provides termination notice (min. 6 months) | Acknowledge, initiate transition planning |
| Planning | Month 1-2 | Joint transition planning, successor provider identification | Provide migration documentation, API specifications, data schemas |
| Parallel run | Month 2-5 | Successor provider setup, data migration, testing | Continue full service, provide data exports, answer technical queries |
| Migration | Month 4-5 | Active data transfer, system cutover preparation | Export all data in standard formats, verify completeness, support testing |
| Cutover | Month 5-6 | Service transition to successor | Final data synchronization, service handoff, availability during cutover |
| Post-transition | Month 6+ (30 days) | Validation, issue resolution | Post-transition support, issue resolution, final data confirmation |
| Secure deletion | After confirmation | Permanent deletion of customer data | Cryptographic deletion, deletion certificate issued |
8.3 Data Portability¶
| Data Type | Export Format | Method |
|---|---|---|
| Certificates | PEM, DER, PKCS#12 | API bulk export, file download |
| Private keys (if MazeVault-managed) | PEM (encrypted), PKCS#12 | Secure export with customer encryption key |
| Secrets | JSON (encrypted) | API bulk export |
| Audit logs | JSON (with chain hashes) | API export, bulk file download |
| Configuration | JSON, YAML | API export |
| Certificate policies | JSON | API export |
| User/role data | JSON | API export |
8.4 Non-Interference¶
MazeVault guarantees: - No degradation of service quality during notice/transition period - No removal of access or features during transition - Continued security monitoring and incident response during transition - No additional charges for standard transition assistance - No data hostage scenarios — all customer data exportable at any time during contract term
9. Subcontracting Notification (Art. 29(2), Art. 30(4-5))¶
9.1 Subprocessor List¶
MazeVault maintains a current list of all subprocessors involved in service delivery:
| Subprocessor | Service Provided | Location | Criticality | Data Access |
|---|---|---|---|---|
| Microsoft Azure | Cloud infrastructure (compute, storage, networking) | EU (customer-selected region) | Critical | Infrastructure-level (encrypted data at rest) |
| Azure Key Vault | HSM-backed key management | EU (same region as deployment) | Critical | Key operations (no plaintext access to customer keys) |
| PostgreSQL (Azure-managed or customer-managed) | Database service | EU (same region as deployment) | Critical | Encrypted data storage |
| Container Registry | Container image storage | EU | Significant | MazeVault application images (no customer data) |
| CI/CD Platform | Build and deployment automation | EU/US (no customer data processed) | Standard | Source code, build artifacts (no customer data) |
Note: For on-premise deployments, cloud subprocessors may not apply. Customer infrastructure serves as the hosting platform under customer's own controls.
9.2 Notification Procedure¶
| Step | Timeline | Description |
|---|---|---|
| 1 | T-30 days | Written notification to customer of intended subprocessor change (addition, removal, or material modification) |
| 2 | T-30 to T-0 | Customer review period; customer may raise objection |
| 3 | If objection | MazeVault enters consultation; if unresolved, customer may terminate per contract |
| 4 | If no objection | Change proceeds at planned date |
| 5 | Post-change | Updated subprocessor list provided; register information updated |
9.3 Customer Rights¶
- Right to be informed: 30-day advance notification of all subprocessor changes
- Right to object: Written objection within 30-day notice period
- Right to terminate: If objection unresolved, customer may terminate without penalty
- Right to audit: Subprocessor audit rights flow through MazeVault's contracts
- Right to information: Updated subprocessor list available at all times upon request
10. Compliance Evidence¶
10.1 Evidence Catalogue¶
MazeVault provides the following evidence artifacts to support financial entity customers' DORA compliance:
| Category | Evidence Artifact | Frequency | Format | Purpose |
|---|---|---|---|---|
| ICT Risk Management | Risk Management Policy | On request | Art. 5-6 compliance | |
| ICT Risk Management | Risk register (relevant entries) | Quarterly summary | Art. 6 evidence | |
| ICT Risk Management | Compliance report (ISO 27001) | On request (API) | JSON/PDF | Framework alignment |
| ICT Risk Management | Compliance report (SOC 2) | On request (API) | JSON/PDF | Trust services criteria |
| Protection | Access control documentation | On request | Art. 9 evidence | |
| Protection | Encryption/key management documentation | On request | Art. 9 evidence | |
| Detection | SIEM rule documentation | On request | Art. 10 evidence | |
| Detection | Anomaly detection configuration | On request | Art. 10 evidence | |
| Testing | Annual penetration test report (executive summary) | Annual (Q4) | Art. 24-25 evidence | |
| Testing | Continuous vulnerability scan summary | Quarterly | Art. 25 evidence | |
| Testing | SBOM (CycloneDX) | Per release | XML/JSON | Art. 25 (open source analysis) |
| Incident Management | Incident Response Plan | On request | Art. 17 evidence | |
| Incident Management | Incident history (relevant to customer) | On request | PDF/JSON | Art. 17-19 evidence |
| Incident Management | Post-incident reports | Per incident | Art. 13, 17 evidence | |
| Continuity | BCP/DRP documentation | On request | Art. 11-12 evidence | |
| Continuity | DR test results | Annual | Art. 11-12 evidence | |
| Continuity | Backup verification results | Monthly summary | Art. 12 evidence | |
| Third-party Risk | Subprocessor list | On request / on change | Art. 29-30 evidence | |
| Third-party Risk | Subprocessor governance documentation | On request | Art. 29 evidence | |
| Audit | Audit log exports (customer-specific) | On request | JSON | Art. 30(3)(f) |
| Audit | Chain hash verification report | On request | Log integrity evidence |
10.2 Compliance Reporting API¶
MazeVault's ComplianceReportService provides automated compliance reports:
GET /api/v1/compliance/iso27001 → ISO 27001 control status
GET /api/v1/compliance/soc2 → SOC 2 trust services criteria
GET /api/v1/compliance/pci-dss → PCI DSS relevant controls
GET /api/v1/compliance/gdpr → GDPR compliance status
Each report includes: - Control implementation status (Implemented / Partially Implemented / Planned) - Evidence references - Last assessment date - Responsible owner - Remediation timeline (if applicable)
10.3 On-Demand Evidence Provision¶
- Standard requests: Evidence provided within 10 business days
- Urgent requests (regulatory examination): Evidence provided within 5 business days
- Incident-related requests: Evidence provided within 24 hours
- Audit support: Dedicated resource available during customer audits
11. Related Documents¶
| Document ID | Title | DORA Relevance |
|---|---|---|
| MV-LEG-001 | Information Security Policy | Art. 5-6 (ICT risk management framework) |
| MV-LEG-002 | Risk Management Policy | Art. 5-6 (risk governance) |
| MV-LEG-003 | Access Control Policy | Art. 9 (protection and prevention) |
| MV-LEG-004 | Cryptography Policy | Art. 9 (encryption, key management) |
| MV-LEG-005 | Data Classification & Retention Policy | Art. 8 (identification), Art. 12 (backup) |
| MV-LEG-007 | Incident Response Plan | Art. 17-19 (incident management) |
| MV-LEG-008 | Business Continuity & Disaster Recovery | Art. 11-12 (response, recovery, backup) |
| MV-LEG-009 | Logging & Monitoring Policy | Art. 10 (detection) |
| MV-LEG-010 | Vulnerability & Patch Management Policy | Art. 7 (systems maintenance), Art. 24-25 (testing) |
| MV-LEG-011 | Third-party Risk Management Policy | Art. 28-30 (ICT third-party risk) |
| MV-LEG-020 | NIS2 / Czech Cybersecurity Act Compliance | Complementary Czech national compliance |
Appendix A — DORA Article Cross-Reference Index¶
| Article | Title | Section in This Document |
|---|---|---|
| Art. 3(21) | ICT third-party service provider definition | §2.1 |
| Art. 5 | Governance and organisation | §3.1 |
| Art. 6 | ICT risk management framework | §3.1 |
| Art. 7 | ICT systems, protocols and tools | §3.1 |
| Art. 8 | Identification | §3.1 |
| Art. 9 | Protection and prevention | §3.1 |
| Art. 10 | Detection | §3.1 |
| Art. 11 | Response and recovery | §3.1 |
| Art. 12 | Backup policies | §3.1 |
| Art. 13 | Learning and evolving | §3.1 |
| Art. 14 | Communication | §3.1 |
| Art. 16 | Simplified ICT risk management framework | §3.1 |
| Art. 17 | ICT-related incident management process | §4.1 |
| Art. 18 | Classification of ICT-related incidents | §4.1, §4.2 |
| Art. 19 | Reporting major ICT-related incidents | §4.1 |
| Art. 20 | Harmonised reporting content | §4.1 |
| Art. 23 | Payment-related incidents | §4.1 |
| Art. 24 | General testing requirements | §5.1 |
| Art. 25 | Testing of ICT tools and systems | §5.1, §5.2 |
| Art. 26 | Advanced testing (TLPT) | §5.1, §5.3 |
| Art. 27 | Requirements for testers | §5.1 |
| Art. 28 | General principles (third-party risk) | §6.2 |
| Art. 29 | Preliminary assessment | §6.3 |
| Art. 30 | Key contractual provisions | §6.4 |
| Art. 31-44 | Oversight framework (CTPPs) | §6.5 |
| Art. 28(3) | Register of information | §7 |
| Art. 28(8) | Exit strategies | §8 |
Document Control¶
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0.0 | 2026-05-01 | CISO | Initial release |
This document is maintained by the MazeVault Information Security team and is subject to annual review. For questions regarding this document or DORA compliance matters, contact the CISO or the legal compliance team.