One ISMS, three regulators: the same nine documents

Most organisations facing NIS2, DORA and an ISO 27001 audit at the same time do the obvious thing: they run three projects. Three owners, three spreadsheets, three sets of binders, three sets of the same evidence with different cover pages. It is expensive, it is slow, and it is the wrong shape. The three regimes overlap heavily at the level of controls — every consultancy in Europe will sell you that mapping. What almost nobody maps is the evidence: the actual documents you hand across the table. Those overlap even more than the controls do. The difference is not what each regulator asks for. It is what each one rejects it for.

The certificate is not the evidence

Start with the most common misreading. An ISO 27001 certificate is not, by itself, proof of NIS2 compliance — ISO 27001 is a voluntary certification against a standard, NIS2 is a legal obligation under national law, and a certificate does not discharge a statutory duty.

Belgium is the instructive case, because the Centre for Cybersecurity Belgium wrote its position down. An entity can obtain a presumption of conformity with the Belgian NIS2 law through CyberFundamentals verification or certification — or through ISO/IEC 27001 certification, provided the CCB finds the scope and the Statement of Applicability acceptable.

Read that condition again. The certificate travels; the scope and the Statement of Applicability are what get inspected. Which means the SoA — Clause 6.1.3(d) of the standard, the document most organisations treat as an annexe their auditor asks for once a year — is a regulatory instrument. If your scope statement quietly excludes the systems that deliver the regulated service, your certificate proves something true about a perimeter nobody is asking about.

The nine artefacts all three ask for

Strip away the framing and the three regimes converge on nine documents. Below is the map, with the clause each reader opens it under.

#	Artefact	ISO/IEC 27001:2022	NIS2	DORA
1	Scope statement + Statement of Applicability	6.1.3(d), 4.3	defines what Art. 21 measures actually cover	Art. 6(1)–(2) framework scope
2	Risk assessment + risk treatment plan	6.1.2, 8.2, 8.3	Art. 21(2)(a)	Arts 6, 8
3	Asset inventory	A.5.9	Art. 21(2)(a), (i)	Art. 8
4	Supplier register + contract clauses	A.5.19–A.5.22	Art. 21(2)(d), 21(3)	Arts 28–30, register of information
5	Incident log + reporting playbook	A.5.24–A.5.28	Art. 23	Arts 17–19
6	Continuity, backup, tested recovery	A.5.29–A.5.30, A.8.13	Art. 21(2)(c)	Arts 11–12
7	Access control + MFA records	A.5.15–A.5.18, A.8.5	Art. 21(2)(i), (j)	Art. 9
8	Training records, management body included	7.2, 7.3	Art. 20(2)	Arts 13(6), 5(4)
9	Internal audit report + management review minutes	9.2, 9.3	Art. 21(2)(f)	Art. 6(5)–(6)

The nine artefacts every one of the three asks for — and the clause each of them reads it under.

Nine documents. One owner each. That is the whole pack, and if you have a working ISMS you already hold most of it — which is exactly why the three-project approach is such a waste. What you are missing is not documents. It is the tagging that tells you which reader each document has to survive.

What each reader is actually checking

The same artefact is read three ways, and the failure modes are different enough to be worth naming.

ISO asks whether the ISMS is managed. The auditor is testing a cycle: risks assessed, controls selected and justified in the SoA, treatment plan executed, internal audit run, management review held, corrective actions closed. Evidence of the cycle turning is the point. A control that works but was never reviewed is a nonconformity.

NIS2 asks whether someone is accountable and whether the measures work. Two things ISO does not press on. Article 20 puts approval of the risk-management measures and oversight of their implementation on the management body itself, and makes that body liable for the entity’s infringements of Article 21. Article 21(2)(f) requires policies and procedures to assess the effectiveness of the measures — not that controls exist, but that you tested whether they do their job and can show the result. If your NIS2 readiness file contains policies and no test results, it answers the wrong question.

DORA asks whether the evidence is current and complete. This is the least forgiving of the three because much of it is machine-checked. For the 2026 register of information cycle the CSSF warned that the ESAs’ validation checks — unchanged in substance — would be applied to more data fields, so that a register accepted the previous year may be rejected this one. Nothing about those firms will have got worse. The bar moves quietly, and evidence quality — not evidence existence — is what DORA readiness turns on.

The three NIS2 duties an ISO certificate does not cover

There is real convergence here, but three NIS2 obligations have no ISO 27001 equivalent at all, and no amount of Annex A coverage produces them.

The reporting clocks. Article 23’s 24-hour early warning and 72-hour notification are procedural duties owed to your CSIRT or, where applicable, your competent authority. ISO asks you to manage incidents; it does not run a stopwatch. If DORA also applies, your effective deadline can be as little as four hours — we set the three clocks side by side in One Incident, Three Regulators.

Management-body accountability. Article 20(2) requires members of the management body to follow training — the directors, personally, and the same paragraph pushes entities to offer equivalent training to their staff. Nothing in it specifies what the record looks like. An auditor will still ask for one.

Registration with the national authority. Article 3(4) requires entities to identify themselves to their Member State. There is no clause in ISO 27001 that produces a registration.

What a valid ISO 27001 certificate does not give you under NIS2 and DORA.

Two ways a good pack still fails

It proves design, not operation. This is the single most common finding. The policy is written, approved, versioned — and nobody can produce the record showing the control ran last quarter. ENISA’s technical implementation guidance on cybersecurity risk-management measures, published in June 2025, is unusually blunt about this: for each requirement it lists the evidence an auditor would expect to see — logs, test reports, review records — and maps it to ISO/IEC 27001:2022 and other standards. The guidance is written for the sectors covered by Implementing Regulation (EU) 2024/2690 and is non-binding, but as a checklist of what “we have a policy” is missing, it is the most useful free document in this field.

It ages quietly. Your supplier register is accurate on the day it is built and decays from there. Third-party evidence is where we see the sharpest drop-off, which is why we published the twelve questions worth sending your own vendors. A pack with no refresh date is a pack that will fail its second audit, not its first.

One more date worth holding: all ISO/IEC 27001:2013 certificates expired on 31 October 2025. Every valid certificate is now against the 2022 version — which is the version the European mappings are written to.

The 30-day build

Nothing here needs to be purchased.

Week 1 — list the nine artefacts and name one owner for each. One owner per artefact, not one owner for the pack; a single owner is a single point of failure and reads as such to an auditor.

Week 2 — tag each artefact with its three readers, and write one line per artefact answering the only question that matters: what would make this reader reject it?

Week 3 — fix the two that fail all three readers. In our engagements it is almost always the supplier register and the effectiveness evidence.

Week 4 — hand the pack to someone who did not build it, and ask them to find the gap. That is what an independent internal audit does, and it is the cheapest hour in the whole programme.

If the ISO 27001 ISMS is the machine, the evidence pack is what the machine is for. Build it once, tag it three ways, and the second and third regulator cost you a fraction of the first.