NIS2 Title 13 incident timeline — the practical playbook

The countdown does not start at the moment your SOC files the alert. It starts at the moment a competent observer would conclude that you should have known. In practice this means:

• Start your internal timeline log immediately upon awareness, capturing the timestamp of first signal (whether human or automated).
• If you suspect that detection delay is itself part of the issue, document the reasons (sensor gap, batch-cadence SIEM, etc.) for inclusion in the post-incident analysis.
• Notify the designated DPO and the legal-affairs lead in parallel with the SOC — they each have parallel obligations that may add notifications (GDPR Art. 33, DORA for finance, sectoral if applicable).

Goal: file the early warning with ACN/CSIRT Italia before hour 24 expires from the "should have known" point.

Minimum content of the early warning: - Date and time of incident detection (or assessed start). - Preliminary classification: type of incident (intrusion, ransomware, exfiltration, DoS, supply-chain compromise, etc.). - Initial scope: which essential or important service is affected, geographical spread, estimated number of users affected. - Whether cross-border impact is suspected. - A single point-of-contact email and phone number.

What you do NOT need at 24h: full root cause, complete IOC list, attribution. The early warning is preliminary by design — under-disclosing is worse than over-disclosing at this stage.

Common failure mode at this gate: waiting for internal "alignment" before filing. The decreto does not contemplate that delay; it expects the early warning even if internal investigation is still active.

Goal: file the full notification by hour 72.

Mandatory content additions over the early warning: - Updated impact assessment (severity, customer-facing impact, business-process impact, financial impact estimate where available). - Indicators of compromise: IPs, domains, hashes, TTPs in MITRE ATT&CK notation. - Initial root-cause hypothesis (vulnerability exploited, initial access vector, lateral path). - Containment actions already taken; remediation actions in progress. - Whether personal data was affected (and therefore GDPR Art. 33 has been triggered). - Whether the incident is suspected to be intentional (criminal vs nation-state) — this changes the downstream stakeholder list.

Failure mode: filing at exactly 72h with hypotheses dressed up as conclusions. ACN expects honest preliminary hypotheses clearly flagged as such. Walking back a confidently-stated conclusion at the 1-month report is worse than flagging uncertainty up front.

Goal: file the final report by 1 month from the "should have known" start.

Final report content: - Verified root cause (or detailed explanation of why root cause is not determinable). - Full IOC list with attribution where confidence is appropriate. - Complete remediation status: which fixes are in production, which are still in flight, target dates for the rest. - Lessons learned: process changes, control changes, tooling changes. - Cross-references to other notifications filed (GDPR Art. 33, DORA, sectoral, law-enforcement).

This is where the evidence chain shows its quality. If every artefact has been signed at write time and the chain is verifiable, the final report is largely a summary document with pointers. If the artefacts were assembled by hand from disparate tools, the final report takes weeks of cross-tool reconciliation that the team is not staffed for in the middle of incident response.

Across all three submissions, plan to have ready (signed, timestamped, with chain-of-custody):

• SOC alert chronology (with original timestamps, no manual edits).
• Detection-system telemetry export covering the incident window plus 7 days before.
• Containment-action log (firewall blocks, account disablement, system isolation) with timestamps.
• Remediation-action log (patches applied, configurations changed, rebuild events) with timestamps and approvers.
• IOC list with provenance (where each indicator came from).
• Root-cause analysis document with version history.
• Communications log (to staff, customers, regulators, law enforcement).

If any of these are produced by manual assembly during the incident response, the bandwidth conflict is immediate. The operational lesson from peer organisations: have a Trust Center or equivalent that pre-signs everything continuously, so the playbook becomes "export, review, sign, send".

A single incident often triggers more than one notification regime. Common combinations:

• Patient-data breach in a hospital: NIS2 Title 13 + GDPR Art. 33 + possible AgID notification if cloud-resident.
• Trading-system disruption in a bank: DORA Art. 17-22 + NIS2 Title 13 + Banca d'Italia sectoral notification.
• Public administration breach: NIS2 Title 13 + GDPR Art. 33 + Garante DPA notification + potential PSNC notification if in perimetro.

In every case, the evidence base is the same. The notifications are different summaries of the same underlying record. Building this once — and exporting per-regime — is dramatically easier than running parallel evidence trails. Most modern Trust Center implementations support this; legacy GRC tools typically do not.