WordPress incident response under NIS2: 24-hour early warning playbook

#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 after the 72-hour notification: 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 NIS2 Article 23 requires

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. The Directive does not define that moment, and recital 102 only repeats the deadlines. This playbook records awareness when a competent person in the entity concludes with reasonable confidence that a significant incident occurred, and writes down who concluded it and on what evidence. 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.

#When an incident is significant under Implementing Regulation 2024/2690

Article 23(3) of the Directive gives the general test. For some entity types the Commission made it concrete. Implementing Regulation (EU) 2024/2690 covers DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers (Article 1). A WordPress agency that runs hosting, maintenance and monitoring for clients may fall into the managed service provider category. Whether it does is a classification under the Directive’s annexes and national law, not something this playbook decides.

For those entities, Article 3(1) of the Regulation treats an incident as significant when one or more of these criteria are met:

• direct financial loss above EUR 500 000 or 5% of the entity’s total annual turnover in the preceding financial year, whichever is lower;
• exfiltration of trade secrets within the meaning of Directive (EU) 2016/943;
• the death of a natural person, or considerable damage to a person’s health;
• a successful, suspectedly malicious and unauthorised access to network and information systems capable of causing severe operational disruption;
• the entity-specific thresholds in Articles 5 to 14.

For managed service providers and managed security service providers, Article 10 sets those thresholds: the service is completely unavailable for more than 30 minutes; availability is limited for more than 5% of its users in the Union, or more than 1 million users, whichever is smaller, for more than one hour; or the integrity, confidentiality or authenticity of data related to the service is compromised as a result of a suspectedly malicious action, or with an impact on more than 5% of users or 1 million users, whichever is smaller.

Two rules change triage on a WordPress estate. Article 3(2) excludes scheduled interruptions and the planned consequences of scheduled maintenance, so an announced maintenance window is not a significant incident under this test. Article 4 adds recurring incidents: incidents that are not significant on their own count together as one significant incident when they occurred at least twice within six months, have the same apparent root cause and together meet the financial loss criterion. Point 3.4.2(b) of the Annex asks for a quarterly check for such recurring incidents. On WordPress, repeated reinfection through the same unpatched plugin is the pattern that check should catch.

Entities outside the Article 1 list still apply the Article 23(3) test as transposed into national law.

#Signs a WordPress site has been compromised

These findings require an incident record and immediate significance triage. They do not automatically start a NIS2 deadline. Article 23 applies when an in-scope entity becomes aware that an incident is significant under the applicable rules.

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. This is a high-severity signal, but scope and significance still require a recorded decision.

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.

#NIS2 24-hour early warning template

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.

#What goes in the NIS2 72-hour incident notification

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. Article 23(4)(b) asks for them where available.
• 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.

#What the NIS2 final incident report must contain

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.

#What Article 23 requires beyond the three NIS2 reports

The 24-hour, 72-hour and one-month deadlines are the part everyone remembers. The same article carries more duties and one protection:

• Ongoing incidents. Under Article 23(4)(e), if the incident is still ongoing when the final report is due, the entity submits a progress report at that time and the final report within one month of its handling of the incident.
• The CSIRT’s reply. Article 23(5) requires the CSIRT or competent authority to respond without undue delay and where possible within 24 hours of receiving the early warning, with initial feedback and, on request, guidance on mitigation. Where the incident is suspected to be criminal, it also gives guidance on reporting it to law enforcement.
• Recipients of the service. Where appropriate, the entity notifies the recipients of its services without undue delay of significant incidents likely to adversely affect the provision of those services (Article 23(1)). Under Article 23(2), recipients potentially affected by a significant cyber threat are told which measures or remedies they can take. For a WordPress shop or customer portal, this is the customer message drafted in advance.
• Trust service providers. By derogation from point (b), a trust service provider notifies significant incidents affecting its trust services within 24 hours of becoming aware, not 72.
• Liability. Article 23(1) states that the mere act of notification does not subject the notifying entity to increased liability.
• Public information. Under Article 23(7), the CSIRT or competent authority may, after consulting the entity, inform the public or require the entity to do so when public awareness is needed to prevent or handle the incident, or when disclosure is otherwise in the public interest.
• Near misses. Article 6(5) defines a near miss as an event that could have compromised the availability, authenticity, integrity or confidentiality of data or services but was prevented from materialising or did not materialise. Article 30 lets essential and important entities notify incidents, cyber threats and near misses voluntarily. A blocked exploit attempt against a WordPress plugin is not a mandatory notification, but it can go through this channel.

#Which CSIRT to report a NIS2 incident to

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.
• Spain. INCIBE-CERT for the private sector and citizens, CCN-CERT for public administration.
• Norway. Not an EU member state. The Directive is addressed to the Member States (Article 46), so Norwegian reporting duties come from Norwegian law; check the current rules with NSM.
• 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.

#How to prepare a WordPress incident response plan

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.

#Incident handling requirements in Implementing Regulation 2024/2690

Section 3 of the Annex to Implementing Regulation 2024/2690 sets the incident handling requirements under Article 21(2)(b) of the Directive for the entities listed in its Article 1. Read against a WordPress estate, these points change daily work:

• Incident handling policy (3.1). Roles, responsibilities and procedures for detecting, analysing, containing, recovering from, documenting and reporting incidents, with a categorisation system, communication plans for escalation and reporting, and the documents used in response: manuals, escalation charts, contact lists and templates (3.1.2). The early warning template above is one of those documents. The policy is tested and reviewed at planned intervals and after significant incidents (3.1.3).
• Logging (3.2.3). Where appropriate, logs cover creation, modification or deletion of users and extension of permissions, authentication events, all privileged access and activity by administrative accounts, and access or changes to critical configuration and backup files. In WordPress terms: user and role changes, administrator logins, and changes to wp-config.php, .htaccess and backup archives.
• Protected logs (3.2.5). Logs are kept for a predefined period and protected from unauthorised access or changes. A log that sits only on the compromised WordPress server can be edited by the attacker, so it is hard to treat as protected.
• Synchronised time (3.2.6). Systems use synchronised time sources so logs can be correlated. Without it, the awareness timestamp in the early warning cannot be matched against web server, WAF and database logs.
• Event reporting (3.3). A simple mechanism lets employees, suppliers and customers report suspicious events, and suppliers and customers are told about it where appropriate.
• Response (3.5). Containment, eradication and recovery; communication plans with the CSIRT or competent authority; logging of response activities with recorded evidence; testing of the procedures at planned intervals.
• Post-incident review (3.6). Where appropriate, a review after recovery identifies the root cause and produces documented lessons learned. The final report under Article 23(4)(d) and this review draw on the same evidence.

#How to triage a WordPress incident and preserve evidence

Open one incident record when a credible signal arrives. Preserve the original observation, time with timezone, source, environment and triage owner. Assess whether the signal is genuine, then its effect on confidentiality, integrity and availability, and only then whether it may meet the organisation’s significant-incident criteria. Operational labels such as event, major incident and crisis allocate resources; they do not replace the Article 23 test or national law. Record confirmed access, affected accounts and components, customer-journey impact, duration, geographic reach, supplier involvement and confidence. Keep unknowns explicit.

Containment and evidence preservation run together. Before rebuilding or deleting suspicious code, capture the relevant snapshot or file copy, database state, deployment identifier, sessions, administrator list and available logs where safe. Retain original exports, hash transferred forensic files and separate working copies. Log every state-changing action, including credential rotation, WAF rules, plugin removal, restore and DNS changes. Safety takes priority if preservation would allow ongoing harm; document what could not be captured and why.

Keep a timestamped decision log beside the technical timeline. Each entry names the decision, facts, assumptions, alternatives, owner and next review. Separate engineering communication, management decisions, legal and privacy assessment, and customer messaging. One coordinator reconciles them. The agency supplies affected components, discovery time, evidence references, containment status, suspected access and recovery estimate. The entity decides and submits regulatory notifications unless an authorised arrangement explicitly says otherwise.

#How to test an incident response playbook

Rehearse a scenario that crosses the host, agency, entity incident lead, privacy role and communications owner. Run from first alert through evidence capture, significance assessment, regulatory handoff, recovery approval and customer update. Accept the playbook when the on-call role responds, the correct record opens, evidence can be captured without improvised access, decision-makers receive the handoff, templates are current, a clean recovery point can be approved and exercise actions receive owners and dates.

After recovery, retain the final timeline, decision log, evidence index, notification copies, affected asset list, root-cause analysis, restore proof, communications and remediation verification. Map actions to control owners and the risk register. Temporary containment must become a durable control or an explicitly accepted residual risk.

For preparation or rehearsal, send a written brief through the NIS2 and DORA readiness service. Include the entity and jurisdictions, WordPress environments, hosting and support model, essential journeys, logging and backups, incident contacts, previous exercises and gaps to review. Do not include credentials, personal data or raw compromise evidence initially. This work improves readiness and evidence quality; it is not a legal opinion, guarantee or automatic finding that Article 23 applies.

#Related NIS2 and compliance articles

• 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
• Cyber Resilience Act + NIS2 + DORA: the 2026 compliance stack for headless WordPress
• NIS2 incident reporting timeline for WordPress: 24h, 72h, one month
• NIS2 vs DORA scope overlap for WordPress agencies in 2026
• EU compliance audit for WordPress