| 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. | 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. | 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. |
|---|
| 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 that any organization can implement. Third-party certification is optional and attests conformity of the scoped ISMS, not compliance with EU financial-sector law. | 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. |
|---|
| 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, assigned ISMS roles, risk treatment, performance evaluation, internal audit, management review, corrective action, 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 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. | 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 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. | 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 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. | 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 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. | 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 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. | 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. |
|---|