NIS2 incident reporting timeline for WordPress: 24h, 72h, one month

#NIS2 incident reporting timeline for WordPress: 24h, 72h, one month

Article 23 of Directive 2022/2555 is the operative clause that decides what an incident response actually looks like in practice. Article 21 covers steady-state risk management; Article 23 covers what happens when something breaks. Three milestones, three deliverables, one clock that starts at detection.

This is a supporting article inside the NIS2 and DORA on WordPress pillar, with cross-references to the Annex II evidence trail guide and the DORA Article 28 third-party register.

#TL;DR

• The clock runs from detection of a significant incident, not from root-cause.
• 24 hours: early warning, suspected malicious cause, cross-border indicator.
• 72 hours: full notification with initial assessment and indicators of compromise.
• One month: final report with threat type, mitigation and cross-border impact.
• Final reports get filed even if the cause is benign; “we thought it was malicious, it was a deployment regression” is a valid filing.

#What “detection” means

Article 23 is silent on what counts as detection, but ENISA guidance and recital 101 read it as the moment the entity becomes aware that an incident may be significant. Practically: the moment the alert hits the runbook owner, not the moment the alert fires in a tool.

For a WordPress site this typically means:

• A monitoring tool (Wordfence, Sucuri, hosting IDS, Cloudflare alert, Sentry error spike) flags an anomaly.
• An on-call engineer triages the alert and assesses scope.
• If the assessment crosses the significance threshold defined in Article 23(3), detection has happened. The clock starts.

The mistake to avoid is letting a junior engineer triage a credential stuffing burst at 23:50, conclude “looks like normal noise” and reassess in the morning. If that burst was actually a credential breach with confirmed account access, the 24-hour clock has been ticking since 23:50 and the regulator will work backwards from logs.

#The 24-hour early warning

Content required by Article 23(4)(a):

• Whether the incident is suspected to be caused by unlawful or malicious action.
• Whether the incident may have a cross-border impact.

That is short. The early warning is not a root-cause analysis, it is a flag. The CSIRT or competent authority needs to know that something significant is happening; details follow in the 72-hour submission.

The WordPress agency role inside 24 hours:

• Confirm the incident scope using logs, alerts and admin-panel forensics.
• Provide the client compliance team with a one-page draft early warning that names the affected service, the suspected category (malicious or operational), and any cross-border element (multi-locale site, EU-wide customer base).
• Preserve evidence: server logs, plugin update timeline, admin login history, hosting-level audit trail. Snapshot the database state if practicable.
• Stop the bleeding: rotate credentials, block IPs, isolate compromised plugins, take the site read-only if the incident affects checkout or payment.

The early warning should not contain speculation about attribution. “Suspected malicious” is enough; naming a threat actor is for forensic specialists.

#The 72-hour incident notification

Content required by Article 23(4)(b):

• Initial assessment of the incident, including severity and impact.
• Where available, indicators of compromise.

Severity language matters. ENISA aligns with three tiers: low, medium, high. A WordPress incident that took the site offline for under an hour with no data exfiltration is medium at most. A confirmed credential breach affecting customer accounts is high. A defacement of a marketing page with no other access is low to medium.

The agency deliverable inside 72 hours:

• A written incident timeline with timestamps from logs.
• An assessment of whether customer data, payment data or session data was accessed.
• Indicators of compromise: source IPs, user agents, file hashes if malware was found, modified plugin or theme files, suspicious admin accounts created.
• A first list of mitigation actions already taken: credentials rotated, vulnerable plugin removed or patched, WAF rule added, admin accounts audited.

This is where most WordPress incidents get a name in the regulator’s records. The 72-hour notification is what auditors compare to the one-month final report later.

#The one-month final report

Content required by Article 23(4)(c):

• A detailed description of the incident, its severity and impact.
• The type of threat or root cause that likely triggered the incident.
• Applied and ongoing mitigation measures.
• Where applicable, cross-border impact.

By month end the WordPress agency should have:

• A full root-cause analysis. Was it a vulnerable plugin? A leaked credential? A misconfigured server? A phishing-routed admin compromise?
• Evidence the immediate fix worked and is sustained. WAF rule shipped, plugin patched in production, credentials rotated and MFA confirmed enforced, monitoring tuned.
• Long-term remediation list. Plugin policy update, removal of unmaintained dependencies, periodic credential audit, training for editors who may have been the phishing vector.
• A confirmation paragraph for the client to forward to the regulator.

If the cause turned out to be benign (a botched plugin update misclassified as a breach), the final report still gets filed. Article 23(7) explicitly addresses this with a “no-action” version. The clock does not stop just because the assessment changes.

#What the agency keeps in the toolkit

Six artefacts every regulated WordPress engagement should have ready before the first incident:

1. Incident response runbook with named owner, escalation path and 24/72/30-day templates.
2. CSIRT and authority contact list for the client’s jurisdiction and any relevant cross-border ones.
3. Communication template for affected customers if data exposure is confirmed.
4. Evidence preservation policy: log retention, backup integrity, chain-of-custody notes.
5. Reporting language library: pre-approved phrasings for “suspected malicious”, “no customer data exposed”, “vulnerability patched”, “monitoring tuned”. Saves 30 minutes inside a 24-hour window.
6. Drill schedule: at least one tabletop exercise per quarter that walks through 24/72/30 with no real incident.

The toolkit is the difference between a 24-hour window that produces a calm one-page early warning and a 24-hour window that produces a panic call to legal at 03:00.

#Cross-references

• NIS2 Annex II for WordPress agencies: Article 21 evidence trail
• DORA Article 28 ICT third-party risk for WordPress
• NIS2 and DORA on WordPress pillar