Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress

#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 that ships a commercial component to a regulated client lands under the CRA on the product side and under NIS2 or DORA on the entity side. For a financial entity, DORA replaces the NIS2 risk-management and reporting rules rather than adding to them. The good news: one evidence pack can satisfy all of it 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.

#CRA, NIS2 and DORA compliance stack in short

• CRA = product regulation. NIS2 = entity regulation. DORA = financial-entity regulation.
• A headless WordPress build can meet the CRA through its commercial components and NIS2 or DORA through the client that runs it.
• For financial entities DORA applies instead of NIS2 Articles 21 and 23 (NIS2 Article 4 and recital 28).
• One evidence pack mapped by control beats three separate paper trails.
• CRA reporting obligations from 11 September 2026, full application from 11 December 2027.
• NIS2 from the 2024-10-17 transposition deadline; DORA from 2025-01-17 direct application.

#How headless WordPress affects CRA, NIS2 and DORA compliance

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 can be 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 it is supplied in the course of a commercial activity. WordPress itself, as free open-source software released by a community, is not in CRA scope when it is not monetised by its makers (recitals 15 and 18 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) asks in-scope entities to secure their relationships with direct suppliers, and DORA Article 28(3) requires financial entities to keep a register of information on every contractual arrangement for ICT services. Both push this chain towards an inventory with contractual controls.

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 CRA, NIS2 and DORA each require

#CRA (Regulation (EU) 2024/2847)

Covers products with digital elements placed on the EU market. Article 13 sets manufacturer obligations: a documented cybersecurity risk assessment (Article 13(2) and 13(3)), the essential requirements of Annex I Part I such as secure by default configuration, vulnerability handling for the support period under Annex I Part II, security updates, and a software bill of materials (SBOM, Annex I Part II point 1). Article 14 adds reporting: actively exploited vulnerabilities and severe incidents go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform of Article 16, with an early warning within 24 hours of awareness.

Application schedule per Article 71:

• Article 14 reporting obligations from 11 September 2026.
• Chapter IV on notified bodies (Articles 35 to 51) from 11 June 2026.
• Everything else, including the full manufacturer obligations, from 11 December 2027.
• Conformity-assessment requirements for “important” and “critical” products with digital elements have separate paths (Article 32).

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, points (a) to (j) (covered in detail in the Annex II evidence trail article). Article 23(4) 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 in indirectly: the entity has to cover supply chain security, including its relationships with direct suppliers and service providers, and Article 21(3) asks it to weigh each supplier’s own secure development practices.

Transposition deadline was 2024-10-17 (Article 41). 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 under Article 31. Articles 28 to 30 cover ICT third-party risk: the general principles, the register of information and exit strategies sit in Article 28 (covered in the DORA Article 28 supplier audit article), and the mandatory contract clauses sit in Article 30. Articles 17 to 19 cover the ICT-related incident management process, classification and reporting of major incidents. Articles 24 to 27 cover digital operational resilience testing including TLPT.

Applies directly from 2025-01-17 across the EU (Article 64).

#Does NIS2 still apply when DORA covers a financial entity

Not for the parts that matter here. NIS2 Article 4(1) switches off its own risk-management, reporting and supervision provisions wherever a sector-specific EU act imposes requirements at least equivalent in effect. Recital 28 of NIS2 names DORA as that act for financial entities: DORA’s rules on ICT risk management, incident reporting, resilience testing, information sharing and ICT third-party risk apply instead of NIS2’s.

For a headless WordPress engagement this splits the client base in two:

• A bank, insurer, payment institution or investment firm works under DORA. The evidence pack maps to DORA articles, and incident reports go to the financial competent authority under DORA Article 19.
• A hospital, energy company, public administration body or other Annex I or II entity works under the national NIS2 law. The evidence pack maps to Article 21(2), and incident reports go to the CSIRT or competent authority under Article 23.

The CRA sits across both: if the agency ships a commercial product, its manufacturer obligations apply whichever regime the client is under. The overlap table below therefore has a NIS2 column and a DORA column, but a single engagement fills one of them, not both.

#When the agency itself falls under NIS2

NIS2 does not only reach the client. Annex I, point 9 lists “ICT service management (business-to-business)”, which covers managed service providers and managed security service providers. Article 6(39) defines a managed service provider as an entity that provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure or applications, by assistance or active administration on the customer’s premises or remotely.

An agency that runs hosting, updates and monitoring for client WordPress installations under a care plan matches that description. The size test in Article 2(1) decides whether it is in scope: the directive applies to entities that qualify as medium-sized enterprises under Commission Recommendation 2003/361/EC or exceed those ceilings. Under Article 2 of that Recommendation a small enterprise has fewer than 50 staff and turnover or balance sheet up to EUR 10 million, so an agency with 50 or more staff on a managed hosting line is the case to check. Once in scope, it needs its own Article 21 measures and its own Article 23 reporting line, separate from the clients’.

#Is a headless WordPress site a product under the CRA

Usually not, and the regulation says so. Recital 12 of the CRA states that websites which do not support the functionality of a product with digital elements fall outside its scope, and that cloud services such as SaaS, PaaS and IaaS are covered by NIS2 instead. A marketing site or an online banking front running on headless WordPress is a website operated as a service, not a product placed on the market.

The CRA enters through three narrower doors:

• A commercial product sold to many clients. A premium theme, a paid plugin or a licensed frontend starter kit supplied in the course of a commercial activity is a product with digital elements (Article 3(1)).
• An app with its own backend. Article 3(2) and recital 11 treat “remote data processing” built by or for the manufacturer, without which the product cannot perform a function, as part of the product. When a mobile app ships with a custom WordPress REST endpoint it depends on, that endpoint is inside the app’s CRA scope.
• Open-source components inside a commercial product. Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source ones, and Article 13(6) requires them to report a vulnerability found in a component to whoever maintains it.

None of the product types in Annex III (important products) or Annex IV (critical products) is a CMS, theme or web frontend. A typical WordPress product therefore uses the internal control procedure (module A in Annex VIII), not a notified body.

#How the CRA, NIS2 and DORA reporting clocks compare

Each act runs its own clock, starting at a different moment:

The DORA time limits come from Commission Delegated Regulation (EU) 2025/301, not from DORA itself. One practical consequence for a headless stack: the frontend agency that is also a CRA manufacturer can owe its own 24-hour report to ENISA about the same vulnerability the bank is reporting to its supervisor. The two reports should reference each other and the runbook should name who files which.

#Where CRA, NIS2 and DORA overlap

A headless WordPress engagement that ships a commercial frontend bundle hits the following overlaps. The NIS2 column applies to non-financial clients, the DORA column to financial ones:

Eight overlapping controls. One pack of evidence with eight folders, each cross-referenced to the CRA and to the regime the client sits under, satisfies them all.

#How to structure a joint CRA, NIS2 and DORA evidence pack

I structure the pack by control area, not by regulation. Each control folder contains:

1. Policy. Approved by the entity’s management body. Cross-referenced to the relevant CRA / NIS2 / DORA articles.
2. Process owner. Named role at the entity, plus the agency’s named contact.
3. Implementation evidence. Logs, audit reports, scan outputs, test results, contract clauses.
4. Mapping table. Three columns: CRA article, NIS2 article, DORA article. Where the policy sits in each.
5. Review record. Annual or more frequent review, dated, signed.
6. 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.

#What evidence a headless build needs for CRA, NIS2 and DORA

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. The npm CLI generates it with npm sbom --sbom-format cyclonedx (or spdx); npm audit signatures is a separate check that verifies registry signatures. The SBOM is a CRA Annex I Part II deliverable; under NIS2 and DORA it serves vulnerability handling and the asset inventory.
• SBOM for the WordPress backend. Plugin and theme inventory with version and licence. WP-CLI exports it with wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=json and wp theme list --format=json; the licence comes from each plugin’s header, 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.

#What a joint CRA, NIS2 and DORA pack does not cover

Three areas where one pack does not cover everything:

Conformity assessment under CRA. Under Article 32, important products of class I that do not apply harmonised standards, all important products of class II and critical products need the EU-type examination or full quality assurance procedures of Annex VIII, which involve a notified body, or a European cybersecurity certification scheme where one is available. 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 when the product falls into Annex III or IV.

TLPT under DORA Article 26. Threat-led penetration testing for designated financial entities runs at least every three years on live production systems, and the technical standards behind it follow 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 financial competent authorities of Article 46, plus a Lead Overseer assisted by a joint examination team (Article 40) for each critical ICT third-party provider. CRA has market surveillance authorities under Article 52. Three different supervisor channels still need separate communication processes.

#What fines CRA, NIS2 and DORA set

The ceilings differ because the acts regulate different parties:

• CRA Article 64. Breaches of the Annex I essential requirements or of Articles 13 and 14: up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher. Other operator obligations: up to EUR 10 million or 2 %. Incorrect or misleading information to notified bodies or market surveillance authorities: up to EUR 5 million or 1 %.
• NIS2 Article 34. Breaches of Article 21 or 23: a maximum of at least EUR 10 million or 2 % for essential entities, and at least EUR 7 million or 1.4 % for important entities. Member States may go higher.
• DORA Article 50. Amounts are left to Member States, which must give competent authorities sanctioning powers. For critical ICT third-party providers, Article 35 lets the Lead Overseer impose a daily periodic penalty payment of up to 1 % of average daily worldwide turnover, for up to six months.

For the agency the CRA line is the one that lands on its own balance sheet, because the agency is the manufacturer. The NIS2 and DORA penalties fall on the client, which is why clients push them down the chain through contract clauses.

#What CRA, NIS2 and DORA require from WordPress agencies

A WordPress agency that wants to ship headless builds to regulated entities in 2026 needs to:

1. Build the joint evidence pack template once and re-use across engagements.
2. Generate SBOMs as part of the deployment pipeline, not as an afterthought.
3. Keep the supplier register up to date as a living document.
4. Maintain incident-response readiness across both layers (WordPress and frontend).
5. Stay current on the implementing and delegated acts the Commission adopts under the CRA, and on ENISA’s single reporting platform before Article 14 applies on 11 September 2026.

Pricing is individual; the compliance scope drives the engagement length, not a fixed per-month retainer.

#Related CRA, NIS2 and DORA guides

• 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