WordPress incident response under NIS2: 24-hour early warning playbook
Article 23 of Directive 2022/2555 compresses the early phase of incident response into three deadlines: 24 hours, 72 hours, one month. The 24-hour clock is the one that catches WordPress operators off guard, because it starts at awareness, not at remediation, and awareness on a typical WordPress site can come from a Slack message rather than a SOC dashboard.
This is a supporting article in the NIS2 and DORA on WordPress pillar, with cross-references to the Annex II evidence trail and the DORA Article 28 supplier audit.
TL;DR
- 24 hours from awareness: early warning to the CSIRT.
- 72 hours from awareness: incident notification with initial assessment.
- 1 month from awareness: final report with root cause and remediation.
- “Awareness” is the trigger, not a SIEM alert.
- Six WordPress signals that I treat as “the clock starts now”.
- File templates per language are in this playbook.
What Article 23 actually says
Article 23(1) sets the obligation: notify the CSIRT or the competent authority of any incident having a significant impact on the provision of their services. Article 23(3) defines significant: capable of causing severe operational disruption of the services or financial loss for the entity, or capable of affecting other natural or legal persons by causing considerable material or non-material damage.
Article 23(4) splits the timeline:
- (a) Without undue delay and in any event within 24 hours of becoming aware of the significant incident: an early warning indicating whether it is suspected to be caused by unlawful or malicious acts, whether it could have a cross-border impact.
- (b) Without undue delay and in any event within 72 hours: an incident notification updating the early warning information and providing an initial assessment, including severity, impact, indicators of compromise.
- (c) On request from the CSIRT or competent authority: an intermediate report on the relevant status updates.
- (d) Not later than one month after the incident notification under (b): a final report including detailed description, threat type or root cause, mitigation measures applied, cross-border impact if any.
The clock starts at awareness of the significant incident. ENISA guidance reads “awareness” as the moment a competent person in the entity has reasonable confidence that a significant incident occurred. This matters for WordPress because awareness usually comes from a customer email, an external monitoring service, or a vulnerability scanner, not from an internal SOC.
Six WordPress signals that start the clock
I treat the following six findings as awareness triggers. Each one starts the 24-hour clock by default, with the option to step back if the initial triage rules out significance.
1. Defacement on a customer-facing page. Search-engine indexed defacement, replaced homepage, replaced product pages. The visibility makes severity assessment easy: customer trust impact is automatic.
2. Compromised admin user with confirmed login. A new admin account, an existing admin account showing logins from an unusual IP range or country, an admin account changing other accounts. Logged in audit-log plugins (WP Activity Log, Stream, Wordfence audit log).
3. Malicious plugin install or theme upload. A plugin file appearing in wp-content/plugins/ outside the regular update channel, or with PHP that calls eval, base64_decode, gzinflate, assert on user-supplied input. Identified by file integrity monitoring or Wordfence scan.
4. Database injection with confirmed write. SQL injection that managed to insert rows or modify rows. Confirmed by audit-log diff or by wp_users / wp_options tampering. The classic signal: siteurl option suddenly points to a domain you do not own.
5. Unauthorised personal data export. WordPress export, REST API call returning user lists, large wp-json/wp/v2/users response from an unexpected IP. GDPR Article 33 may apply alongside NIS2 Article 23.
6. Ransomware or filesystem encryption on the production server or backups. Files appearing with new extensions, .html ransom notes in upload directories, encrypted backup archives. Significance is automatic.
For any of these, the agency runbook says: timestamp the awareness moment in the IR ticket, name the responsible person, start the 24-hour clock, notify the entity’s CISO or equivalent inside the first hour. The agency does not file with the CSIRT; the entity does. The agency provides the technical content.
Early warning template (24-hour)
The early warning is intentionally short. The template I file with the entity’s compliance team:
Entity: [legal name]
Sector: [Annex I or Annex II classification]
National identifier: [tax ID or registry number]
Incident summary
Date and time of awareness: [ISO-8601 with timezone]
Detection source: [audit log / customer report / external scanner / hosting provider notification]
Affected service: [public-facing WordPress site at https://example.com, customer portal, etc.]
Initial classification
Suspected cause: [malicious / accidental / under investigation]
Cross-border impact: [yes / no / under investigation]
Indicators of cross-border impact: [if yes, what suggests it]
Initial impact estimate
Service availability: [up / degraded / down]
Confirmed data access: [none / suspected / confirmed]
Data subjects potentially affected: [count if known, otherwise "under investigation"]
Initial response
Containment actions taken: [credentials rotated, plugin removed, IP blocked, etc.]
Forensics in progress: [yes / no, with vendor name if external]
Next update: [time of 72-hour notification or earlier intermediate]
Contact
Reporter name and role: [CISO, Head of IT, etc.]
Contact email and phone: [direct line]This is the early warning, not the incident notification. The 72-hour notification expands it with severity scoring, indicators of compromise, and a clearer cross-border assessment.
72-hour notification: what to add
Within 72 hours from awareness, the notification adds:
- Severity assessment. Number of affected users, geographic spread, financial loss estimate, recovery time estimate.
- Indicators of compromise. IP addresses, file hashes, URLs, malicious user-agent strings, attack signatures. ENISA publishes a recommended schema; CSIRTs accept STIX 2.1 or a free-form list.
- Cross-border impact assessment. Confirmed or ruled out, with reasoning.
- Containment status. What is contained, what is still open.
- Cooperation needs. Whether the entity needs help from the CSIRT or other authorities.
For WordPress, the indicators block usually contains: attacker IPs from access logs, malicious file paths in wp-content/, hashes of malicious files, the user-agent strings observed during exploitation, and any HTTP request bodies preserved by the WAF.
One-month final report
Article 23(4)(d): final report not later than one month after the incident notification. Contents:
- Detailed description of the incident.
- Threat type or root cause.
- Applied and ongoing mitigation measures.
- Cross-border impact, where applicable.
For WordPress incidents, the root cause section typically lands on one of: outdated plugin with known CVE, weak admin credentials without MFA, exposed wp-config.php from a backup file, RCE via theme function, supply-chain compromise of an update channel, server-level misconfiguration. The mitigation section maps the root cause to the Article 21(2) measure that should have prevented it and updates the entity’s risk register.
Where to file: national CSIRTs
Each member state designates one or more CSIRTs and a competent authority. The current list is on the ENISA portal. The most common destinations for entities I work with:
- Poland. CSIRT NASK for civilian sectors, CSIRT GOV for public administration, CSIRT MON for defence-related. National competent authority varies by sector.
- Germany. BSI (Bundesamt für Sicherheit in der Informationstechnik) and CERT-Bund. Sector-specific CSIRTs for finance (CSIRT BaFin), energy and telecoms.
- Spain. INCIBE-CERT for the private sector and citizens, CCN-CERT for public administration.
- Norway. Not an EU member but EEA-aligned; NSM NCSC handles incident reporting for sectors that voluntarily align.
- Portugal. CERT.PT under CNCS (Centro Nacional de Cibersegurança).
For multi-jurisdiction entities, ENISA hosts the single-point-of-contact (SPOC) list which lists the national contact for cross-border coordination.
Pre-incident preparation that makes the 24 hours possible
The 24-hour deadline is unforgiving for entities that wait until awareness to prepare. Before any incident:
- A named on-call rotation. Two people, primary and secondary, with phone numbers in the IR runbook.
- An escalation tree to the entity’s CISO. The agency cannot file the early warning; the entity must, so the path from “agency notices” to “entity decides” must be sub-hourly.
- Communications templates pre-drafted. Customer notification, internal notification, regulator notification. All three in all relevant languages.
- A snapshot capability for the production WordPress instance. Before changing anything for containment, capture the file system and database for forensics.
- A relationship with a forensic vendor, contracted in advance. Article 23 forensics inside 72 hours requires a vendor that picks up the phone, not a procurement RFP.
- An off-site immutable backup. Without it, ransomware can prevent the final report by destroying evidence.
The price for setting this up is individual and depends on the size of the WordPress estate; it is not a line item on a hosting invoice.
