1. Introduction
The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022, complemented by an amending directive, Directive (EU) 2022/2556. It establishes a single, harmonised and comprehensive framework for the management of information and communication technology (ICT) risk across the European Union financial sector. DORA entered into force on 16 January 2023 and became directly applicable from 17 January 2025. Unlike a directive, DORA is a regulation, which means it applies directly in all EU Member States without the need for national transposition, ending the previously fragmented, sector-by-sector approach to operational resilience.
DORA rests on the recognition that a modern financial entity is, in effect, an ICT-dependent enterprise. A trading platform, a payment processor, a core banking ledger, an insurance policy administration system and the third-party cloud that hosts them are all now first-order sources of systemic risk. DORA therefore reframes operational resilience away from a purely capital-based or business-continuity lens and towards the continuous ability of a financial entity to build, assure and review its operational integrity by ensuring that it can withstand, respond to and recover from all types of ICT-related disruptions and threats.
This guide is written for two audiences at once: the auditor or assessor who must test compliance against DORA and its Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS), and the CISO, resilience lead and implementation team who must build and evidence the underlying capability. It enumerates every chapter, article family, technical standard and obligation, provides verification tables, and maps DORA to adjacent frameworks such as NIS2, the EBA ICT guidelines and ISO 27001.
Copyright and source note
DORA is EU legislation published in the Official Journal of the European Union. The consolidated legislative text and the associated RTS/ITS are Crown-of-the-Union public documents but are subject to EUR-Lex reuse terms. This guide is original CyberSigma commentary and interpretation. It paraphrases and summarises obligations for educational purposes and does not reproduce the copyrighted or official text of the Regulation, its delegated acts, or the European Supervisory Authorities' technical standards. Always work from the authoritative EUR-Lex text and the final adopted RTS/ITS when performing a formal assessment.
2. What is DORA
DORA is a lex specialis for digital operational resilience in EU financial services. It consolidates and elevates pre-existing supervisory expectations (for example the EBA Guidelines on ICT and security risk management and the EIOPA and ESMA equivalents) into binding, cross-sectoral law. Its central objective is to ensure that all participants in the financial system have the necessary safeguards in place to mitigate cyber-attacks and other ICT-related risks, and that the sector as a whole can maintain resilient operations through severe operational disruption.
The Regulation is built on five substantive pillars, each corresponding to a chapter of the legal text:
- ICT risk management (Chapter II) — a governance-anchored, proportionate risk-management framework covering identification, protection, detection, response, recovery, learning and communication.
- ICT-related incident management, classification and reporting (Chapter III) — a harmonised taxonomy for classifying incidents and mandatory reporting of major incidents and significant cyber threats to competent authorities.
- Digital operational resilience testing (Chapter IV) — a proportionate testing programme, culminating for significant entities in Threat-Led Penetration Testing (TLPT) aligned to the TIBER-EU framework.
- Managing of ICT third-party risk (Chapter V) — lifecycle management of ICT third-party service providers, contractual requirements, register of information, and an EU-level Oversight Framework for Critical ICT Third-Party Providers (CTPPs).
- Information and intelligence sharing (Chapter VI) — voluntary arrangements for exchanging cyber threat information and intelligence among financial entities.
DORA is deliberately principle-based at the level of the Regulation and prescriptive at the level of its technical standards. The European Supervisory Authorities (ESAs) — the EBA, EIOPA and ESMA, acting jointly through the Joint Committee — were mandated to develop a suite of RTS and ITS that operationalise the pillars, alongside Guidelines. These delegated instruments are where much of the auditable detail lives (for example the RTS on ICT risk management framework, the RTS on incident classification, and the ITS on the register of information).
3. Who must comply — scope of applicability
DORA has one of the broadest scopes of any EU financial regulation. Article 2 lists 20 categories of financial entity, plus ICT third-party service providers. Scope is entity-based, not activity-based, and there is no general de minimis exemption, although proportionality and a simplified ICT risk-management framework apply to smaller and less complex entities (Article 16).
| In-scope category | Notes on applicability |
|---|---|
| Credit institutions (banks) | Full scope; large significant institutions face TLPT and enhanced oversight expectations. |
| Payment institutions and account information service providers | Includes PSD2 firms; some exemptions for very small payment institutions. |
| Electronic money institutions | Full scope, including exempted e-money institutions in limited respects. |
| Investment firms | Full scope; simplified framework available for small and non-interconnected firms. |
| Crypto-asset service providers and issuers of asset-referenced tokens | Aligned with the Markets in Crypto-Assets Regulation (MiCA). |
| Central securities depositories (CSDs) | Full scope; systemically important, subject to testing. |
| Central counterparties (CCPs) | Full scope; systemic infrastructure. |
| Trading venues and data reporting service providers | Regulated markets, MTFs, OTFs, APAs, ARMs. |
| Trade repositories and securitisation repositories | Full scope. |
| Managers of alternative investment funds (AIFMs) and UCITS management companies | In scope; small AIFMs below thresholds may benefit from proportionality. |
| Insurance and reinsurance undertakings | Full scope; micro-enterprises and small insurers get proportionality relief. |
| Insurance intermediaries, reinsurance intermediaries and ancillary insurance intermediaries | In scope unless micro/small/medium enterprise carve-out applies. |
| Institutions for occupational retirement provision (IORPs) | In scope, with proportionality for schemes with few members. |
| Credit rating agencies | Full scope. |
| Administrators of critical benchmarks | Full scope. |
| Crowdfunding service providers | In scope. |
| ICT third-party service providers | Indirectly through contracts; CTPPs directly through the Oversight Framework. |
Explicitly excluded (Article 2(3)) are, among others, managers of alternative investment funds under the sub-threshold regime, certain insurance intermediaries that are micro/small/medium enterprises, some IORPs operating schemes with fewer than 15 members, natural persons, and post office giro institutions. Non-EU entities are captured to the extent they act as ICT third-party service providers to in-scope financial entities, and may be required to establish an EU subsidiary if designated a Critical ICT Third-Party Provider.
Proportionality — the simplified framework
Article 16 provides a simplified ICT risk-management framework for smaller and non-interconnected entities (for example small investment firms, small institutions, small payment/e-money institutions and certain intermediaries). These entities still must manage ICT risk, report major incidents and manage third-party risk, but with reduced granularity. The detail of the simplified framework is set out in a dedicated RTS. Proportionality never means exemption from the core obligations.
4. Structure of DORA
The Regulation comprises nine chapters and 64 articles. The substantive obligations concentrate in Chapters II to VI. The following table maps the chapters, their key article ranges and the associated technical standards.
| Chapter | Title / domain | Key articles | Associated RTS/ITS/Guidelines |
|---|---|---|---|
| I | General provisions (subject matter, scope, definitions, proportionality) | 1-4 | Definitions; proportionality principle. |
| II | ICT risk management | 5-16 | RTS on ICT risk management framework; RTS on simplified framework (Art 16). |
| III | ICT-related incident management, classification and reporting | 17-23 | RTS on classification of major incidents and significant cyber threats; RTS and ITS on content, format and templates for incident reporting. |
| IV | Digital operational resilience testing | 24-27 | RTS on Threat-Led Penetration Testing (TLPT), aligned to TIBER-EU. |
| V | Managing of ICT third-party risk | 28-44 | RTS on policy for ICT services supporting critical/important functions; ITS on register of information; RTS on subcontracting; RTS on Oversight harmonisation; RTS on Oversight fees. |
| VI | Information and intelligence sharing arrangements | 45 | Voluntary; no mandatory technical standard. |
| VII | Competent authorities | 46-56 | Supervisory powers, cooperation, administrative penalties. |
| VIII | Delegated acts | 57 | Empowerment to adopt delegated acts. |
| IX | Transitional and final provisions | 58-64 | Review clauses; entry into force; date of application. |
Within the pillars, DORA also defines a small number of cross-cutting concepts that recur throughout the assessment: critical or important function (CIF), ICT third-party service provider, ICT-related incident, major incident, significant cyber threat, digital operational resilience, and the register of information. Correct identification of critical or important functions is the single most consequential scoping judgement, because it drives testing intensity, third-party contractual rigour and reporting.
5. Master assessment checklist
This is the operative heart of the guide. It enumerates every obligation family across Chapters II to VI, grouped by article. For each group the table states what an auditor must verify and the typical evidence an implementer should have ready. Nothing is skipped.
5.1 Governance and organisation (Article 5)
| What to verify | Typical evidence |
|---|---|
| The management body has ultimate responsibility for ICT risk and has approved the ICT risk-management framework. | Board minutes, framework approval record, RACI, terms of reference. |
| Management body members maintain sufficient knowledge and skills, including through regular training, to understand and assess ICT risk. | Board training logs, competency matrix, attendance records. |
| Clear roles, responsibilities and reporting lines for all ICT functions are defined and documented. | Organisation chart, role descriptions, control function mandate. |
| The ICT risk-management framework is reviewed at least once a year and after major incidents or supervisory instructions. | Annual review sign-off, change history, post-incident review triggers. |
| An appropriate budget is allocated to ICT security awareness and digital operational resilience. | Budget approvals, resilience investment plan. |
5.2 ICT risk-management framework (Articles 6-8)
| What to verify | Typical evidence |
|---|---|
| A sound, comprehensive and well-documented ICT risk-management framework exists and is part of the overall risk-management system (Art 6). | ICT risk framework document, integration with ERM policy. |
| A digital resilience strategy sets out how the framework is implemented, including risk tolerance for ICT risk. | Digital operational resilience strategy, risk-appetite statement. |
| Systems, protocols and tools are appropriate, reliable, of sufficient capacity and technologically resilient (Art 7). | Architecture standards, capacity plans, technology lifecycle policy. |
| All ICT-supported business functions, information and ICT assets are identified, classified and documented; asset inventory is maintained (Art 8). | CMDB/asset register, information classification policy, data-flow maps. |
| ICT risk is identified continuously, including for legacy systems, and reassessed on major change; concentration and interdependency risks are mapped. | Risk register, change-triggered assessments, dependency maps. |
5.3 Protection and prevention (Article 9)
| What to verify | Typical evidence |
|---|---|
| ICT security policies, procedures, protocols and tools ensure resilience, continuity and availability, and preserve confidentiality, integrity and authenticity. | Information security policy suite, control standards. |
| Strong authentication mechanisms and protected cryptographic keys are in place; identity and access management follows least privilege. | IAM policy, MFA config, key-management procedure, access reviews. |
| Network and infrastructure segmentation, and secure configuration baselines, are implemented and maintained. | Network diagrams, hardening baselines, segmentation evidence. |
| Data and system change management, and patch/vulnerability management, are formalised. | Change tickets, patch SLAs, vulnerability scan reports. |
5.4 Detection (Article 10)
| What to verify | Typical evidence |
|---|---|
| Mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, are in place. | SIEM/monitoring architecture, detection use cases, alerting rules. |
| Multiple layers of control, defined alert thresholds and criteria to trigger incident detection and response are established. | Threshold definitions, runbooks, escalation matrix. |
| Detection covers user activity, error identification and reporting, including anomalies. | Log sources inventory, UEBA/log analytics reports. |
5.5 Response and recovery (Article 11)
| What to verify | Typical evidence |
|---|---|
| A comprehensive ICT business continuity policy is implemented, integrated with the overall BC framework. | ICT BCP, alignment with enterprise BCM policy. |
| Response and recovery plans specify RTOs and RPOs for each function, and are tested at least yearly and after major changes. | BC/DR plans with RTO/RPO, test schedule, test results. |
| Crisis communication plans enable responsible disclosure to clients, counterparties and the public where relevant. | Crisis communication procedure, stakeholder notification templates. |
| Backups and restoration are performed on data critical to functions, using segregated ICT capacity; restoration is tested. | Backup policy, restoration test logs, isolation evidence. |
| A crisis management function coordinates response; lessons learned feed back into the framework. | Crisis team charter, post-incident reviews, improvement register. |
5.6 Backup, restoration and secondary sites (Article 12)
| What to verify | Typical evidence |
|---|---|
| Backup policies and procedures define scope and frequency based on criticality and confidentiality of information. | Backup policy, criticality-based schedules. |
| Restoration and recovery procedures and methods are maintained; redundant ICT capacity exists where warranted. | DR runbooks, secondary-site design, redundancy evidence. |
| Where feasible, financial entities maintain a secondary processing site with adequate resources and geographic separation. | Secondary-site risk assessment, DC location analysis. |
5.7 Learning and evolving; communication (Articles 13-14)
| What to verify | Typical evidence |
|---|---|
| Capabilities and staff gather information on vulnerabilities, cyber threats and incidents, and perform post-incident reviews (Art 13). | Threat intelligence process, PIR reports, KPI trend analysis. |
| Findings from testing and real incidents are incorporated into the ICT risk-assessment process and awareness programmes. | Improvement backlog, updated risk assessments. |
| ICT security awareness and digital operational resilience training is mandatory for staff and, proportionately, senior management. | Training completion records, phishing simulation results. |
| Communication plans allow disclosure of major ICT-related incidents or vulnerabilities to clients, counterparties and public (Art 14). | Communication plan, designated spokesperson, disclosure log. |
5.8 Simplified ICT risk-management framework (Article 16)
| What to verify | Typical evidence |
|---|---|
| Entities eligible for the simplified regime nonetheless maintain a sound and documented ICT risk-management framework proportionate to their profile. | Simplified framework document, eligibility assessment. |
| Continuous monitoring, protection of information, business continuity and reporting obligations are met at proportionate depth. | Monitoring evidence, BCP, incident reports. |
5.9 Incident management process (Article 17)
| What to verify | Typical evidence |
|---|---|
| An ICT-related incident management process detects, manages and notifies incidents, with early warning indicators. | Incident management procedure, ticketing system, indicators list. |
| Roles and responsibilities for different incident scenarios and escalation are defined, including to management and, where relevant, authorities. | Escalation matrix, on-call roster, RACI. |
| All ICT-related incidents and significant cyber threats are recorded, and impact of major incidents on critical functions is analysed. | Incident register, root-cause analyses, impact assessments. |
5.10 Classification of incidents and cyber threats (Article 18)
| What to verify | Typical evidence |
|---|---|
| Incidents are classified against the RTS criteria: clients/counterparties and transactions affected, data losses, reputational impact, duration and service downtime, geographical spread, economic impact and criticality of services affected. | Classification methodology, worked classification examples. |
| Materiality thresholds for each criterion are applied to determine whether an incident is major. | Threshold matrix, classification decisions log. |
| Significant cyber threats are identified based on the criticality of services at risk and probability of materialisation. | Threat significance assessment, criteria mapping. |
5.11 Reporting of major incidents and threats (Articles 19-23)
| What to verify | Typical evidence |
|---|---|
| Major ICT-related incidents are reported to the competent authority using the harmonised templates and within the mandated deadlines (initial, intermediate, final). | Submitted reports, submission timestamps, acknowledgement receipts. |
| Initial notification is submitted without undue delay and no later than the regulatory deadline after classification as major; intermediate report follows within the required window; final report follows once root cause is analysed. | Timeline evidence: classification time vs submission time. |
| Affected clients are informed without undue delay where an incident impacts their financial interests. | Client notification records. |
| Significant cyber threats may be voluntarily notified to competent authorities (Art 19(2)). | Voluntary threat notifications, if any. |
| Reporting can be delegated to a third party but responsibility remains with the financial entity. | Outsourcing arrangement for reporting, oversight evidence. |
DORA incident reporting deadlines
Under the RTS/ITS on incident reporting, the harmonised deadlines are: an initial notification no later than 4 hours from the moment the incident is classified as major, and in any case no later than 24 hours from the moment the entity became aware of it; an intermediate report within 72 hours of the initial notification; and a final report no later than one month after the intermediate report. Aggregated reporting of recurring incidents applies where individually minor incidents cumulatively become major.
5.12 Digital operational resilience testing programme (Articles 24-25)
| What to verify | Typical evidence |
|---|---|
| A risk-based digital operational resilience testing programme is established, proportionate to size and risk profile (Art 24). | Testing strategy, annual test plan, proportionality rationale. |
| The programme includes a range of assessments: vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scenario-based tests, compatibility, performance and penetration testing (Art 25). | Test schedule covering each test type, scoping documents. |
| Tests are conducted by independent internal or external parties; conflicts of interest are managed. | Independence declarations, tester credentials, engagement letters. |
| All critical or important ICT systems and applications are tested at least yearly; identified vulnerabilities are remediated and re-tested. | Test coverage matrix, remediation tracker, re-test evidence. |
5.13 Advanced testing — Threat-Led Penetration Testing (Articles 26-27)
| What to verify | Typical evidence |
|---|---|
| Entities identified by authorities as significant carry out TLPT at least every three years, covering critical or important functions on live production systems. | TLPT scoping specification, competent-authority identification letter. |
| TLPT follows the TIBER-EU-aligned RTS: threat intelligence-led red-team testing with a control team, red team and (optionally) blue team purple-teaming. | TIBER/TLPT test plan, threat intelligence report, scope specification. |
| Testers meet the RTS requirements for suitability, independence and certification; where internal testers are used, external testers must be engaged at least every third test. | Tester accreditation, independence attestation, provider due diligence. |
| ICT third-party providers supporting tested functions are included in scope; pooled testing is used where multiple entities share providers. | Provider participation agreements, pooled-testing arrangements. |
| A valid attestation confirming the TLPT was performed in line with requirements is obtained and shared with the authority for mutual recognition. | TLPT attestation, remediation and closure report. |
5.14 General principles for third-party risk (Articles 28-30)
| What to verify | Typical evidence |
|---|---|
| ICT third-party risk is managed as an integral component of ICT risk, respecting the principle of full responsibility for compliance despite outsourcing (Art 28). | Third-party risk policy, accountability statement. |
| A strategy on ICT third-party risk, including a multi-vendor strategy where relevant, is adopted and reviewed. | TPRM strategy, concentration-risk analysis. |
| A register of information on all contractual arrangements for ICT services is maintained and made available to authorities on request; arrangements supporting critical/important functions are distinguished. | Register of information (ITS template), extract capability. |
| Before entering an arrangement, the entity assesses whether the function is critical/important, conducts due diligence, assesses concentration risk, and evaluates subcontracting chains (Art 29). | Pre-contract assessment, due-diligence pack, concentration analysis. |
| Concentration risk at entity and sector level, including reliance on non-substitutable providers, is assessed. | Substitutability and exit-difficulty analysis. |
5.15 Key contractual provisions (Article 30)
| What to verify | Typical evidence |
|---|---|
| All ICT contracts contain the baseline provisions: clear service description, locations of data processing, availability/integrity/confidentiality obligations, and data protection. | Executed contracts, clause-mapping matrix. |
| Contracts for services supporting critical/important functions additionally include: full service level descriptions with quantitative and qualitative targets, notice periods and reporting obligations, incident assistance, cooperation with authorities, exit strategies, access/audit/inspection rights, and business contingency/security requirements. | Enhanced contract addenda, audit-rights clauses, exit plans. |
| Termination rights exist for breach, supervisory impediment, evidenced weaknesses in ICT risk management, or breaches of law. | Termination clause review. |
| Documented, comprehensive and tested exit strategies exist for critical/important functions to enable transition without disruption. | Exit plans, transition test evidence. |
5.16 Oversight of Critical ICT Third-Party Providers (Articles 31-44)
| What to verify | Typical evidence |
|---|---|
| The entity understands whether any of its providers are designated Critical ICT Third-Party Providers (CTPPs) and how the EU Oversight Framework affects the relationship. | CTPP designation awareness, provider communications. |
| Recommendations issued by the Lead Overseer to a CTPP are tracked, and the entity considers ICT concentration risk arising from non-compliant CTPPs. | Lead Overseer recommendation tracking, contingency planning. |
| Where a CTPP does not comply and the risk is material, the entity is prepared to suspend or terminate the arrangement. | Contingency/termination readiness for CTPP dependencies. |
| Subcontracting of critical/important functions is governed per the RTS, including conditions and chain monitoring. | Subcontracting register, chain-monitoring evidence. |
5.17 Information and intelligence sharing (Article 45)
| What to verify | Typical evidence |
|---|---|
| Where the entity participates in threat intelligence sharing arrangements, these operate within trusted communities and protect sensitive information and personal data. | Sharing arrangement terms, membership records, data-protection safeguards. |
| Participation (or a decision not to participate) is notified to the competent authority as required. | Notification to authority, arrangement documentation. |
6. Scoping, materiality and tiering
DORA scoping proceeds in layers. First, entity scope is settled via Article 2 (are we an in-scope financial entity, and do we qualify for the Article 16 simplified regime?). Second, and most consequential, is the identification of critical or important functions (CIFs). A function is critical or important where a disruption would materially impair financial performance, soundness or continuity of services, or breach conditions of authorisation. CIF identification drives testing intensity, contractual rigour and the register of information.
Third, incident materiality is determined against the classification criteria in the RTS, using thresholds for clients affected, transactions affected, data losses, downtime, geographic spread, economic impact, reputational impact and criticality of services. Fourth, testing tiering determines whether an entity is designated for TLPT (significant entities identified by authorities based on impact, systemic character and ICT risk profile). Fifth, third-party tiering distinguishes ordinary providers from those supporting CIFs, and identifies dependence on CTPPs.
| Scoping dimension | Driver | Consequence |
|---|---|---|
| Entity scope | Article 2 categories; Article 16 eligibility | Full vs simplified framework. |
| Critical or important functions | Impact of disruption on financial soundness/continuity | Testing depth, contract Art 30(3) provisions, register entries. |
| Incident materiality | RTS classification criteria and thresholds | Mandatory reporting and deadlines. |
| Advanced testing | Authority designation of significant entities | 3-yearly TLPT obligation. |
| Third-party tiering | Whether provider supports a CIF; CTPP designation | Enhanced contracts, audit rights, exit plans, concentration control. |
7. Implementation approach
A DORA programme is best delivered in five phases. Each phase lists key activities and deliverables.
Phase 1 — Mobilise and assess (weeks 0-6)
- Activities: confirm entity scope and Article 16 eligibility; appoint accountable executive and programme lead; perform a DORA gap assessment against all five pillars and the RTS/ITS; baseline the ICT asset inventory.
- Deliverables: scoping memo, gap-assessment report with heat map, prioritised remediation backlog, programme charter and RACI.
Phase 2 — Govern and design (weeks 4-14)
- Activities: identify and formally document critical or important functions; draft/refresh the ICT risk-management framework and digital resilience strategy; secure board approval and training; define risk appetite for ICT risk.
- Deliverables: CIF register, approved ICT risk framework, resilience strategy, board training record, risk-appetite statement.
Phase 3 — Build controls (weeks 10-28)
- Activities: implement protection, detection, response and recovery controls (IAM, MFA, segmentation, SIEM, backup/DR with RTO/RPO); stand up the incident management process and classification methodology; build the reporting workflow and templates.
- Deliverables: control implementation evidence, incident runbooks, classification methodology, reporting playbook, BC/DR test plan.
Phase 4 — Third-party and testing (weeks 16-36)
- Activities: build the register of information; remediate contracts against Article 30 (especially CIF providers); design exit strategies; establish the testing programme; if designated, plan TLPT with a threat-intelligence provider and control team.
- Deliverables: register of information (ITS format), remediated contracts, exit plans, annual testing plan, TLPT scope specification.
Phase 5 — Operate, assure and improve (ongoing)
- Activities: run the annual framework review; conduct yearly resilience testing and periodic TLPT; report major incidents to deadline; monitor CTPP recommendations; feed lessons learned into the framework.
- Deliverables: annual review sign-off, test reports, incident reports, KPI dashboard, continuous-improvement register.
8. Maturity and capability model
DORA does not prescribe a formal maturity scale, but a five-level capability model is useful for tracking readiness and for supervisory conversations. Entities should target at least Level 4 (Managed) for critical or important functions.
| Level | Name | Characteristics | Typical DORA state |
|---|---|---|---|
| 1 | Initial | Ad hoc ICT risk activity; no documented framework; reactive incident handling. | Non-compliant; material findings across pillars. |
| 2 | Developing | Some policies exist; asset inventory incomplete; incident process informal. | Partial coverage; CIFs not formally identified. |
| 3 | Defined | Framework documented and board-approved; incidents classified; register started. | Structurally compliant; evidence gaps in testing and third-party. |
| 4 | Managed | Controls operating and measured; annual testing done; contracts remediated; reporting to deadline. | Substantively compliant; TLPT-ready if designated. |
| 5 | Optimising | Threat-led testing, intelligence sharing, continuous improvement; concentration risk actively managed. | Leading practice; resilient-by-design. |
9. Assessment and audit approach
- Confirm scope: validate entity category under Article 2 and whether the Article 16 simplified framework applies.
- Establish the CIF baseline: review and challenge the critical-or-important-function identification, as it drives most obligations.
- Test governance (Art 5): examine board approval, accountability, training and the annual review cycle.
- Assess the ICT risk-management framework (Arts 6-14): walk through identification, protection, detection, response, recovery, learning and communication with evidence sampling.
- Evaluate incident management (Arts 17-23): trace sample incidents through detection, classification, reporting and deadline adherence.
- Review the testing programme (Arts 24-27): confirm annual testing of critical systems and, for significant entities, TLPT scope, tester independence and attestation.
- Examine third-party management (Arts 28-44): inspect the register of information, contract clauses for CIF providers, exit strategies and concentration analysis.
- Assess intelligence sharing (Art 45) where applicable, including data-protection safeguards.
- Perform concentration and dependency analysis on CTPPs and non-substitutable providers.
- Report findings against each pillar, rate severity, agree remediation owners and dates, and schedule re-test of high-severity gaps.
10. Evidence request list
Assessors should request the following, organised by pillar.
- Governance: board minutes approving the ICT risk framework, RACI, board training records, annual review sign-offs.
- Risk management: ICT risk framework, digital resilience strategy, risk register, asset inventory/CMDB, information classification policy, data-flow diagrams.
- Protection: information security policy suite, IAM and MFA configuration, key-management procedure, hardening baselines, patch and vulnerability reports.
- Detection: SIEM/monitoring design, detection use cases, alert thresholds, log-source inventory.
- Response and recovery: ICT BCP, DR plans with RTO/RPO, backup policy, restoration test logs, crisis communication plan, post-incident reviews.
- Incident reporting: incident register, classification methodology, submitted regulatory reports with timestamps, client notification records.
- Testing: testing strategy and annual plan, test reports, remediation tracker, TLPT scope, threat-intelligence report, tester accreditations, TLPT attestation.
- Third-party: register of information (ITS format), executed contracts and Article 30 clause mapping, due-diligence packs, exit strategies, concentration analysis, subcontracting register.
- Intelligence sharing: sharing arrangement terms, membership records, authority notifications.
11. Roles and responsibilities
| Role | Primary DORA responsibilities |
|---|---|
| Management body / Board | Ultimate accountability; approve and review the ICT risk framework; maintain ICT risk knowledge; allocate resources. |
| Chief Information Security Officer / control function | Design and operate the ICT risk-management framework; oversee protection and detection; independent from ICT operations. |
| Head of ICT / Operations | Implement and maintain resilient systems, protocols and tools; execute change, patch and configuration management. |
| Business continuity / crisis manager | Own BC/DR plans, RTO/RPO, restoration testing and crisis coordination. |
| Incident response lead | Run detection, classification, escalation and regulatory reporting to deadline. |
| Third-party risk / procurement lead | Maintain the register of information; ensure Article 30 contract provisions and exit strategies; manage concentration and CTPP dependencies. |
| Testing lead / red-team coordinator | Run the testing programme; coordinate TLPT with the control team and threat-intelligence provider. |
| Internal audit | Provide independent assurance over the framework and evidence, respecting testing independence. |
| Data protection officer | Ensure incident and intelligence-sharing activities respect GDPR and data-protection safeguards. |
12. KPIs and metrics to track
- Percentage of critical or important functions with documented, tested BC/DR plans meeting agreed RTO/RPO.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for ICT-related incidents.
- Number of major incidents and percentage reported within the 4-hour / 24-hour / 72-hour / one-month deadlines.
- Percentage of critical ICT assets covered by annual resilience testing and vulnerability remediation SLA adherence.
- Percentage of ICT contracts (and CIF-supporting contracts) compliant with Article 30, and with tested exit strategies.
- Register of information completeness and freshness (last update date).
- Patch latency for critical vulnerabilities and MFA coverage across privileged accounts.
- Backup success rate and restoration test pass rate.
- Board training completion and staff security-awareness completion rates.
- Concentration metrics: share of CIFs dependent on a single provider or a CTPP; number of non-substitutable providers.
13. Readiness checklist
- Entity scope under Article 2 confirmed and Article 16 eligibility assessed.
- Critical or important functions formally identified, documented and board-endorsed.
- ICT risk-management framework and digital resilience strategy approved by the management body.
- Board and staff resilience/security training delivered and recorded.
- Asset inventory, information classification and dependency maps complete and current.
- Protection controls (IAM, MFA, segmentation, encryption, patching) implemented and evidenced.
- Detection and monitoring (SIEM, thresholds, alerting) operational for critical systems.
- BC/DR plans with RTO/RPO tested at least annually; backups isolated and restoration tested.
- Incident management process, classification methodology and reporting templates in place with deadline monitoring.
- Annual resilience testing programme running; TLPT planned if designated significant.
- Register of information maintained in ITS format and extractable on request.
- CIF-supporting contracts remediated to Article 30 with tested exit strategies.
- Concentration and CTPP dependency risks assessed and contingency-planned.
- Intelligence-sharing participation decision made and, where relevant, notified.
- Annual framework review scheduled with post-incident triggers.
14. Common gaps and findings
- Critical or important functions not formally identified, leaving testing scope and contract rigour under-specified.
- Register of information incomplete, inconsistent with the ITS template, or not extractable within supervisory timeframes.
- Contracts for CIF providers missing Article 30(3) provisions such as audit rights, incident assistance or exit strategies.
- Exit strategies documented but never tested, so transition feasibility is unproven.
- Incident classification methodology not aligned to the RTS criteria, causing under- or over-reporting.
- Reporting deadlines missed because classification-to-notification timing is not instrumented.
- BC/DR plans lacking function-specific RTO/RPO, or restoration never actually tested from backups.
- Board treated as informed rather than accountable; no evidence of ICT-risk training.
- Testing programme limited to vulnerability scans, with no gap analysis, scenario-based or penetration testing.
- Significant entities unprepared for TLPT — no control team, threat-intelligence provider or scope specification.
- Concentration risk on a single cloud/CTPP unquantified and without contingency.
- Third-party subcontracting chains for critical services unmapped and unmonitored.
15. DORA mapped to other frameworks
| DORA pillar / concept | NIS2 | ISO/IEC 27001 & 27002 | Other reference |
|---|---|---|---|
| ICT risk-management framework (Arts 6-8) | Art 21 risk-management measures | Clauses 4-10; A.5 org controls | EBA Guidelines on ICT and security risk management; NIST CSF Identify/Protect. |
| Protection and detection (Arts 9-10) | Art 21 technical measures | A.8 technological controls (access, crypto, logging) | NIST CSF Protect/Detect; PCI DSS access and monitoring. |
| Response and recovery / BCP (Arts 11-12) | Art 21 business continuity, backup | A.5.29-A.5.30 continuity; ISO 22301 | NIST CSF Respond/Recover; ISO 22301 BCMS. |
| Incident classification and reporting (Arts 17-23) | 24h early warning / 72h notification / 1-month final | A.5.24-A.5.28 incident management | GDPR 72h breach notice; national CSIRT reporting. |
| Resilience testing and TLPT (Arts 24-27) | Not prescriptive on TLPT | A.8.8 vulnerability; A.8.29 secure testing | TIBER-EU; CBEST; NIST SP 800-115. |
| ICT third-party risk (Arts 28-44) | Supply-chain security under Art 21 | A.5.19-A.5.23 supplier relationships | EBA outsourcing guidelines; NIST SP 800-161 C-SCRM. |
| Governance and accountability (Art 5) | Management-body accountability and training | Clause 5 leadership; A.5.1-A.5.4 | EBA internal governance guidelines. |
| Information sharing (Art 45) | Voluntary information sharing under NIS2 | A.5.6 contact with special interest groups | ISACs / FS-ISAC arrangements. |
16. How CyberSigma helps
How CyberSigma helps with DORA
CyberSigma provides end-to-end DORA readiness for EU-facing financial entities and their ICT providers. As a CERT-In empanelled and PCI QSA advisory team, we run a pillar-by-pillar gap assessment against the Regulation and its RTS/ITS, help you formally identify critical or important functions, and build a board-approved ICT risk-management framework and digital resilience strategy. We stand up incident classification and reporting workflows tuned to the 4-hour, 24-hour, 72-hour and one-month deadlines, design and test BC/DR to defined RTO/RPO, and build your register of information and Article 30-compliant contract and exit-strategy remediation. For entities designated significant, we scope and coordinate Threat-Led Penetration Testing aligned to TIBER-EU, including threat intelligence, control-team facilitation and attestation. Our resilience dashboards track the KPIs supervisors expect, and our continuous-assurance service keeps your framework, testing and third-party register audit-ready year-round. Talk to CyberSigma to move from DORA gap to DORA-resilient.
Frequently asked questions
Who must comply with DORA?
Almost all EU-regulated financial entities and the critical ICT third-party providers that serve them, including many non-EU vendors reaching EU clients.
Official documents
CyberSigma resources
Need help with DORA?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.