NIS2 vs DORA scope overlap for WordPress agencies in 2026
Directive 2022/2555 (NIS2) and Regulation 2022/2554 (DORA) cover similar ground but with different mechanics. NIS2 is a directive transposed by each Member State into national law. DORA is a regulation that applies directly. NIS2 covers a broad set of essential and important sectors. DORA is finance-specific. Where they overlap (most of risk management, incident handling, supply chain), one well-built evidence trail can satisfy both. Where DORA goes further (Register of Information, threat-led penetration tests), the WordPress agency needs to add the deltas.
This is a supporting article inside the NIS2 and DORA on WordPress pillar, with cross-references to the Annex II evidence trail, the DORA Article 28 third-party guide, the Register of Information field guide and the 24/72/30 incident timeline.
TL;DR
- DORA is lex specialis for financial entities; NIS2 applies elsewhere.
- Overlap: risk management, incident handling, business continuity, supply chain, reporting.
- DORA-only: Register of Information schema, TLPT for critical entities, prescriptive third-party clauses.
- NIS2-only: broader sectoral scope (energy, transport, health, public administration), national transposition variants.
- Practical rule: if any client is under DORA, build the evidence trail to DORA grade and downscale for NIS2.
How NIS2 itself names DORA
Article 1(2) of NIS2 says: where sector-specific Union legal acts require essential or important entities to manage cybersecurity risks or to notify significant incidents, those sector-specific provisions apply. DORA is one of those acts. So a financial entity in scope of DORA does not double-comply: it complies with DORA, and the equivalent NIS2 provisions are deemed met.
What DORA does not address explicitly (e.g. parts of NIS2 management body responsibility, training, sector-shared CSIRT cooperation), the NIS2 baseline still covers.
For a WordPress agency this means: if your client is a bank, an investment firm, a payment institution, an insurer, an asset manager, a TPP under PSD2 - DORA dominates. Build to DORA. If your client is a hospital, a TLD registry, an energy distributor, a postal operator - NIS2 dominates. Build to NIS2.
What overlaps
Five large overlap areas where a single artefact serves both regimes:
Risk management. NIS2 Article 21 lists ten measures; DORA Articles 5-15 cover the same conceptual ground in more detail. A risk register that names assets, threats, likelihood, impact and treatment satisfies both. Detail level differs: DORA expects more granularity for critical or important functions; NIS2 expects proportionality.
Incident handling. NIS2 Articles 22-23 and DORA Articles 17-23 both demand classification, response, recovery, post-mortem and reporting. The reporting deadlines differ slightly (NIS2: 24h early warning, 72h notification, 1-month final report; DORA: similar but with sector-specific templates). The internal incident response runbook can be shared.
Business continuity. NIS2 Article 21(2)(c) and DORA Article 11 both demand backup, restore-tested, off-site, with documented RPO and RTO. One BCDR plan with one annual restore drill log satisfies both.
Supply chain controls. NIS2 Article 21(2)(d) and DORA Article 28 both demand supplier register, due diligence, contract clauses, exit plan. The DORA Register of Information is a stricter schema; building to DORA gives you NIS2 supply chain compliance for free.
Reporting. Both demand competent-authority reporting. NIS2 designates national CSIRT and competent authority; DORA reports to the financial regulator (national plus ESAs). The internal evidence prep is the same; the addressee is different.
What DORA adds on top
Three deltas where DORA goes further than NIS2 and the WordPress agency must add specific evidence:
Register of Information schema. Commission Implementing Regulation 2024/2956 specifies fifteen tables with named columns. Covered in detail in the Register of Information field guide. NIS2 has no equivalent; the agency under NIS2-only obligations does not need this schema.
Threat-led penetration testing. DORA Article 26 requires advanced TLPT for financial entities classified as significant. The agency operating critical infrastructure for such an entity may be in scope as a tested system. NIS2 mentions vulnerability handling broadly but not TLPT.
Concentration risk and substitutability. DORA Article 29 demands explicit concentration analysis: how many critical functions does this third party support, and how easily can it be replaced. The agency must be able to answer “who else can do this work in eight weeks if we disappear”. NIS2 has no equivalent prescriptive demand.
What NIS2 adds on top
Two deltas where NIS2 reaches further than DORA in non-finance contexts:
Sectoral breadth. Hospitals, ISPs, telecom carriers, postal services, food production, public administration, research organisations are in NIS2. Most are not in DORA. The agency working across these clients must keep one NIS2-shaped trail per client sector.
National transposition variants. Because NIS2 is a directive, each Member State implements details with local flavour. The German implementation (KRITIS-DachG / NIS2UmsuCG) differs from the Polish (KSC) which differs from the Norwegian. The agency operating cross-border keeps a small per-jurisdiction delta document.
One evidence trail, both regimes
A practical evidence trail layout that covers both:
00_governance/- risk register, management body sign-off, review cadence.01_risk_management/- Article 21 / Article 5 mapping, controls, evidence files.02_incident_response/- runbook, tabletop drills, post-mortems, 24/72/30 templates.03_business_continuity/- backup policy, restore test logs, BCDR plan.04_supply_chain/- supplier register, sub-processor list, due diligence files.05_dora_register/- Register of Information inputs (15 tables) for DORA clients.06_reporting/- past reports, addressee log, deadline log.07_jurisdictions/- per-Member-State NIS2 transposition deltas.08_tlpt/- for DORA significant entities, threat-led pen-test reports and remediation.
Build it once, iterate quarterly, and the next supplier review takes hours not weeks.
