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 incident reporting looks like in practice. Article 21 covers steady-state risk management; Article 23 covers notification when a significant incident occurs. Three milestones follow the entity becoming aware of a significant incident. A raw alert is not automatically a reportable incident.

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 becoming aware of a significant incident, not from completing root-cause analysis.
• 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.
• Not every alert or WordPress incident is reportable; significance must be assessed and the decision recorded.

#What awareness means

The operative question is when the entity becomes aware of a significant incident. A tool firing does not by itself settle that question, but an organisation cannot defer awareness indefinitely through an unattended queue or an undefined escalation path.

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 in Article 23(3), record when the entity became aware and calculate the deadline from that point.

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 incident is still ongoing when the final report would be due, Article 23(4)(d) provides for a progress report followed by the final report within one month after the incident has been handled. If later evidence changes the assessment, the reporting owner should document the change and coordinate with the competent authority rather than inventing a separate “no-action” filing.

#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.

#The decision gate: event, incident, significant incident

Keep three records separate. An event is an observable occurrence such as repeated login failures, a WAF rule firing or a deployment error. An incident is an event that compromises, or may compromise, the availability, authenticity, integrity or confidentiality of data or services. A significant incident is assessed against Article 23(3), including whether it caused or can cause severe operational disruption or financial loss for the entity, or considerable material or non-material damage to other persons.

The WordPress team supplies facts; the entity’s authorised reporting owner makes the legal and regulatory decision. The decision log should show the first reliable alert, when a responsible person reviewed it, known service and customer effects, evidence available, significance assessment, approver and next review time. Record both decisions to notify and decisions not to notify. The latter need a reason, not merely “low severity” selected in a ticket.

A multilingual site, an EU-wide audience or malicious activity does not by itself prove significance. Conversely, a modest-looking plugin compromise can be significant if it disrupts an essential service or exposes many customer accounts. National transposition, competent-authority guidance and sector context may refine the threshold, so the client legal or compliance function must verify the applicable route.

#Evidence inputs for each reporting stage

The early warning needs a stable incident identifier, affected entity and service, awareness time, current significance basis, suspected malicious or unlawful cause and possible cross-border impact. Preserve uncertainty explicitly. “Under investigation” is more defensible than an unsupported attribution.

By 72 hours, assemble a timestamped chronology, affected environments and functions, observed duration, customer and operational impact, data types potentially involved, indicators of compromise, containment completed and current residual exposure. Mark which facts are confirmed, inferred or unknown. Use UTC in the master timeline and retain original time zones from source systems.

The final report adds the developed cause analysis, severity and impact, threat type where known, mitigation completed and planned, and cross-border effects where applicable. Link each claim to a log, ticket, change record, forensic note or named decision. Preserve originals read-only where practicable and record who collected, exported and transferred them. This is operational traceability, not a claim that the agency performs formal digital forensics in every engagement.

#Roles and hand-offs under a running clock

The monitoring or hosting provider raises and preserves the technical alert. The WordPress responder contains the application impact and builds the factual timeline. The incident commander coordinates work and keeps remediation from destroying evidence. Service ownership evaluates operational impact. Security or forensics leads technical investigation. Legal, compliance or the nominated regulatory liaison determines the notification route and submits through the approved channel. Communications handles customers and public statements where required.

Define one accountable owner and one deputy for each role. Supplier contracts should state notification contacts, out-of-hours escalation and how quickly the supplier provides logs. A hand-off is complete only when the recipient acknowledges it, the current facts and uncertainties are attached, and the next deadline is visible. Do not let an agency submit to a regulator in the client’s name unless authority and process have been explicitly established.

#Rehearse the timeline, not just the attack

A useful tabletop starts with an ambiguous alert rather than a confirmed breach. Ask the team to record awareness, make a significance decision, request missing supplier evidence, draft the early warning and update it at the 72-hour stage. Introduce a late discovery such as affected customer accounts or a subcontractor in another Member State. Test the progress-report route for an incident still ongoing at one month.

After the exercise, measure time to triage, decision, evidence preservation, legal hand-off and draft completion. Record unavailable logs, stale contacts, inaccessible regulator portals and conflicting clocks. Assign each corrective action an owner and due date, then retest the failed hand-off. Quarterly drills may suit some environments, but cadence should follow the entity’s risk assessment rather than an unsupported universal interval.

#Worked decision: suspicious administrator access

Consider a hosting alert at 09:10 showing a successful WordPress administrator login from an unfamiliar network, followed by installation of a plugin. At this point the team has an event and a credible security concern, but not enough information to declare it significant. The on-call responder opens one incident record, preserves the hosting and identity logs, disables the affected account through an approved route and asks the service owner whether any customer-facing function changed.

At 09:35 the responder confirms that the account belongs to a former contractor and that the plugin created an unauthorised export endpoint. The export log is incomplete. The incident commander records the new facts, the earliest supported awareness time and the questions that remain: whether the endpoint was called, which records were reachable, how long access existed and whether another environment used the same credentials. Compliance reviews the Article 23(3) criteria using operational impact and possible harm, rather than treating the mere presence of malware as the threshold.

Suppose the WAF and application logs then show no requests to the endpoint, no service interruption and no access outside a test environment. The authorised owner may conclude, with recorded reasons, that the incident does not meet the applicable significance threshold. Monitoring continues and parallel data-protection analysis is documented. If production requests or affected accounts are discovered later, the assessment is reopened and the earlier evidence remains visible.

In a second outcome, logs show the endpoint was queried against production and customer access was disrupted during containment. The reporting team records when the entity had enough information to recognise the significant incident, prepares the early warning without waiting for complete attribution, and uses the same evidence ledger for the 72-hour update. The example demonstrates why awareness is a governed decision supported by facts, not whichever timestamp produces the most convenient deadline.

#Evidence hand-off record

Each transfer should list incident identifier, source system, covered period, collector, collection time, original time zone, integrity check where used, storage location, access restrictions and recipient acknowledgement. The recipient also records whether the material is complete enough for the requested decision. A screenshot may illustrate an alert, but exported logs or provider records are normally required to reconstruct sequence and scope.

When a supplier cannot deliver an input before a reporting milestone, the draft states what was requested, when, from whom and how the uncertainty affects the current assessment. This prevents a missing log from becoming an unmarked assumption. The supplier request remains open after submission and any material result is routed to the reporting owner for an update decision.

#Acceptance and limitations

Readiness is acceptable when the client has an approved significance matrix, named decision-makers and deputies, current authority contacts, synchronised evidence sources, tested templates, an acknowledged supplier-escalation route and a dated exercise result. The 24-hour template should be deliberately short; the 72-hour and final templates should reuse the same incident identifier and timeline rather than create competing records.

This workflow does not make every security incident reportable, decide legal significance for the entity or guarantee that a competent authority will agree with the initial assessment. It also does not replace parallel duties such as personal-data-breach assessment under the GDPR or sector-specific reporting. Those clocks and recipients need their own mapped decision paths.

For a scoped readiness review, send a written brief with the entity and sector, jurisdictions, WordPress function, monitoring sources, suppliers, current incident roles, reporting channels and exercise history. The NIS2 and DORA readiness service can then map the decision gate, evidence inputs, hand-offs, templates and rehearsal plan without presenting the result as legal certification.

#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
• NIS2 vs DORA scope overlap for WordPress agencies in 2026
• WordPress incident response under NIS2: 24-hour early warning playbook
• EU compliance audit for WordPress