NIS2 vs DORA scope overlap for WordPress agencies in 2026

#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.

#Decision tree: NIS2, DORA, or both?

The rule above (“DORA for finance, NIS2 for everything else”) holds for the obvious cases. It breaks down for the cases that actually take an afternoon to scope: a fintech below the significant-entity threshold, a hospital group with a payments subsidiary, or an agency that has never signed anything with the word “NIS2” in it but discovers a supply-chain clause buried in an appendix. The flowchart below is the walk-through we use on a new-client intake call, before any contract review starts.

flowchart TD
    A["Is your client a financial entity under DORA Article 2?"] -->|"Yes"| B["Is it a bank, investment firm, payment institution, insurer, asset manager, or PSD2 TPP?"]
    A -->|"No"| C["Is the client in a NIS2 Annex I or II sector: energy, transport, health, water, digital infrastructure, public administration, postal, waste, or manufacturing?"]
    B -->|"Yes"| D["DORA primary: build Register of Information, TLPT readiness, concentration risk analysis"]
    B -->|"No - below threshold or exempt"| C
    C -->|"Yes"| E["NIS2 primary: build Article 21 risk register, Annex II evidence trail, national transposition delta"]
    C -->|"No"| F["Is your agency contracted by an entity that is itself in scope, i.e. you are an ICT third-party supplier?"]
    F -->|"Yes - client is DORA scope"| G["Supply-chain pull-in under DORA Article 28: client contract clauses flow down DORA-grade obligations"]
    F -->|"Yes - client is NIS2 scope"| H["Supply-chain pull-in under NIS2 Article 21(2)(d): client contract clauses flow down NIS2-grade obligations"]
    F -->|"No"| I["Neither regime applies directly or indirectly: monitor client growth and sector reclassification annually"]
    D --> J["Does the group have non-finance subsidiaries that also use the agency?"]
    E --> J
    J -->|"Yes"| K["Mixed-regime holding: keep DORA-grade evidence as the ceiling and map subsidiaries individually"]
    J -->|"No"| L["Single-regime evidence trail is sufficient"]

Two branches are where agencies most often get the answer wrong. First, the “No - below threshold or exempt” branch out of B: a client can be a financial entity under DORA Article 2 and still not be a bank or insurer in the everyday sense - crowdfunding service providers and some payment institutions land here, and they do not stop being DORA entities just because they are small. Second, the F branch: an agency with zero regulated clients on paper can still be pulled into DORA obligations if one of its hosting or maintenance sub-contracts sits underneath a regulated entity’s supply chain, several tiers removed.

#Applicability matrix

Six client archetypes an agency is likely to encounter, mapped to primary regime, how the obligation reaches the agency, and the evidence trail grade that scoping call should end with.

The pattern that trips up new scoping calls: once one client relationship anywhere in an agency’s book is DORA-scope, it is operationally cheaper to build every evidence trail to DORA grade and downscale for NIS2-only clients than to maintain two parallel documentation systems.

#Two anonymized scoping cases

Details below are composited and stripped of identifying specifics; no client names appear anywhere in this section.

Case A: regional cooperative bank. A cooperative bank with roughly 40 branches across a single region outsourced its corporate website and an internal staff intranet, both WordPress-based, to an external agency. The bank is a financial entity under DORA Article 2 without qualification - the “cooperative” structure does not change that. The scoping call confirmed the agency needed to appear in the bank’s Register of Information as an ICT third-party service provider, specifically in table B.02.01 (contractual arrangements) and B.05.01 (functions supported), even though the bank’s size kept it below the threshold for advanced threat-led penetration testing. The agency still had to answer the concentration-risk question under Article 29 - “who else could take over hosting and maintenance within eight weeks” - because the bank’s compliance officer needed that answer on file regardless of TLPT status. The resulting evidence trail folder structure mirrored the 05_dora_register/ layout described later in this article, populated from day one of the engagement rather than backfilled before an audit.

Case B: municipal hospital group. A group of municipal hospitals running a shared patient-information portal and a staff-facing intranet, both WordPress-based, contracted the same evidence-trail approach but landed on the opposite side of the tree. Hospitals sit in NIS2 Annex I (health sector) and the group had no financial-entity status anywhere in its structure, so DORA never entered the picture. No Register of Information schema was built - it would have been wasted effort, since the fifteen-table RoI format is a DORA-specific requirement with no NIS2 equivalent. Instead, the agency built a simpler supplier register plus a due-diligence questionnaire and an incident-notification SLA clause tied to the hospital’s national NIS2 transposition (which set its own reporting deadlines and competent authority, distinct from the 24h/72h/1-month rhythm used elsewhere in this pillar). The practical lesson from comparing the two cases side by side: the DORA-scope client cost roughly twice the initial documentation effort of the NIS2-scope client, almost entirely because of the Register of Information schema, and that cost gap is the single best predictor of which grade of evidence trail to quote for a new engagement.

#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

#Decision matrix for a real WordPress engagement

Start with the legal entity, regulated service and jurisdiction, then map the WordPress asset to the function it supports. Record whether NIS2, DORA, both or neither appears applicable, who made that assessment and which national rule was checked. The agency supplies technical facts; the client and its advisers own the legal classification.

Where both regimes touch the same financial service, do not run two unrelated control programmes. Treat DORA as the sector-specific baseline where its provisions govern, while retaining NIS2 and national-law deltas that remain relevant. This is a scoped analysis, not a blanket statement that one act always cancels the other.

Reuse evidence only when scope, owner, period and acceptance criteria match. The same restore test may support both mappings; the DORA register template and regulator-facing incident form remain separate. Give each control a client owner, agency owner, reviewer, evidence location and refresh trigger. A gap register should distinguish missing implementation, missing proof and unresolved legal interpretation.

Accept the mapping when every in-scope control has evidence or a documented gap, shared artefacts are cross-referenced rather than copied, and residual risk has an owner. Review after architecture, supplier, service or law changes. The matrix is neither certification nor a guarantee against incidents.

Send the entities, jurisdictions, service description, architecture, suppliers, existing control map and deadline in a written brief. Our NIS2 and DORA readiness service can build the overlap matrix and evidence-gap plan without replacing legal advice.

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.

#Cross-references

• NIS2 Annex II for WordPress agencies: evidence trail
• DORA Article 28 ICT third-party risk for WordPress
• DORA Register of Information for WordPress vendors: required fields
• NIS2 incident reporting timeline 24h/72h/1M
• NIS2 and DORA on WordPress pillar
• EU compliance audit for WordPress