NIS2 vs ISO 27001 vs DORA: what overlaps, what does not

Three names come up in every European security conversation, and they are routinely treated as interchangeable: NIS2, ISO 27001 and DORA. They are three different kinds of object. NIS2 is a directive that Member States transpose into law and that binds entities in listed sectors. DORA is a regulation that applies directly to financial entities. ISO 27001 is a voluntary, certifiable standard for an information security management system that binds nobody unless a contract says so. This article maps where they overlap, where they do not, which one governs when two apply, and what each actually says about testing.

Three objects, not three versions of one thing

When NIS2 and DORA both seem to apply: lex specialis

Credit institutions and financial market infrastructures appear in NIS2 Annex I (sectors 3 and 4). A bank could read that as a double regime. The Directive resolves it in Article 4: where a sector-specific Union legal act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect to the NIS2 obligations, the corresponding NIS2 provisions do not apply. Article 2(10) adds that the Directive does not apply to entities exempted from DORA under DORA Article 2(4). For a financial entity, therefore, DORA governs ICT risk management, incident reporting and testing, and the matching NIS2 articles step back. The ACPR's DORA page is the French supervisor's entry point.

Two practical consequences. A bank's IT service provider is not relieved by Article 4: an MSP is an Annex I entity in its own right under NIS2 and, separately, an ICT third-party provider under DORA Articles 28 to 30 for its financial clients. And a fintech that is not a DORA financial entity (because it is exempt or not listed) is not thereby a NIS2 entity either; it is in NIS2 only if it is of a listed type, for example a cloud computing service provider.

Testing: the three texts say different things

This is where the comparison earns its keep, because "penetration test" appears in exactly one of the three.

• NIS2, Article 21(2)(f). Essential and important entities must adopt "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". The Directive never names a penetration test, a method or a frequency. A validated test is one means of producing that evidence; point (e) adds vulnerability handling and disclosure. Article 21(4) requires corrective measures "without undue delay" when non-compliance is found.
• DORA, Chapter IV (Articles 24 to 27). Financial entities must maintain a digital operational resilience testing programme; Article 24 requires appropriate tests on all ICT systems and applications supporting critical or important functions at least yearly, by independent testers. Article 25 lists the tests the programme includes, and "penetration testing" is named explicitly among them. Article 26 adds threat-led penetration testing (TLPT) at least every three years for entities identified by their authority, with Article 27 setting the requirements for testers. TLPT is a supervised regime with authority-validated scope and external testers; Darkmoon supports the general Article 24 and 25 programme and its evidence, not the TLPT itself.
• ISO/IEC 27001. The standard requires a risk assessment, a treatment plan, internal audits and management review, and refers to the Annex A controls, among them management of technical vulnerabilities and security testing in development. It does not mandate a penetration test either; a test is a common way to satisfy the controls an organisation has selected and to feed the internal audit.

What overlaps

• Risk-based governance. All three start from a risk analysis owned by management. NIS2 Article 20 makes management bodies approve and oversee the measures; DORA Article 5 does the same for the ICT risk-management framework; ISO 27001 clause 5 makes leadership accountable for the ISMS.
• Supply-chain security. NIS2 Article 21(2)(d), DORA Chapter V on ICT third-party risk, and the ISO 27001 supplier-relationship controls address the same reality: your provider's weakness is yours.
• Incident handling. NIS2 Article 21(2)(b) and Article 23 (24-hour early warning, 72-hour notification, final report within one month), DORA Chapter III on ICT-related incident reporting, and ISO 27001's incident-management controls.
• Evidence. Each regime asks the organisation to show, not tell. An ISO 27001 ISMS is often the vehicle an entity uses to organise its NIS2 or DORA evidence, which is why the three get conflated.

What does not overlap

• A certificate is not compliance. ISO 27001 certification proves an ISMS exists and is audited against the standard's requirements. It does not prove that NIS2 Article 21 measures are appropriate and proportionate for the entity, nor that DORA's testing programme ran. Authorities assess the measures, not the certificate, although a well-run ISMS makes the assessment far easier.
• Scope of application. NIS2 is sector- and size-based with national identification; DORA is entity-type-based and applies regardless of size, with proportionality and partial relief for microenterprises; ISO 27001 scope is whatever the organisation writes in its statement of applicability.
• Prescriptiveness of testing. DORA prescribes what, how often and by whom. NIS2 and ISO 27001 leave that to the entity, then judge the result.
• Enforcement. NIS2 fines are set by national law (at least €10 M or 2 % of worldwide turnover for essential entities, at least €7 M or 1.4 % for important ones, as maxima); DORA sanctions come from financial supervisors; losing an ISO certificate has only the consequences your contracts attach to it.

Where a validated penetration test fits in each

The same test report serves three different files. Under NIS2 it is Article 21(2)(f) evidence that the measures were assessed, and Article 21(2)(e) evidence of vulnerability handling. Under DORA it is one of the Article 25 tests of the Article 24 programme, provided the tester is independent and the systems supporting critical or important functions are covered. Under ISO 27001 it supports the technical-vulnerability and security-testing controls and gives the internal auditor something concrete. What all three need from the report is the same: scope and dates, a method, findings qualified by what was actually demonstrated, and a remediation and retest record. Darkmoon qualifies each finding EXPLOITED, CONFIRMED or UNCONFIRMED with the evidence kept, and its Pro reports carry CVSS 3.1, MITRE ATT&CK and ISO 27001 mappings, with recurring campaigns so the record is a series rather than a single date. We go deeper in Darkmoon and NIS2: turning autonomous offensive validation into evidence and in Continuous pentesting for NIS2 and DORA.

France, as of 4 October 2026

DORA has applied since 17 January 2025 and is supervised by the ACPR and the AMF. ISO 27001 applies to whoever adopts it. NIS2 is not yet transposed: the bill transposing CER, NIS2 and the DORA directive was adopted by the Sénat in first reading on 12 March 2025 and is scheduled for public session at the Assemblée nationale on 7 October 2026; the law is not promulgated (legislative file). ANSSI offers pre-registration and a self-assessment on messervices.cyber.gouv.fr/nis2. Our NIS2 guide tracks the sector lists, the size rule and the transposition.

Where to start

If you are a NIS2 entity or supplier, start with the NIS2 guide. If you are a financial entity under DORA, the financial services page explains what Darkmoon supports in the Article 24 and 25 programme and what it does not claim about TLPT; our trust page covers how the platform itself is built and hosted. For an organisation that wants the test run for it, with the legal framework, scoping call, report and debrief handled by ASC-IT's experts, Pentest on Demand is a flat €799 per engagement, indicative and adjusted to the final scope.