Your ISO 27001 certificate does not start DORA's clocks

A common way to start a DORA programme is with a spreadsheet. One column lists the requirements of Regulation (EU) 2022/2554, another lists the ISO/IEC 27001:2022 Annex A controls the firm has already implemented within its certified ISMS, and a third records the overlap. When the mapping is done, the overlap is large: ICT risk management, access control, supplier management, business continuity, incident handling. The residue can look like a writing exercise against an existing certificate.

That framing is the trap. It is not wrong about the overlap, which is genuine. It is wrong about what the residue is. The parts of DORA that a certified ISO 27001 firm has not already done are not simply documentation to write. Several of them are duties that must be performed, to a specification and on a clock, and a certificate is the wrong instrument to prove them.

A certificate attests a scoped system; a regulation imposes duties

ISO/IEC 27001:2022 certifies that an information security management system of defined scope meets the standard's requirements. Certification is not a single moment: a certification body issues the certificate after an audit, and it is typically maintained across a three-year cycle of surveillance audits and recertification. Two things travel with it that matter here. The object certified is a management system, bounded by the scope statement, and the certifying question is conformity: does the ISMS meet the requirements.

DORA is not built that way. It applies to financial entities directly from 17 January 2025 (Regulation (EU) 2022/2554), and its provisions are not a management system to conform to but obligations to perform, several of them timed and specified. You can hold a valid ISO 27001 certificate, in scope and in date, and still breach DORA, because the certificate answers a question DORA does not ask. Three of DORA's duties run on clocks or to specifications a certificate never tested; a fourth shifts accountability to a place a certificate never checks.

The register

Article 28(3) requires a financial entity to maintain a register of information on its contractual arrangements for the use of ICT services provided by ICT third-party service providers, and to report information on those arrangements to its competent authority at least yearly. The register is a structured artefact, not a free-form document: Commission Implementing Regulation (EU) 2024/2956, published in the Official Journal on 2 December 2024, lays down the standard templates and data fields. Under the European Supervisory Authorities' reporting arrangements, competent authorities then collect these registers from supervised entities and submit them to the ESAs, the first such collection running in 2025.

A certified firm already manages its ICT suppliers under Annex A controls such as A.5.19 to A.5.23, selected through its risk treatment and recorded in its Statement of Applicability. What that does not produce on its own is a register in the prescribed schema, populated to the DORA data fields, reconciled to the firm's actual contracts, and renderable to a supervisor on the collection cycle. Managing suppliers and rendering a specific structured artefact to a regulator are different obligations, and the second is not evidenced by the first.

The incident clock

Article 19 obliges financial entities to report major ICT-related incidents to the competent authority, and the technical standard fixes the timers. Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 requires an initial notification within four hours of the incident being classified as major and, ordinarily, no later than 24 hours after the entity became aware of it; an intermediate report within 72 hours of that initial notification; and a final report within one month of the intermediate report (or the latest updated intermediate report). Whether an incident is "major" at all is decided by the classification criteria in Commission Delegated Regulation (EU) 2024/1772.

The reference point is the part worth reading twice. DORA's four-hour clock runs from the moment an incident is classified as major, which makes accurate and prompt classification part of the obligation rather than a preliminary to it. That is a different structure from the incident-notification duties financial teams already know: NIS2's early warning runs within 24 hours of becoming aware of a significant incident (Directive (EU) 2022/2555, Article 23), and the GDPR requires a controller to notify a personal-data breach that risks individuals' rights without undue delay and, where feasible, within 72 hours of awareness (Regulation (EU) 2016/679, Article 33). They are not interchangeable clocks. Under Annex A controls A.5.24 to A.5.27, a certified firm plans for, assesses, responds to, and learns from information security incidents through the process it implemented, and an auditor accepted that process as conforming. An auditor accepting that the process conforms is not the same as that process producing a correctly classified regulatory notification inside four hours of classification.

The testing obligation

Article 26 requires financial entities identified by their competent authorities, on the basis of size, risk profile, and systemic importance, to carry out threat-led penetration testing at least every three years, on live production systems supporting critical or important functions. The three years is a floor the competent authority may adjust, and the detailed methodology and identification criteria are set out in Commission Delegated Regulation (EU) 2025/1190, applicable from 8 July 2025. This does not reach every financial entity, and the identification is the regulator's to make. But for a firm in scope it is a recurring, evidenced obligation of a specific kind.

ISO/IEC 27001 asks a firm to monitor, measure, and evaluate the performance of its ISMS (clause 9.1) and to run internal audits (clause 9.2), and Annex A control A.8.29 covers security testing in development and acceptance. None of those, on its own, evidences an intelligence-led red-team exercise against production, repeated on the DORA cadence and run to the supervisory methodology. A firm can be fully certified and never have done one.

The accountability that a certificate does not reach

Article 5(2) places on the management body the duty to define, approve, oversee, and be responsible for the ICT risk management framework, and point (a) makes it "bear the ultimate responsibility for managing the financial entity's ICT risk." Article 5(4) adds a personal duty: members of the management body must keep their knowledge and skills current enough to understand and assess ICT risk. This is the one of the four that is not a clock. It is a continuing governance obligation.

ISO/IEC 27001 clause 5.1 already requires top-management leadership and commitment, so this is the area of closest overlap. The gap is narrower and more specific than "ISO ignores the board." DORA fixes ultimate responsibility on the "management body," a legally defined term, and imposes a personal competence duty on its members. ISO's "top management" and DORA's "management body" are not necessarily the same people, and certification demonstrates leadership commitment to the ISMS, not compliance with Article 5(2)(a) or 5(4). A certificate can be earned without ever testing the specific accountability DORA names.

Why the mapping hides all four

The spreadsheet fails in a consistent way: it compares control text to control text, and DORA's additional weight is not only in the text. A control reads "the organisation shall manage information security incidents," and so does the firm's ISO evidence, and the cells match. What the cell does not show is that DORA has attached a reference-pointed four-hour timer, a prescribed register schema, an at-least-every-three-years testing obligation, and a legally named accountable body to activities that ISO states as capabilities. Two requirements can use nearly identical words and still be satisfied by different acts, because one asks whether a conforming system exists within a scope and the other asks whether a specified duty was performed.

This is the objection worth taking seriously, and it is the one that keeps many programmes on the documentation track. Annex A, the argument goes, already covers incident management, supplier management, and testing, so DORA is the same substance with a compliance wrapper. The answer is that a specification and a deadline are not a wrapper around a control. A reference point, a submission format, an adjustable testing cadence, and a named legal accountability are new obligations that a control's existence does not discharge, and they are precisely the ones a control-to-control mapping renders invisible.

The rule worth keeping

When you map a certification onto a regulation, map the operating obligations, not the control text. A certificate attests that a management system met a standard, within a scope, across an audit cycle. A regulation says what that system must do, to what specification, and by when. Where the two describe the same activity, check whether the regulation has attached a reference-pointed clock, a format, a cadence, or a named accountability, because those are the additions a control-to-control mapping renders invisible and the ones a supervisor is likely to test.

The instinct generalises past DORA, though the specifics differ by regime. NIS2 requires Member States to impose both management-body governance duties (Directive (EU) 2022/2555, Article 20) and a 24-hour early-warning duty (Article 23), over activities existing controls already describe. The Cyber Resilience Act attaches timed reporting of actively exploited vulnerabilities and severe incidents to manufacturers of products with digital elements, with those reporting duties applying from 11 September 2026 (Regulation (EU) 2024/2847, Article 14). The accountability models are not identical, but the reading discipline is: find the verb, find the clock or the specification, and treat every duty with a deadline or a defined addressee as an operating obligation rather than a document to write.

If your near-term task is separating the genuine ISO-27001-to-DORA overlap from the timed and specified duties a certificate does not evidence, that cross-referencing against the actual articles and technical standards is the kind of work ISMS Copilot is built to support. A large overlap on the mapping is real. It is also reusable evidence that still needs DORA-specific validation, not compliance you can carry across untouched, which is why it is not the part that should shape the plan.

This is practical compliance analysis, not legal advice. Confirm your entity's scope and obligations against the regulation and its technical standards, and where it matters with your competent authority or counsel.