NIS2 Annex II for WordPress agencies: scope, deadlines, evidence trail

#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.
• Annexes I and II list the sectors; Article 3 decides who is essential and who is important. 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.

#Which entities fall under NIS2 Annex I and Annex II

Annex I lists the sectors of high criticality: energy, transport, banking, financial market infrastructures, health, drinking and waste water, digital infrastructure, ICT service management (B2B), public administration, space. Annex II lists the other critical sectors: 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 or more employees, or both annual turnover and 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. 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.”

#NIS2 Article 21 measures mapped to WordPress

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), Plugin Check (PCP) from WordPress.org for custom plugins, 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”.

#Essential or important entity under NIS2 Article 3

The annex a sector sits in does not settle the category on its own. Article 3(1)(a) makes an entity of an Annex I type essential only if it exceeds the medium-sized enterprise ceilings of Recommendation 2003/361/EC, which means a large enterprise: 250 or more employees, or annual turnover above 50 million EUR together with a balance sheet above 43 million EUR. Article 3(2) makes every other entity of an Annex I or Annex II type that is not essential an important entity. A medium-sized hospital from Annex I is therefore an important entity, just like a large manufacturer from Annex II.

Some cases do not depend on size. Article 3(1)(b) makes qualified trust service providers, TLD name registries and DNS service providers essential regardless of their size. Member States can also designate specific entities under Article 2(2), points (b) to (e).

For the agency the practical consequence is that the client should know its category before sending the questionnaire. Article 3(3) required Member States to establish a list of essential and important entities by 17 April 2025 and to review it at least every two years. If the client cannot state its category, the supplier review starts with an open question, and that question belongs to the client’s legal counsel, not to the agency.

#Is a WordPress maintenance agency a managed service provider under NIS2

Article 6, point 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, applications or any other network and information systems, via assistance or active administration on the customer’s premises or remotely. Annex I, point 9, lists these providers in the sector ICT service management (business-to-business). A WordPress maintenance contract with admin access, updates and server monitoring matches the wording of that definition. Whether a specific agency falls under it is a legal assessment, and I do not make it for anyone.

Size still decides. An agency with fewer than 50 people and annual turnover or balance sheet up to 10 million EUR stays outside Article 2(1). A medium-sized agency providing managed services would be an important entity; a large one, essential. For these providers Article 26(1)(b) places jurisdiction in the Member State of their main establishment in the Union.

There is a second consequence. Commission Implementing Regulation (EU) 2024/2690, adopted under Article 21(5), sets out the technical and methodological requirements of the Article 21(2) measures for managed service providers, among others. Its Article 3 treats an incident as significant when, for example, it causes or can cause direct financial loss above 500,000 EUR or 5% of the entity’s total annual turnover in the preceding financial year, whichever is lower. An in-scope agency applies that regulation directly, not through a client contract.

#What evidence do NIS2 auditors expect for each security measure

For each of the ten paragraphs I expect to produce four artefacts when an auditor turns up:

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.

#NIS2 incident reporting deadlines under Article 23

Article 21 covers the steady state. 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 after the incident notification: final report with a detailed description, the likely root cause, applied and ongoing mitigation and any cross-border impact.
• Incident still ongoing at that point: a progress report instead, and the final report within one month of handling the incident (Article 23(4)(e)).
• 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.

#NIS2 fines and management liability

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.

#NIS2 supply chain clauses in a WordPress agency contract

Article 21(3) requires the entity, when choosing its point (d) measures, to take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and its cybersecurity practices, including secure development procedures. Article 21(4) requires corrective measures without undue delay once the entity finds it does not comply. For a WordPress agency this turns into questions about code review, dependency management and patch deadlines.

The most detailed official text on contract content is point 5.1.4 of the annex to Implementing Regulation 2024/2690. It lists what contracts with suppliers specify where appropriate: cybersecurity requirements; awareness, skills, training and certifications of the supplier’s staff; background verification of that staff; notification without undue delay of incidents that present a risk; a right to audit or to receive audit reports; an obligation to handle vulnerabilities; subcontracting rules; obligations at the end of the contract, such as retrieval and disposal of the information.

The regulation binds only the entities listed in its Article 1: DNS service providers, TLD registries, cloud, data centre and CDN providers, managed and managed security service providers, online marketplaces, search engines, social networks and trust service providers. A hospital or a manufacturer is not bound by it, but the eight items work as a checklist for a draft contract. When one is missing, the agency asks the client how it is covered before signing.

#How to scope a WordPress agency for a NIS2 supplier review

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.

#NIS2 RACI matrix for client, agency and host

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.

#NIS2 evidence for change, vulnerability and access management

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.

#How to test a backup restore as NIS2 evidence

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.

#How often to review and accept NIS2 evidence

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.

#What to send for a NIS2 supplier pack estimate

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 a supplier security pack for regulated clients contains

A WordPress agency that wants to keep regulated clients in 2026 needs to ship two artefacts on every engagement:

1. A self-attestation against Article 21(2)(d) supply chain clauses, listing the security measures the agency itself implements.
2. 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.

#Related reading on NIS2 and DORA

• Pillar: NIS2 and DORA on WordPress: 2026 compliance stack
• DORA Article 28 ICT third-party risk: WordPress hosting and WAF supplier audit
• WordPress incident response under NIS2: 24-hour early warning playbook
• Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress