Two Frameworks, Different Starting Points
ISO 27001 and DORA both address ICT risk management, but they approach it from fundamentally different angles. ISO 27001 is a voluntary international standard that provides a framework for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). Organisations pursue certification to demonstrate security maturity to clients, partners, and regulators.
DORA (EU Regulation 2022/2554) is a mandatory regulation that applies to approximately 22,000 financial entities across the EU. It entered into force on 17 January 2025 and prescribes detailed requirements for digital operational resilience, covering ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
The key distinction is that ISO 27001 certification is a choice, while DORA compliance is a legal obligation. An ISO 27001-certified financial entity still needs to satisfy DORA's additional requirements. But the good news is that ISO 27001 provides a substantial head start: if you already run a certified ISMS, you have the governance structures, risk methodology, and control framework that DORA builds upon.
DORA vs ISO 27001 Comparison Table
This table highlights the most important differences across the dimensions that matter for compliance planning. Use it to identify where your existing ISO 27001 programme already meets DORA expectations and where additional work is needed.
| Dimension | ISO 27001 | DORA (EU 2022/2554) |
|---|---|---|
| Legal status | Voluntary international standard; certification is optional | Mandatory EU regulation; directly applicable in all member states |
| Scope | Any organisation, any sector, any size | EU financial entities (banks, insurers, investment firms, payment institutions, crypto-asset providers) + critical ICT providers |
| Risk management | Risk-based ISMS with Annex A controls; organisation defines own risk appetite | Prescriptive ICT risk management framework (Art. 5–16) with specific requirements for identification, protection, detection, response, recovery, and learning |
| Incident reporting | Internal incident management process (A.5.24–A.5.28); no regulatory reporting timeline | Mandatory reporting to NCA: 4h initial notification, 72h intermediate report, 1 month final report |
| Testing | Recommends testing and evaluation of security measures; no specific methodology mandated | Mandates annual basic testing + TLPT every 3 years for designated entities (Art. 24–27) |
| Third-party risk | Supplier relationship management (A.5.19–A.5.23); asset inventory approach | Register of Information in machine-readable format + mandatory contract clauses + pre-contract due diligence + CTPP oversight framework (Art. 28–44) |
| Board accountability | Top management oversight and commitment (Clause 5); no personal liability | Management body personally liable for ICT risk management framework; must approve and oversee implementation (Art. 5(2)) |
| Business continuity | Business continuity controls (A.5.29–A.5.30); aligns with ISO 22301 | ICT business continuity management with specific recovery time and point objectives; mandatory testing of ICT continuity plans |
| Penalties | No regulatory penalties; risk of losing certification | Regulatory fines set by NCAs; CTPP periodic penalties up to 1% daily worldwide turnover; personal liability for management body members |
Where ISO 27001 and DORA Overlap
If you already hold ISO 27001 certification, you have significant coverage across several DORA requirement areas. These overlapping domains mean you are not starting from zero.
Risk Management Frameworks
Both require a structured risk management approach covering identification, assessment, treatment, and monitoring. Your ISO 27001 risk assessment methodology and Statement of Applicability provide a strong starting point for DORA's ICT risk management framework under Articles 5–16.
Governance and Accountability
ISO 27001 Clause 5 requires top management commitment, while DORA Art. 5(2) requires management body oversight. Both insist on clear roles, responsibilities, and board-level engagement with information security and operational resilience.
Incident Detection and Response
ISO 27001 Annex A.5.24–A.5.28 covers information security incident management. DORA Articles 17–23 address ICT-related incident management. Both require processes for detecting, classifying, responding to, and learning from incidents.
Asset Management
ISO 27001 Annex A.5.9–A.5.13 addresses information asset identification and classification. DORA Art. 8 requires financial entities to identify all ICT assets and maintain an up-to-date inventory. Your existing asset register gives you a foundation to build on.
Access Control and Authentication
ISO 27001 Annex A.8.1–A.8.5 and A.5.15–A.5.18 cover access control, identity management, and authentication. DORA Art. 9(4) requires strong authentication, access management policies, and monitoring of access to ICT systems and data. The control objectives align closely.
Where DORA Goes Further Than ISO 27001
While ISO 27001 gives you a solid security management framework, DORA introduces several requirements that have no direct equivalent in the standard. These are the areas where financial entities need to extend their existing ISMS to achieve compliance.
Mandatory threat-led penetration testing (TLPT). DORA Art. 26–27 requires designated financial entities to conduct threat-led penetration testing at least every three years, following the TIBER-EU framework or equivalent. ISO 27001 recommends testing but does not mandate any specific methodology, frequency, or approach. TLPT is one of the most resource-intensive DORA requirements and requires careful planning. See our resilience testing guide for implementation details.
Register of Information. DORA Art. 28(3) requires financial entities to maintain a complete register of all contractual arrangements with ICT third-party service providers, in a machine-readable format that can be submitted to regulators on request. ISO 27001 addresses supplier relationships at a high level (A.5.19–A.5.23) but does not require a structured, machine-readable register. This is a significant new data management obligation. Learn more about this requirement in our third-party risk management guide.
Mandatory contract clauses. DORA Art. 30 prescribes specific clauses that must be included in agreements with ICT service providers, covering service levels, data location, audit rights, exit strategies, and subcontracting conditions. ISO 27001 requires organisations to address information security in supplier agreements but does not prescribe mandatory contract terms.
CTPP oversight framework. DORA establishes direct EU-level oversight of Critical Third-Party Providers (CTPPs) through Lead Overseers appointed by the ESAs. This is a regulatory construct that has no equivalent in ISO 27001. Financial entities need to understand whether their key providers are designated as CTPPs and what that means for their contractual and oversight arrangements.
Specific incident reporting timelines. DORA requires an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month, all submitted to the relevant financial supervisory authority. ISO 27001 requires incident management processes but does not impose any external reporting timeline. This gap requires new reporting workflows and templates.
Board personal liability. DORA Art. 5(2) makes the management body personally responsible for defining, approving, overseeing, and being accountable for the ICT risk management framework. ISO 27001 Clause 5 requires top management commitment but does not establish personal liability. This distinction changes how boards engage with operational resilience and may require updated governance processes.
Concentration risk monitoring. DORA Art. 29 requires financial entities to assess and manage ICT concentration risk, including dependencies on individual providers or on providers that serve a large portion of the financial sector. ISO 27001 does not address concentration risk as a specific control area.
Using ISO 27001 as a Foundation for DORA
If you already operate a certified ISMS, the most efficient path to DORA compliance is to extend what you have rather than build a parallel programme. Your ISO 27001 management system gives you the governance structures, risk methodology, internal audit capabilities, and control framework that DORA builds upon.
Your ISMS covers more than you think
Organisations with a mature ISO 27001 ISMS typically find that 60–70% of DORA's requirements are already addressed at some level. The risk assessment process, control implementation approach, management review cycles, and continuous improvement methodology all transfer directly. The work ahead is focused on the DORA-specific additions, not on rebuilding from scratch.
Do not create a separate programme. A common mistake is to treat DORA as an entirely new compliance initiative with its own governance, documentation, and reporting structures. This creates duplication, increases cost, and makes long-term maintenance harder. Instead, integrate DORA requirements into your existing ISMS scope, extend your Statement of Applicability to cover DORA-specific controls, and use your established management review and internal audit processes to monitor compliance.
Run a structured gap analysis. The single most valuable step is a systematic comparison of your current ISO 27001 controls against DORA's specific requirements. This identifies exactly where your ISMS already satisfies DORA, where controls need to be strengthened, and where entirely new capabilities are required. The DORA gap analysis tool is designed for exactly this purpose and maps your current posture across all five DORA pillars.
Prioritise the highest-impact gaps. Not all gaps carry equal weight. TLPT planning, Register of Information implementation, and incident reporting workflow changes tend to be the most time-intensive additions. Start with these areas to ensure you have adequate lead time for implementation, particularly for TLPT which requires engagement with external testers and coordination with regulators.
Recommended Approach: From ISO 27001 to DORA Compliance
Follow these steps to systematically extend your ISO 27001 programme to meet DORA requirements. Each step builds on the previous one and is designed to minimise disruption to your existing management system.
Map ISO 27001 controls to DORA articles
Create a detailed mapping between your Annex A controls and the five DORA pillars. Identify which controls already satisfy DORA requirements, which partially satisfy them, and which DORA articles have no corresponding ISO 27001 control. This mapping becomes your baseline for the gap analysis.
Identify and document gaps
For each DORA requirement that is not fully covered by your current ISMS, document the gap, the effort required to close it, and the priority level. Focus on the areas outlined in the gaps section above: TLPT, Register of Information, mandatory contract clauses, incident reporting timelines, board liability, and concentration risk. Use the free assessment tool to accelerate this step.
Extend your ISMS with DORA-specific controls
Add new controls to your Statement of Applicability to address the identified gaps. Update your risk treatment plan to include DORA-specific risks. Integrate these controls into your existing control monitoring and internal audit schedule rather than creating a separate oversight structure.
Add DORA reporting capabilities
Implement the incident reporting workflows that DORA requires, including templates for initial notifications, intermediate reports, and final reports. Set up your Register of Information in the machine-readable format required by the regulation. Configure board reporting to cover DORA-specific metrics and accountability requirements. The DORA GRC platform provides these capabilities out of the box.
Implement your TLPT programme
If your entity is designated for TLPT, plan and execute your threat-led penetration testing programme in accordance with Art. 26–27 and the TIBER-EU framework. This involves engaging qualified threat intelligence and red team providers, defining the scope with your competent authority, and conducting tests against live production systems. See the resilience testing guide for a detailed implementation roadmap.
Frequently Asked Questions
No. ISO 27001 provides a strong foundation that covers roughly 60–70% of what DORA requires, but it does not address several mandatory DORA obligations. These include threat-led penetration testing, a machine-readable Register of Information, prescriptive incident reporting timelines to regulators, mandatory contract clauses for ICT providers, CTPP oversight, and explicit board personal liability. You need to identify and close these gaps by extending your ISMS with DORA-specific controls.
Yes, and this is the recommended approach. Your ISO 27001 ISMS already provides the governance framework, risk management methodology, asset inventory, access controls, and incident management processes that DORA requires. Rather than building a separate DORA compliance programme, extend your existing management system with DORA-specific controls. Run a gap analysis to identify what DORA requires beyond your current scope, then add those controls as extensions within your established framework.
The main gaps fall into six areas: (1) TLPT — DORA mandates threat-led penetration testing every three years for designated entities; (2) Register of Information — a machine-readable register of all ICT third-party arrangements with no ISO 27001 equivalent; (3) Incident reporting — specific timelines of 4 hours, 72 hours, and 1 month to regulators; (4) Contract clauses — mandatory terms for ICT provider agreements; (5) CTPP oversight — an EU-level oversight framework for critical ICT providers; (6) Board liability — personal liability for management body members that goes beyond ISO 27001's top management commitment.
Start by mapping Annex A controls to the five DORA pillars. Annex A.5 (Organisational controls) maps broadly to DORA's ICT risk management framework (Art. 5–16). A.8 (Technological controls) aligns with DORA's protection and testing requirements. A.5.19–A.5.23 (Supplier relationships) maps to DORA's third-party risk management (Art. 28–44), though DORA goes significantly further. A.5.24–A.5.28 (Incident management) maps to DORA's incident reporting (Art. 17–23), but without the specific timelines. Use a structured gap analysis tool to systematically identify where DORA requirements exceed your current Annex A coverage.