DORA vs ISO/IEC 27001 Legal resilience obligations versus ISMS assurance
DORA is an EU financial-sector regulation for digital operational resilience. ISO/IEC 27001 is a certifiable standard.
This comparison shows where ISO/IEC 27001 evidence can support DORA work, and where DORA still requires separate legal, reporting, testing, register, contract, and supervisory evidence.
DORA has applied since 17 January 2025 to the financial entities in its scope. ISO/IEC 27001:2022, together with Amendment 1:2024, specifies requirements for an (ISMS). An ISMS can supply control evidence for DORA, but its scope, risk treatment, Statement of Applicability, and optional certificate do not replace DORA's entity-specific governance, incident reporting, resilience testing, ICT third-party records, contracts, or supervisory duties.
Side-by-side comparison
DORA vs ISO/IEC 27001: what overlaps and what does not
Use these rows to decide when an ISO/IEC 27001 ISMS artifact can support DORA and when a DORA-specific legal, supervisory, reporting, testing, or supplier record is still required.
DORA scope starts with covered financial entities, their ICT-supported business functions, critical or important functions, ICT risk, ICT incidents, ICT third-party services, and related supervisory records.
Supports DORA scope around financial entities and ICT operational resilience obligations.
financial entities
The organisation defines the ISMS boundaries and applicability after considering internal and external issues, interested-party requirements, interfaces, and dependencies. A certificate covers only the scope stated on it.
Supports ISO/IEC 27001 as an adaptable ISMS standard for organisations of different sizes and sectors.
adapted to their size and needs
A DORA scope memo should identify the regulated entity, function, ICT service, supplier, asset, and incident process. An ISO/IEC 27001 scope statement supports that memo only where its boundary covers the same facts.
DORA is EU law for the financial sector. It creates regulatory obligations for covered financial entities and establishes an oversight framework for critical ICT third-party providers.
Supports DORA's status as the EU financial-sector digital operational resilience regulation.
digital operational resilience for the financial sector
ISO/IEC 27001 is a management-system standard that any organization can implement. Third-party certification is optional and attests conformity of the scoped ISMS, not compliance with EU financial-sector law.
Supports ISO/IEC 27001 as an ISMS standard and explains that organisations may choose whether to pursue certification.
information security management system
Do not describe ISO/IEC 27001 certification as DORA compliance. Check the certificate scope, exclusions, Statement of Applicability, audit period, and underlying evidence before mapping it to a DORA obligation.
DORA puts ICT risk governance on the financial entity, including management-body oversight of ICT risk management arrangements and resilience responsibilities.
Supports ISO/IEC 27001 as a management-system standard for maintaining and improving information security.
continually improving
Management review minutes can help, but DORA evidence should show the management body's DORA ICT-risk decisions, approvals, risk appetite, remediation, and supplier-risk oversight.
DORA requires classification of ICT-related incidents and reporting of major ICT-related incidents through an initial notification, intermediate report, and final report. The reporting RTS sets specific time limits, including initial reporting within four hours of major classification and no later than 24 hours after awareness. If classification as major occurs after the first 24 hours, the initial notification is due within four hours of that later classification.
Supports the DORA initial notification, intermediate report, final report, and specified reporting time limits.
initial notification
ISO/IEC 27001 can support incident planning, event assessment, response, learning, evidence collection, and contact with authorities. It does not define DORA's major-incident thresholds, report template, recipient, or clocks.
Supports ISO/IEC 27001 as a risk-management and information-security control system rather than a DORA reporting regime.
manage risks related to the security of data
Use ISO/IEC 27001 incident procedures for preparation and records, but run a separate DORA classification and reporting workflow for potentially major ICT-related incidents.
DORA evidence should include ICT risk framework records, management-body approvals, incident classification and reporting records, register-of-information entries, ICT service contract evidence, resilience test results, remediation records, and supervisory-response material.
Supports the DORA evidence categories for ICT risk, incidents, testing, third-party risk, and supervisory readiness.
ICT risk management
ISO/IEC 27001 evidence should include the ISMS scope, risk assessment and treatment records, Statement of Applicability, control evidence, competence records, monitoring results, internal audits, management reviews, nonconformities, corrective actions, and certification records if applicable.
Supports ISO/IEC 27001 as a certifiable ISMS that manages risks through documented management-system practices.
Store shared evidence once if useful, but label every record by obligation. The same supplier control can support both regimes; a DORA reporting deadline or register template usually cannot be replaced by an ISO artifact.
DORA requires an Article 24 digital operational resilience testing programme for entities other than microenterprises, proportionate testing for microenterprises, and threat-led penetration testing for identified financial entities outside the Article 16 and microenterprise exemptions.
Supports DORA-specific criteria for identifying financial entities required to perform TLPT.
threat-led penetration testing
ISO/IEC 27001 requires monitoring, measurement, analysis, evaluation, internal audit, and management review of the ISMS. It does not determine which financial entities must perform DORA TLPT or prescribe DORA's testing scope and frequency.
Supports ISO/IEC 27001 as an ISMS used for risk management and operational excellence.
risk management, cyber-resilience and operational excellence
Security testing evidence can be reused only after confirming it satisfies the DORA testing objective, entity scope, scenario, independence, remediation, and TLPT criteria where relevant.
DORA requires governance of ICT third-party risk, registers of information for ICT third-party arrangements, and detailed policy content for contracts supporting critical or important functions.
Supports DORA contract-policy content for ICT services supporting critical or important functions.
critical or important functions
ISO/IEC 27001 can support supplier selection, contractual security, monitoring, change management, and cloud-service controls selected through the ISMS. It does not provide DORA's register templates, critical-function test, contract clauses, or subcontracting process.
Supports ISO/IEC 27001 as an ISMS that manages information security risks, including supplier-related controls when selected in scope.
manage risks related to the security of data
Reuse supplier due-diligence evidence where it fits, but create DORA register rows, critical-or-important-function flags, subcontracting records, contractual rights, and exit evidence separately.
If the record must answer a DORA legal question, such as whether an incident is major, whether an ICT service supports a critical or important function, or whether TLPT applies, use DORA and its RTS or ITS as the source.
Supports using DORA as the controlling legal source for ICT operational resilience obligations.
ICT-related incidents
If the record must answer an ISMS question, such as whether a control is selected, implemented, audited, improved, or within certification scope, use ISO/IEC 27001 as the source.
Supports using ISO/IEC 27001 as the ISMS source for information security risk management and conformity evidence.
requirements an ISMS must meet
A useful comparison output is a gap register with columns for DORA obligation, ISO/IEC 27001 supporting control, reusable evidence, missing DORA-specific evidence, owner, and next review trigger.
DORA assurance is regulatory: competent authorities supervise financial entities, Member States set administrative penalties and remedial measures, and critical ICT third-party providers can fall within the DORA oversight framework.
Supports DORA supervisory powers, penalties, remedial measures, and oversight framework context without stating unsupported penalty amounts.
administrative penalties and remedial measures
ISO/IEC 27001 assurance concerns conformity of the ISMS within its stated scope. Certification is optional; accreditation concerns the certification body, not a regulator's approval of DORA compliance.
Supports ISO/IEC 27001 certification as one way to demonstrate secure information management to stakeholders and customers.
demonstrate to stakeholders and customers
Use the certificate as one assurance input. DORA remediation, reporting, testing, contract, register, and supervisory questions still require evidence owned by the regulated financial entity.
Supports keeping DORA accountability tied to the regulated financial-sector supervisory route.
competent authorities
Scope boundary
EU DORA
DORA scope starts with covered financial entities, their ICT-supported business functions, critical or important functions, ICT risk, ICT incidents, ICT third-party services, and related supervisory records.
Supports DORA scope around financial entities and ICT operational resilience obligations.
financial entities
ISO/IEC 27001
The organisation defines the ISMS boundaries and applicability after considering internal and external issues, interested-party requirements, interfaces, and dependencies. A certificate covers only the scope stated on it.
Supports ISO/IEC 27001 as an adaptable ISMS standard for organisations of different sizes and sectors.
adapted to their size and needs
Operational implication
A DORA scope memo should identify the regulated entity, function, ICT service, supplier, asset, and incident process. An ISO/IEC 27001 scope statement supports that memo only where its boundary covers the same facts.
Supports the need to anchor DORA evidence to the financial entity and ICT context.
ICT services
Legal status and certification
EU DORA
DORA is EU law for the financial sector. It creates regulatory obligations for covered financial entities and establishes an oversight framework for critical ICT third-party providers.
Supports DORA's status as the EU financial-sector digital operational resilience regulation.
digital operational resilience for the financial sector
ISO/IEC 27001
ISO/IEC 27001 is a management-system standard that any organization can implement. Third-party certification is optional and attests conformity of the scoped ISMS, not compliance with EU financial-sector law.
Supports ISO/IEC 27001 as an ISMS standard and explains that organisations may choose whether to pursue certification.
information security management system
Operational implication
Do not describe ISO/IEC 27001 certification as DORA compliance. Check the certificate scope, exclusions, Statement of Applicability, audit period, and underlying evidence before mapping it to a DORA obligation.
Supports the distinction between implementing ISO/IEC 27001 and using certification for stakeholder assurance.
go through a certification process
Governance and accountability
EU DORA
DORA puts ICT risk governance on the financial entity, including management-body oversight of ICT risk management arrangements and resilience responsibilities.
Supports ISO/IEC 27001 as a management-system standard for maintaining and improving information security.
continually improving
Operational implication
Management review minutes can help, but DORA evidence should show the management body's DORA ICT-risk decisions, approvals, risk appetite, remediation, and supplier-risk oversight.
Supports separating DORA management-body evidence from general ISMS review evidence.
ICT risk management
Incident reporting
EU DORA
DORA requires classification of ICT-related incidents and reporting of major ICT-related incidents through an initial notification, intermediate report, and final report. The reporting RTS sets specific time limits, including initial reporting within four hours of major classification and no later than 24 hours after awareness. If classification as major occurs after the first 24 hours, the initial notification is due within four hours of that later classification.
Supports the DORA initial notification, intermediate report, final report, and specified reporting time limits.
initial notification
ISO/IEC 27001
ISO/IEC 27001 can support incident planning, event assessment, response, learning, evidence collection, and contact with authorities. It does not define DORA's major-incident thresholds, report template, recipient, or clocks.
Supports ISO/IEC 27001 as a risk-management and information-security control system rather than a DORA reporting regime.
manage risks related to the security of data
Operational implication
Use ISO/IEC 27001 incident procedures for preparation and records, but run a separate DORA classification and reporting workflow for potentially major ICT-related incidents.
Supports keeping DORA reporting clocks separate from internal incident-management timelines.
within four hours
Evidence record
EU DORA
DORA evidence should include ICT risk framework records, management-body approvals, incident classification and reporting records, register-of-information entries, ICT service contract evidence, resilience test results, remediation records, and supervisory-response material.
Supports the DORA evidence categories for ICT risk, incidents, testing, third-party risk, and supervisory readiness.
ICT risk management
ISO/IEC 27001
ISO/IEC 27001 evidence should include the ISMS scope, risk assessment and treatment records, Statement of Applicability, control evidence, competence records, monitoring results, internal audits, management reviews, nonconformities, corrective actions, and certification records if applicable.
Supports ISO/IEC 27001 as a certifiable ISMS that manages risks through documented management-system practices.
Operational implication
Store shared evidence once if useful, but label every record by obligation. The same supplier control can support both regimes; a DORA reporting deadline or register template usually cannot be replaced by an ISO artifact.
Supports the example that DORA-specific reporting evidence cannot be replaced by generic ISMS documentation.
intermediate and final report
Testing and TLPT
EU DORA
DORA requires an Article 24 digital operational resilience testing programme for entities other than microenterprises, proportionate testing for microenterprises, and threat-led penetration testing for identified financial entities outside the Article 16 and microenterprise exemptions.
Supports DORA-specific criteria for identifying financial entities required to perform TLPT.
threat-led penetration testing
ISO/IEC 27001
ISO/IEC 27001 requires monitoring, measurement, analysis, evaluation, internal audit, and management review of the ISMS. It does not determine which financial entities must perform DORA TLPT or prescribe DORA's testing scope and frequency.
Supports ISO/IEC 27001 as an ISMS used for risk management and operational excellence.
risk management, cyber-resilience and operational excellence
Operational implication
Security testing evidence can be reused only after confirming it satisfies the DORA testing objective, entity scope, scenario, independence, remediation, and TLPT criteria where relevant.
Supports treating DORA TLPT determination as separate from general ISMS testing.
identifying financial entities required
ICT third-party and supplier controls
EU DORA
DORA requires governance of ICT third-party risk, registers of information for ICT third-party arrangements, and detailed policy content for contracts supporting critical or important functions.
Supports DORA contract-policy content for ICT services supporting critical or important functions.
critical or important functions
ISO/IEC 27001
ISO/IEC 27001 can support supplier selection, contractual security, monitoring, change management, and cloud-service controls selected through the ISMS. It does not provide DORA's register templates, critical-function test, contract clauses, or subcontracting process.
Supports ISO/IEC 27001 as an ISMS that manages information security risks, including supplier-related controls when selected in scope.
manage risks related to the security of data
Operational implication
Reuse supplier due-diligence evidence where it fits, but create DORA register rows, critical-or-important-function flags, subcontracting records, contractual rights, and exit evidence separately.
Supports keeping DORA register evidence separate from general supplier-assurance files.
standard templates
Which sources to use
EU DORA
If the record must answer a DORA legal question, such as whether an incident is major, whether an ICT service supports a critical or important function, or whether TLPT applies, use DORA and its RTS or ITS as the source.
Supports using DORA as the controlling legal source for ICT operational resilience obligations.
ICT-related incidents
ISO/IEC 27001
If the record must answer an ISMS question, such as whether a control is selected, implemented, audited, improved, or within certification scope, use ISO/IEC 27001 as the source.
Supports using ISO/IEC 27001 as the ISMS source for information security risk management and conformity evidence.
requirements an ISMS must meet
Operational implication
A useful comparison output is a gap register with columns for DORA obligation, ISO/IEC 27001 supporting control, reusable evidence, missing DORA-specific evidence, owner, and next review trigger.
Supports treating ISMS conformity and certification evidence as distinct from DORA legal compliance.
Conformity with ISO/IEC 27001
Supervision and certification
EU DORA
DORA assurance is regulatory: competent authorities supervise financial entities, Member States set administrative penalties and remedial measures, and critical ICT third-party providers can fall within the DORA oversight framework.
Supports DORA supervisory powers, penalties, remedial measures, and oversight framework context without stating unsupported penalty amounts.
administrative penalties and remedial measures
ISO/IEC 27001
ISO/IEC 27001 assurance concerns conformity of the ISMS within its stated scope. Certification is optional; accreditation concerns the certification body, not a regulator's approval of DORA compliance.
Supports ISO/IEC 27001 certification as one way to demonstrate secure information management to stakeholders and customers.
demonstrate to stakeholders and customers
Operational implication
Use the certificate as one assurance input. DORA remediation, reporting, testing, contract, register, and supervisory questions still require evidence owned by the regulated financial entity.
Supports keeping DORA accountability tied to the regulated financial-sector supervisory route.
competent authorities
Practical decision rule
How should a financial entity use ISO/IEC 27001 for DORA?
Start with DORA: identify the financial entity, ICT-supported business function, critical or important function, incident, supplier, test, or register obligation.
Check whether an ISO/IEC 27001 process or control already produces evidence for that exact DORA point.
Reuse ISO/IEC 27001 evidence only when the scope, owner, record, and timing match the DORA obligation.
Create separate DORA evidence for major incident reporting, register templates, ICT contract policy content, TLPT determination, supervisory responses, and management-body ICT risk oversight.
Supports using ISO/IEC 27001 as the ISMS control and assurance source, not as a replacement for DORA.
information security management system
1
Section 1
DORA legal obligations vs ISO/IEC 27001 controls
DORA is binding EU law for financial entities and for oversight of critical ICT third-party providers. It is organised around ICT risk management, incident reporting, digital operational resilience testing, information sharing, and ICT third-party risk.
ISO/IEC 27001:2022 is an international management-system standard for establishing, implementing, maintaining, and continually improving an ISMS. Amendment 1:2024 adds the published climate-action changes to that edition. Certification is optional, applies only to the stated ISMS scope, and does not by itself satisfy DORA-specific legal obligations.
Use DORA as the legal obligation source for covered EU financial-sector operations and ICT services.
Use ISO/IEC 27001:2022 and Amendment 1:2024 as the ISMS requirements and assurance source for information security risk management.
Map ISO/IEC 27001 controls to DORA only where the control evidence actually supports a DORA requirement.
Defines DORA as the EU financial-sector digital operational resilience regulation and sets the main ICT risk, incident, testing, and third-party risk chapters.
digital operational resilience for the financial sector
Official ISO source for Edition 3 of the ISMS requirements standard, its published 2024 amendment, and optional certification.
information security management systems
2
Section 2
Where ISO/IEC 27001 helps DORA
ISO/IEC 27001 can provide an operating layer for DORA because it requires a defined ISMS scope, information security risk assessment and treatment, documented information, performance evaluation, internal audit, management review, corrective action, and continual improvement.
The Statement of Applicability records the necessary controls, whether they are implemented, and the reasons for including or excluding Annex A controls. Those records support DORA only when the ISMS boundary and evidence cover the relevant legal entity, ICT-supported business function, critical or important function, asset, incident process, supplier service, and resilience test.
Risk assessment, treatment, and Statement of Applicability records can support DORA ICT risk management, but DORA still needs financial-entity, service, asset, dependency, and critical-function context.
Internal audits and management reviews can support oversight evidence, but DORA still expects management-body accountability for ICT risk.
Supplier controls can support due diligence, but DORA still needs ICT-service contract terms, register rows, subcontracting oversight, and exit planning where applicable.
Incident controls can support preparation and evidence preservation, but DORA major incident classification and reporting clocks remain separate.
Supports the DORA obligation categories that need financial-sector-specific evidence beyond a generic ISMS.
ICT risk management
3
Section 3
Where DORA goes beyond ISO/IEC 27001
DORA adds legal mechanics that an ISO/IEC 27001 certificate does not cover: classification and staged reporting of major ICT-related incidents, a digital operational resilience testing programme, prescribed register-of-information templates, ICT contract requirements, and criteria for identifying financial entities required to perform threat-led penetration testing.
A control can exist inside an ISMS and still leave a DORA gap. The DORA record must connect that control to the regulated financial entity, the applicable article or technical standard, the affected critical or important function, the responsible management decision, and any required authority submission.
Major ICT-related incidents need DORA classification and reporting evidence, not only an internal incident ticket.
ICT third-party arrangements need DORA-specific contract and register evidence, not only supplier security questionnaires.
Entities other than microenterprises need the Article 24 testing programme; microenterprises follow the applicable proportionate testing requirements. Identified entities also need TLPT readiness. Vulnerability-management records alone do not cover these duties.
Management-body evidence needs to show DORA ICT risk oversight, not only ISMS management review minutes.
Specifies criteria used to identify financial entities required to perform threat-led penetration testing under DORA.
threat-led penetration testing
4
Section 4
Practical implementation pattern
Treat ISO/IEC 27001 as a reusable evidence layer, not as a DORA compliance label. Start with the DORA obligation, identify the ICT-supported function, supplier, incident, test, asset, or management decision, then decide whether existing ISMS evidence proves that point within its documented scope.
When the answer is yes, tag the ISO/IEC 27001 evidence to the DORA requirement and keep the source citation. When the answer is no, create a DORA-specific record instead of stretching an ISMS artifact beyond what it proves.
Create a DORA-to-ISMS control map with one row per DORA obligation, not one row per ISO control.
Keep separate owners for DORA legal interpretation, ISMS operation, incident reporting, supplier contracting, and resilience testing.
Supports using DORA as the controlling source for financial-sector ICT operational resilience obligations.
financial entities
Recommended next step
Turn the comparison into an obligation-by-obligation evidence map
Sorena can help separate DORA legal obligations from ISO/IEC 27001 control evidence, so incident, supplier, testing, register, and governance records do not get merged into an unsupported compliance claim.
Primary legal source for DORA scope, governance, ICT risk management, incident reporting, resilience testing, ICT third-party risk, oversight, and supervisory measures.
Defines DORA as the EU financial-sector digital operational resilience regulation and sets the main ICT risk, incident, testing, and third-party risk chapters.
Supports the DORA obligation categories that need financial-sector-specific evidence beyond a generic ISMS.
Show 12 more
Supports using DORA as the controlling source for financial-sector ICT operational resilience obligations.
Supports DORA scope around financial entities and ICT operational resilience obligations.
Supports the need to anchor DORA evidence to the financial entity and ICT context.
Supports DORA's status as the EU financial-sector digital operational resilience regulation.
Supports DORA governance and management-body accountability for ICT risk management.
Supports separating DORA management-body evidence from general ISMS review evidence.
Supports the DORA evidence categories for ICT risk, incidents, testing, third-party risk, and supervisory readiness.
Supports DORA's digital operational resilience testing obligations.
Supports using DORA as the controlling legal source for ICT operational resilience obligations.
Supports DORA supervisory powers, penalties, remedial measures, and oversight framework context without stating unsupported penalty amounts.
Supports keeping DORA accountability tied to the regulated financial-sector supervisory route.
Supports starting from DORA where the question concerns EU financial-sector ICT operational resilience obligations.
"digital operational resilience for the financial sector"