DORA and ISO 27001 Compliance: One Unified Programme

Financial institutions across the EU face a dual compliance reality. DORA became applicable on 17 January 2025, introducing binding ICT risk obligations for banks, insurers, investment firms, and their critical technology providers. ISO 27001:2022, revised from the 2013 edition, remains the most widely recognised global standard for information security management, and many regulated financial entities hold or are pursuing certification.

The business case for running a unified programme is clear. Both frameworks address the same underlying risk domain: the security, availability, and integrity of information systems. The cost of running two independent compliance streams with separate control libraries, separate evidence gathering, and separate audit preparation is significant and largely unnecessary given the degree of structural overlap.

The complexity lies in where the frameworks diverge. DORA is a binding EU regulation enforced by the European Supervisory Authorities (ESAs) (the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA)) with direct penalties for non-compliance. ISO 27001 is a voluntary standard for which organisations seek third-party certification. Their documentation models, governance expectations, and testing requirements diverge at several points, and those divergences require deliberate design decisions in a unified programme.

DORA's core ICT risk management requirements, set out in Articles 5 to 16, organise around five functional pillars: governance, protection, detection, response and recovery, and learning and evolving. ISO 27001:2022 addresses the same domains across its management system requirements (Clauses 4 to 10) and the 93 controls in Annex A, structured across four themes: Organisational, People, Physical, and Technological.

Coverage is extensive across DORA Articles 5-16, though some DORA requirements go further than what Annex A controls address on their own. The table below maps DORA's primary articles to the most directly relevant ISO 27001:2022 Annex A controls. Compliance teams should treat this as a working framework: where an ISO 27001 control satisfies the DORA requirement, document that mapping as evidence; where DORA imposes specific procedural or documentation requirements beyond what the control covers, treat that as a new control requirement.

Board-Level Accountability (Article 5)

This is the most significant governance gap. DORA Article 5 places direct legal accountability on the management body itself for the ICT risk management framework, its implementation, and its review. Under Article 5(4), management body members are required to keep their ICT knowledge and skills up to date to understand and assess ICT risk and its impact on the organisation.

ISO 27001 requires top management commitment and leadership (Clause 5.1), but it does not establish the same direct liability model. For ISO 27001-certified firms approaching DORA compliance, the primary governance gap is documentation of board engagement, decision-making, and personal accountability rather than the underlying controls, which are often already in place.

Regulatory Reporting (Articles 17-23)

DORA's incident reporting regime introduces a structured three-stage process that sits entirely outside ISO 27001's scope. Under Articles 17-23, financial entities must submit: an initial notification to the competent authority within 4 hours of classification (no later than 24 hours from first awareness); an intermediate report within 72 hours; and a final report within one month. These obligations apply regardless of whether the incident also triggers notification under NIS2 or GDPR.

Compliance teams building a unified programme should maintain a single incident log that feeds all reporting obligations, but should assess each incident against DORA's specific classification criteria (set out in the ESA Regulatory Technical Standards on incident classification) separately from the ISO 27001 event classification process. The thresholds are different and must be applied independently.

Threat-Led Penetration Testing (Articles 25-27)

DORA requires financial entities identified by their competent authority to carry out TLPT (threat-led penetration testing) at least every three years under Articles 25-27. TLPT involves live production systems, an intelligence-led red team exercise, and structured remediation. ISO 27001 leaves penetration test scope and methodology to the organisation: its technical vulnerability management control (Annex A 8.8) falls well short of TLPT in both scope and method. Significant financial entities should treat TLPT as a standalone programme requirement, separate from the ISO 27001 internal audit and technical testing cycle.

Contractual Requirements for ICT Third Parties (Article 30)

DORA Article 30 specifies minimum contractual provisions that financial entities must include in agreements with ICT third-party service providers: audit rights, SLA obligations, data portability provisions, and, for critical ICT third-party providers, alignment to the ESA direct oversight framework under Article 28. ISO 27001 Annex A controls 5.19 to 5.22 address supplier security requirements at a high level, leaving the specific contractual provisions to organisational policy. Compliance teams should maintain a contract review process specifically mapped to Article 30 requirements, separate from the ISO 27001 supplier assessment process.

Start With the ISO 27001 Control Library as Your Foundation

For organisations already certified to ISO 27001:2022, the most efficient approach is to treat the existing control library as the base and layer DORA requirements on top. Begin with a structured gap analysis mapping each DORA article requirement to its corresponding ISO 27001 control(s) using the table above. Where an ISO 27001 control satisfies the DORA requirement, document that mapping as evidence. Where DORA requires more (on contractual terms, reporting, board accountability, or testing) treat that as a new control requirement to be added to the programme.

Use a Single Risk Register

ISO 27001 Clause 6.1 requires a risk assessment and treatment process. DORA Article 8 requires ongoing identification and assessment of ICT risk sources. These are substantively the same activity, and one risk register can satisfy both sets of documentation requirements.

Apply DORA's classification language (distinguishing between ICT risk affecting critical or important functions and ICT risk with broader scope) as a tagging layer on the ISO 27001 risk register, rather than maintaining two separate registers. This keeps evidence consolidated while supporting separate reporting for ISO 27001 certification auditors and DORA supervisory review.

Consolidate Evidence, Separate Audit Packs

Unified evidence collection is efficient. Presenting that evidence separately for each audience is a different matter: ISO 27001 certification audits and DORA regulatory examinations require different presentations of evidence, different levels of technical detail, and different demonstration of management engagement. Collect once, present twice. Build your control evidence library so that each item can be tagged to both its ISO 27001 clause reference and its DORA article reference, then generate separate views for each audience.

Assign Ownership at the Programme Level

A unified programme requires a single owner with visibility across both compliance tracks. In practice, this is most often the CISO or Head of Information Security. DORA's explicit board accountability requirements mean the management body must be formally assigned oversight of the ICT risk management framework, and that assignment must be documented. The compliance programme owner and the management body overseer are two distinct roles, and both must be defined in the unified programme governance structure.

The operational challenge is calendar management. ISO 27001 certification audits (Stage 1, Stage 2, and annual surveillance audits) run on a fixed cycle tied to your certification body. DORA compliance is continuous and subject to regulatory examination at any time, with supervisory review intensifying in the first years of DORA enforcement.

Four practical steps for managing both tracks with one team:

1. Align your ISO 27001 annual management review (required under Clause 9.3) with your DORA ICT risk framework review. These are substantively the same activity. A combined review, documented to meet both requirements simultaneously, reduces management time and produces evidence for both tracks.
2. Schedule DORA-specific exercises (particularly incident response testing and tabletop exercises) at points in the year that do not conflict with ISO 27001 surveillance audit preparation.
3. Use your ISO 27001 internal audit programme (Clause 9.2) to cover DORA controls. Your internal audit schedule should explicitly reference DORA article obligations alongside ISO 27001 Annex A controls so that audit findings address both.
4. Track DORA Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) publications from the ESAs separately from ISO 27001 standard updates. DORA's technical standards are being issued in phases and may tighten requirements in specific areas, particularly incident classification criteria and third-party risk assessment methodology.