| Scope boundary | 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. | ISO/IEC 27001 scope is set by the organisation for its ISMS boundaries and applicability, taking account of internal and external issues, interested-party requirements, and information security risks. | A DORA scope memo should identify the regulated entity, function, ICT service, supplier, or incident. An ISO/IEC 27001 scope statement can support that memo only if its ISMS boundary covers the same facts. |
|---|
| Covered actors | 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. | ISO/IEC 27001 is a management-system standard. It defines ISMS requirements and can be used for internal assurance or third-party certification, but it is not an EU financial-sector regulation. | Do not describe ISO/IEC 27001 certification as DORA compliance. Treat it as possible control evidence for specific DORA obligations. |
|---|
| Trigger | DORA puts ICT risk governance on the financial entity, including management-body oversight of ICT risk management arrangements and resilience responsibilities. | ISO/IEC 27001 requires top-management leadership, ISMS roles and responsibilities, risk treatment, performance evaluation, internal audit, management review, and continual improvement. | 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. |
|---|
| Core obligations | 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. | ISO/IEC 27001 supports incident-management planning, event assessment, evidence preservation, and contact with relevant authorities, but it does not create DORA's major-incident reporting sequence or clocks. | 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. |
|---|
| Evidence record | 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. | ISO/IEC 27001 evidence should include ISMS scope, risk assessment and treatment records, Statement of Applicability, control evidence, internal audit results, management review records, nonconformities, corrective actions, and certification records if applicable. | 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. |
|---|
| Testing and TLPT | DORA requires a digital operational resilience testing programme and includes threat-led penetration testing for financial entities identified under DORA criteria. | ISO/IEC 27001 requires evaluation of ISMS effectiveness and controls but does not itself determine which financial entities must perform DORA TLPT. | 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. |
|---|
| Enforcement | 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. | ISO/IEC 27001 can support supplier security selection, monitoring, and control evidence within the ISMS, but it does not provide DORA's register templates or contract-policy requirements. | 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. |
|---|
| Overlap and reuse | 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. | 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. | 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. |
|---|
| Practical decision rule | 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. | ISO/IEC 27001 assurance is management-system assurance. Certification is optional and can demonstrate commitment to information security, especially when issued by an accredited conformity assessment body. | An ISO/IEC 27001 certificate may help customers and auditors trust the ISMS, but DORA remediation and supervisory questions still go to the DORA accountable owner. |
|---|