Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress
Three EU acts converged on the same operational substance between 2024 and 2026. The Cyber Resilience Act (Regulation (EU) 2024/2847) regulates products with digital elements placed on the EU market. The NIS2 Directive (2022/2555) regulates entities providing essential or important services. The DORA Regulation (2022/2554) regulates financial entities and the ICT third-party providers they rely on. A headless WordPress build for a regulated entity that ships a commercial component lands under all three at once. The good news: one evidence pack can satisfy all three if structured by control rather than by act.
This article is the closing piece of the NIS2 and DORA on WordPress pillar and ties together the Annex II evidence trail, DORA Article 28 supplier audit, 24-hour incident playbook, and BFSG vs EAA accessibility piece.
TL;DR
- CRA = product regulation. NIS2 = entity regulation. DORA = financial-entity regulation.
- Headless WordPress for regulated entities can sit under all three.
- One evidence pack mapped by control beats three separate paper trails.
- CRA reporting obligations from 2026, full manufacturer obligations from 2027.
- NIS2 from 2024-10-17 transposition deadline; DORA from 2025-01-17 direct application.
Why headless WordPress is the intersection point
A headless WordPress build separates two layers. The content layer runs WordPress as the editor and source of truth, exposing content through the REST API or GraphQL. The presentation layer runs a frontend framework (Next.js, Astro, Nuxt, SvelteKit) consuming that content and rendering for end users.
For compliance the headless split changes the risk surface in three ways:
The frontend is a product. A Next.js application bundled with commercial libraries, deployed by an agency, may be a “product with digital elements” under the CRA when sold or licensed to a financial entity. WordPress itself, as free open-source software released by a community, is not in CRA scope per recital 15 of Regulation (EU) 2024/2847; commercial bundles built on top can be.
The supply chain is wider. Headless builds bring in npm dependencies (often hundreds), CDN edge functions, image-optimisation services, search providers, comment systems. NIS2 Article 21(2)(d) and DORA Article 28(2) both require this chain to be inventoried, classified, and contractually controlled.
The incident surface is split. A vulnerability can sit in the WordPress backend, in the frontend bundle, in an edge function, or in a third-party API. The 24-hour NIS2 clock and the DORA reporting timelines apply to the entity regardless of where the bug lives. The agency runbook needs to detect and triage across all four layers.
What each act actually demands
CRA (Regulation (EU) 2024/2847)
Covers products with digital elements placed on the EU market. Article 13 sets manufacturer obligations: cybersecurity by design and by default, vulnerability handling for the support period, security updates, software bill of materials (SBOM), reporting of actively exploited vulnerabilities to ENISA within 24 hours of awareness, reporting of severe incidents within 24 hours of awareness.
Application schedule per Article 71:
- Vulnerability and incident reporting obligations from 2026.
- Full manufacturer obligations from 2027 (36 months after entry into force).
- Conformity-assessment requirements for “important” and “critical” products with digital elements have separate paths.
Open-source software developed and supplied without commercial activity sits outside the CRA scope. The recitals draw a distinction between non-commercial open-source contribution and commercial bundling. WordPress core itself is non-commercial open source; a managed-WordPress-as-a-product offering with bundled premium plugins under a single licence may cross into CRA scope.
NIS2 (Directive 2022/2555)
Covers entities (essential and important) listed in Annex I and Annex II. Article 21(2) lists ten risk-management measures (covered in detail in the Annex II evidence trail article). Article 23 sets the 24-hour early warning, 72-hour notification, one-month final report (covered in the 24-hour incident response playbook). Article 21(2)(d) pulls suppliers into scope through contractual obligations.
Transposition deadline was 2024-10-17. Several member states delayed; check national status before any final audit.
DORA (Regulation 2022/2554)
Covers financial entities listed in Article 2 and the Critical ICT Third-Party Providers (CTPPs) designated by the European Supervisory Authorities. Article 28 covers ICT third-party risk management (covered in the DORA Article 28 supplier audit article). Articles 16 to 19 cover the ICT incident management lifecycle. Article 24 to 27 cover digital operational resilience testing including TLPT.
Applies directly from 2025-01-17 across the EU.
Where the three acts overlap
A headless WordPress engagement for a financial entity that ships a commercial frontend bundle hits the following overlaps:
| Control area | CRA reference | NIS2 reference | DORA reference |
|---|---|---|---|
| Vulnerability handling | Article 13 (manufacturer obligations) | Article 21(2)(e) | Article 16, Article 17 |
| Security updates | Article 13 (support period) | Article 21(2)(e) | Article 8 (ICT systems maintenance) |
| Software bill of materials | Article 13 (SBOM) | Article 21(2)(e) (acquisition and development) | Article 8 |
| Incident reporting | Article 14 (severe incidents to ENISA, 24 h) | Article 23 (24/72/30) | Article 19 (financial-entity timelines) |
| Supply chain | Annex I Section II (manufacturer due diligence) | Article 21(2)(d) | Article 28 (third-party risk management) |
| Risk management | Article 13(1) | Article 21(2)(a) | Article 6 (ICT risk management framework) |
| Authentication | Article 13(1) (security by default) | Article 21(2)(j) (MFA) | Article 8 (information security) |
| Cryptography | Annex I Section I | Article 21(2)(h) | Article 9 (data protection) |
Eight overlapping controls. One pack of evidence with eight folders, each cross-referenced to all three regulations, satisfies them all.
What the joint evidence pack looks like
I structure the pack by control area, not by regulation. Each control folder contains:
- Policy. Approved by the entity’s management body. Cross-referenced to the relevant CRA / NIS2 / DORA articles.
- Process owner. Named role at the entity, plus the agency’s named contact.
- Implementation evidence. Logs, audit reports, scan outputs, test results, contract clauses.
- Mapping table. Three columns: CRA article, NIS2 article, DORA article. Where the policy sits in each.
- Review record. Annual or more frequent review, dated, signed.
- Audit history. External audits, penetration tests, regulator queries, all dated and tagged.
The joint pack avoids the most common waste in multi-act compliance: writing the same risk register three times to cover three regulators. One register, three article references in the metadata.
Headless-specific evidence the joint pack must include
A headless build adds artefacts that a monolithic WordPress engagement does not need:
- SBOM for the frontend bundle. A CycloneDX or SPDX file listing every npm dependency with version and licence. Generated by
npm audit signaturesplus a CycloneDX generator. The SBOM is a CRA Article 13 deliverable; under NIS2 and DORA it serves vulnerability handling. - SBOM for the WordPress backend. Plugin and theme inventory with version and licence. WordPress.org plugin checker plus internal version lock files.
- Edge-function inventory. Cloudflare Workers, Netlify Functions, Vercel Edge. Each function is a piece of the supply chain and a piece of the incident surface.
- API contract documentation. OpenAPI or GraphQL schema for the headless API, with security definitions, rate limits, authentication.
- Frontend deployment pipeline evidence. CI/CD logs, container scan results, secret-scanning evidence, dependency review on every PR.
- Cross-layer monitoring. A single dashboard or runbook that correlates events from WordPress backend, frontend application, edge layer, and third-party APIs.
For a regulated entity, this artefact set is mandatory. For an unregulated entity, it is good practice, but the budget conversation gets tighter.
Where the joint pack still falls short
Three areas where one pack does not cover everything:
Conformity assessment under CRA. “Important” and “critical” products with digital elements need a third-party conformity assessment under CRA Annex VII. NIS2 and DORA do not have an equivalent third-party certification baseline (DORA’s TLPT is the closest). Plan for the conformity assessment as a separate workstream.
TLPT under DORA Article 26. Threat-led penetration testing for designated significant financial entities follows the TIBER-EU framework. NIS2 and CRA do not require this depth of testing.
Sector-specific supervision. NIS2 has sector competent authorities. DORA has the Joint Examination Teams under Article 31. CRA has market surveillance authorities under Annex VIII. Three different supervisor channels still need separate communication processes.
What this means for the engagement model
A WordPress agency that wants to ship headless builds to regulated entities in 2026 needs to:
- Build the joint evidence pack template once and re-use across engagements.
- Generate SBOMs as part of the deployment pipeline, not as an afterthought.
- Keep the supplier register up to date as a living document.
- Maintain incident-response readiness across both layers (WordPress and frontend).
- Stay current on CRA implementation acts as ENISA publishes them through 2026.
Pricing is individual; the compliance scope drives the engagement length, not a fixed per-month retainer.
Cluster reading
- Pillar: NIS2 and DORA on WordPress: 2026 compliance stack
- NIS2 Annex II for WordPress agencies: scope, deadlines, evidence trail
- DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit
- WordPress incident response under NIS2: 24-hour early warning playbook
- BFSG vs EAA: Germany’s Accessibility Strengthening Act 2025 deadline for WordPress shops
