Regulation
NIS2, DORA and ISO 27001: which testing evidence satisfies which
Organisations carrying two or three of these frameworks tend to run two or three testing programmes. That is usually unnecessary. The obligations overlap heavily on substance and differ mostly on evidence format, independence and cadence.
A European financial-services SaaS company can plausibly be subject to NIS2 as an important entity, to DORA as an ICT third-party provider's customer or as a financial entity itself, and to ISO 27001 because customers demand the certificate. Three frameworks, one budget. The good news is that they ask for the same underlying thing in different registers.
What each one actually says about testing
| NIS2 | DORA | ISO 27001:2022 | |
|---|---|---|---|
| Legal nature | Directive — binding via national law | Regulation — directly applicable | Voluntary standard, contractually enforced |
| Testing wording | Policies and procedures to assess effectiveness of measures; vulnerability handling | Digital operational resilience testing programme; TLPT where designated | Annex A 8.8 technical vulnerability management; 8.29 security testing in development and acceptance |
| Prescribed frequency | None stated in the directive | At least yearly for critical systems; TLPT at least every three years | None stated; determined by your risk assessment |
| Independence | Not specified | Independent parties, conflicts of interest managed | Implied through competence and objectivity requirements |
| Who checks | National supervisory authority | Competent financial authority | External certification body |
| Failure consequence | Administrative fines, management liability | Supervisory measures and sanctions | Nonconformity, potentially loss of certificate |
Where a single programme covers all three
The overlap is larger than the differences. A test that produces reproducible findings, a dated remediation record and a verified retest satisfies the substantive expectation of all three. What differs is packaging.
- ISO 27001 auditors want to see the process working — a documented method, evidence that findings entered your vulnerability management process, and evidence of closure. They care less about how deep the test went than about whether the management system handled the output.
- NIS2 supervision wants to see that measures are effective and that management approved a factual risk position. Depth matters more here, because the question is about outcome rather than process.
- DORA supervision wants coverage of critical or important functions, independence of testers, and full remediation of findings. It is the most prescriptive on cadence and on who may perform the work.
Where you genuinely cannot consolidate
DORA TLPT
If you have been designated for threat-led penetration testing, nothing substitutes for it. It runs against production, requires an external threat intelligence provider, involves the competent authority throughout, and ends in an attestation. It also generates evidence far exceeding what NIS2 or ISO 27001 need, so the reverse mapping works well — a TLPT will comfortably support both.
ISO 27001 development-lifecycle testing
Annex A 8.29 covers security testing during development and acceptance. This is not the same as an annual assessment, and auditors notice when organisations try to substitute one for the other. It is a pipeline concern — testing in CI, security acceptance criteria before release — and it is evidenced from your engineering system, not from a consultancy report.
NIS2 incident reporting rehearsal
The 24-hour early warning obligation has no analogue in ISO 27001 and a different shape under DORA. Evidence that you can meet it comes from a timed exercise, not from a vulnerability assessment. Budget for it separately.
A consolidated annual programme
| Activity | Cadence | Covers |
|---|---|---|
| External and authenticated internal assessment of critical systems | Annual | NIS2 effectiveness, DORA yearly testing, ISO 8.8 |
| Retest of high and critical findings | Per remediation cycle | All three — this is the closure evidence |
| Security testing in the delivery pipeline | Continuous | ISO 8.29, supports NIS2 vulnerability handling |
| Supplier and third-party access review | Semi-annual | NIS2 supply chain, DORA third-party register, ISO A.5.19–5.22 |
| Timed incident exercise | Annual | NIS2 reporting readiness, DORA response, ISO A.5.24–5.27 |
| Threat-led penetration testing | Every three years if designated | DORA only — but supports the other two |
The three mistakes that cost the most
- Buying separate tests per framework. The technical work is the same. Only the mapping differs, and mapping is a document, not an engagement.
- Treating certification as compliance. An ISO 27001 certificate is evidence that a management system exists. It is not a defence under NIS2 or DORA, and no supervisory authority treats it as one.
- Leaving remediation unverified. Every one of these frameworks cares about closure. An unverified fix produces zero evidence under all three, which makes retesting the highest-yield line item in the entire programme.
Frequently asked questions
Does ISO 27001 certification satisfy NIS2?
No. ISO 27001 certification demonstrates that an information security management system exists and is audited, and it is useful supporting evidence. NIS2 obligations attach to the entity under national law and are supervised by a national authority, which assesses the effectiveness of your measures rather than the existence of a certificate.
Can one penetration test satisfy NIS2, DORA and ISO 27001?
The technical work usually can, provided the scope covers the systems each framework cares about, the testers are sufficiently independent for DORA, and findings flow into a documented remediation and retest process. What differs is the evidence packaging, which is best handled with a mapping appendix produced at the time of the test.
How often does ISO 27001 require penetration testing?
ISO/IEC 27001:2022 does not specify a frequency. Annex A 8.8 requires timely information about technical vulnerabilities and appropriate measures to address them, with the cadence driven by your risk assessment. Annual testing of internet-facing and business-critical systems is the common interpretation, and auditors will ask you to justify whatever you chose.
Talk to the team
Need this tested rather than described?
QuietHours is a European cybersecurity practice operated by the securIT team. Send us the system, service, or control you are concerned about and we will help turn it into a workable scope.
Discuss your scope