NIS2 Annex II for WordPress agencies: scope, deadlines, evidence trail
Article 21 of Directive 2022/2555 is the operative clause that decides what an audit looks like. Annex I and Annex II decide who has to sit through that audit. This article maps the ten Article 21(2) measures to a WordPress agency control and the evidence file I expect to find when a regulated client asks for a supplier review.
This is a supporting article inside the NIS2 and DORA on WordPress pillar, with cross-references to the DORA Article 28 third-party guide and the 24-hour incident response playbook.
TL;DR
- Article 21(2) lists ten risk-management measures. None is optional.
- Annex I = essential entities. Annex II = important entities. Same measures, different supervision.
- Auditors look for four artefacts per measure: policy, owner, evidence record, review cadence.
- The penalty caps in Article 34 apply to the entity, not its WordPress vendor, but supply chain clauses flow the obligations downstream anyway.
- I keep one folder per Article 21 paragraph in every regulated-client engagement.
Who is in scope: Annex I vs Annex II
Annex I lists the essential entities: energy, transport, banking, financial market infrastructures, health, drinking and waste water, digital infrastructure, ICT service management (B2B), public administration, space. Annex II lists the important entities: postal and courier services, waste management, chemicals, food, manufacturing of medical devices, computers and electronics, machinery and motor vehicles, digital service providers, research organisations.
Both annexes apply to medium-sized entities and above (50+ employees, or annual turnover above 10 million EUR, or balance sheet above 10 million EUR). Microenterprises and small enterprises are out of direct scope unless they fall under one of the named exceptions in Article 2(2): trust service providers, TLD registries, certain DNS providers, public administration, providers of public electronic communications networks.
The practical filter for a WordPress agency: a hospital, a bank, a chemical plant, a data centre operator, a TLD registry, a UCITS manager. If the client is one of these, the scoping conversation starts. If the client is a hotel, a SaaS startup or a regional retailer, scoping usually ends in “out of scope, but security best practice still applies.”
Article 21(2): the ten measures
The directive text reads as ten lettered paragraphs from (a) to (j). Each one becomes a folder in my project workspace.
(a) Policies on risk analysis and information system security. A signed risk register listing assets, threats, likelihood, impact and treatment. For WordPress: list the production server, staging server, plugin set, third-party APIs (payment, email, analytics, AI), admin accounts and content database. Threats: plugin RCE, credential stuffing, ransomware on backups, GDPR breach via export. Treatment: update cadence, MFA, off-site encrypted backup, WAF rule set.
(b) Incident handling. Detection, classification, response, recovery, post-mortem. Evidence file: an IR runbook with named owners, the monitoring tool that triggers alerts (Wordfence, Sucuri, hosting-level IDS, Cloudflare alerts), the Slack or PagerDuty channel, the post-mortem template.
(c) Business continuity, including backup management and disaster recovery, and crisis management. Backup with off-site storage, RPO and RTO defined, restore tested. Crisis communication plan including who talks to the press and who talks to the regulator. Annual restore drill with a written report.
(d) Supply chain security, including security-related aspects concerning relationships between each entity and its direct suppliers or service providers. This is where the WordPress agency lands. The regulated entity must keep a register of suppliers, classify them by criticality, run due diligence, write security clauses into contracts. Cross-reference: DORA Article 28 has the same logic but stricter for finance.
(e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Documented secure development lifecycle. For WordPress: code review for custom plugins and themes, dependency scanning (Snyk, Dependabot, the WordPress.org plugin checker), vulnerability disclosure email, patch management policy.
(f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Internal audit, external audit or penetration test. Evidence: scope statement, test report, remediation tracker, retest record.
(g) Basic cyber hygiene practices and cybersecurity training. Annual training for all staff, role-specific training for admins. Evidence: training log with names, dates, content covered.
(h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption. TLS 1.3 at the edge, encryption of backups, encryption of database backups at rest. Hash algorithm policy (no MD5 or SHA-1). Cryptographic key inventory.
(i) Human resources security, access control policies and asset management. Joiner-mover-leaver process. Named admin accounts, no shared credentials. Asset inventory including all WordPress installs, staging environments, repository access, hosting console access. Quarterly access review.
(j) Use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems. MFA on every WordPress admin, every hosting console, every CDN console, every code repository, every email. No exceptions for “trusted internal users”.
The evidence trail: four artefacts per measure
For each of the ten paragraphs I expect to produce four artefacts when an auditor turns up:
| Artefact | What it looks like | Why it matters |
|---|---|---|
| Policy document | Approved by management, dated, version-controlled | Article 20 requires management approval and oversight |
| Process owner | A named role (CISO, Head of Engineering, Agency Director) | Auditors disqualify “the team” as ownership |
| Implementation record | Logs, screenshots, ticket numbers, scan reports, contract clauses | Demonstrates the policy is operating, not just written |
| Review cadence | Annual or quarterly review, calendar entry, minutes | Shelfware policy with no review = audit finding |
I run this four-column table for every Article 21(2) sub-paragraph. Ten paragraphs, forty artefacts. That is what an audit binder looks like in 2026.
Reporting deadlines from Article 23
Annex II is the steady-state list. When an incident actually happens, Article 23 applies:
- 24 hours from awareness: early warning to the CSIRT or competent authority.
- 72 hours from awareness: incident notification with initial assessment and indicators of compromise.
- 1 month from awareness: final report including root cause and applied remediation.
- Intermediate report on request from the regulator at any time.
The detailed playbook for those first 24 hours lives in the WordPress incident response under NIS2 article.
Penalty caps and management responsibility
Article 34 sets the upper caps national transpositions must respect:
- Essential entities: at least 10 million EUR or 2% of total worldwide annual turnover, whichever is higher.
- Important entities: at least 7 million EUR or 1.4% of total worldwide annual turnover, whichever is higher.
Article 20(1) puts the responsibility on management bodies, including the obligation to oversee implementation. Article 20(2) requires management to follow training. National transpositions can add personal liability sanctions for the named officer responsible.
Define the supplier scope before collecting evidence
The agency pack should start with a boundary statement. Name the contracting entity, client service, production sites, repositories, environments, integrations and suppliers that the agency actually operates. Separate responsibility for WordPress application code, hosting, DNS, CDN, identity, payment and editorial access. A tool appearing in the architecture does not automatically make the agency its control owner.
Record exclusions and assumptions alongside the scope. If the client operates its own identity provider or retains database access, say so. If the agency can deploy code but cannot approve production changes, record that split. The regulated client remains responsible for its NIS2 assessment and national-law obligations; the agency provides evidence about the service it supplies. This boundary prevents a supplier questionnaire from becoming an unsupported declaration about the client’s entire organisation.
A responsibility matrix procurement can test
Use a RACI-style matrix for every material activity, but write roles rather than vague team names. Include change approval, emergency deployment, vulnerability triage, privileged access, backup execution, restore approval, incident escalation, log review and supplier exit. Each row needs the client owner, agency owner, approver, evidence location and escalation route.
Pay attention to shared controls. The host may create backups, the agency may monitor completion and the client may decide the recovery objective. All three actions matter. Marking the control simply “hosting provider” hides the verification and decision responsibilities that remain with the other parties.
Review the matrix when the statement of work, architecture or personnel changes. A responsibility record signed at onboarding but never updated is weaker than a concise, current matrix linked to operational tickets.
Minimum evidence for changes, vulnerabilities and access
For changes, retain the request, risk assessment, peer review, test result, approval, deployment record and rollback outcome. Emergency changes need a shorter path, not an undocumented path: identify the authority, reason and retrospective review deadline. Link releases to code commits and production timestamps so an investigator can reconstruct what changed.
For vulnerabilities, preserve the source of the alert, affected asset and version, severity rationale, exposure, decision, remediation target and retest. A scanner export alone does not show whether the finding applied to production or whether an exception was accepted. When a plugin has no supported fix, record compensating controls and the replacement decision.
For access, keep named identities, role, business justification, approver, MFA status, grant date and latest review. Store evidence of removal for leavers and expired support accounts. Do not place credentials or recovery codes inside the audit pack; prove that the control exists without turning the evidence folder into a new security risk.
Backup and recovery evidence must prove restoration
A dashboard showing green backup jobs proves creation, not recoverability. Record what is copied, frequency, encryption, location, retention, failure alerts and who can restore it. Then run a restoration into an isolated environment and document start time, completion time, integrity checks, application test and deviations from the expected RPO and RTO.
Include dependencies outside the WordPress database: media, configuration, secrets, DNS, edge rules, scheduled jobs and deployment definitions. A database-only restoration may produce a site that loads but cannot send transactional mail or take payments. The acceptance record should state precisely which service was recovered and which dependencies were simulated or excluded.
Cadence, acceptance and limitations
Evidence needs an owner and refresh trigger. Access reviews may be quarterly; restoration and incident exercises may be annual or driven by material change; vulnerability and patch records operate continuously. Contract, architecture, provider or critical-plugin changes should trigger a targeted review rather than waiting for the calendar.
Accept an artefact when it is current, attributable, tied to the scoped control, stored in an agreed location and reviewed by the responsible party. Track gaps separately with risk, owner and due date. Never rewrite a missing record after the fact as though it existed at the time.
The pack demonstrates selected supplier controls for a stated period. It is not a NIS2 certification, a legal opinion or proof that the client meets every national requirement. It cannot guarantee that no incident will occur. These limitations should appear in the cover note so procurement and management understand what they can rely on.
Send a written brief for an evidence-trail review
For a useful estimate, send the contracting entities, service description, architecture, environments, critical integrations, existing supplier questionnaire, audit deadline and evidence already available. Do not send secrets in the initial message. Our NIS2 and DORA readiness service can scope the WordPress supplier pack, responsibility matrix, evidence gaps and acceptance review. Pricing follows the systems and artefacts in scope, and the engagement does not replace the client’s legal assessment.
What this means for the agency
A WordPress agency that wants to keep regulated clients in 2026 needs to ship two artefacts on every engagement:
- A self-attestation against Article 21(2)(d) supply chain clauses, listing the security measures the agency itself implements.
- A reference document the client can paste into its own Article 21 binder, showing how the WordPress engagement maps to each of the ten measures.
I bundle both into a “supplier security pack” and send it inside the proposal. It removes the procurement-team round-trip and signals that the engagement understands the regulated context. Pricing for compliance-engineering engagements is individual; the scope of the binder dictates the hours, not a list price.
