24 h / 72 h / 14 d procedure

The legal framework is in Reporting to ENISA, the legal decision in Reporting duties. This page is the runbook.

Prerequisites, to verify before any incident

  • Live named accounts on the single reporting platform, for every on-call person, tested within the last six months
  • Templates pre-filled: early warning, notification, final report
  • List of Member States where each product is made available — data to maintain, often missing
  • Operational user notification channel, with up-to-date contact details
  • On-call rota, technical and legal, with deputies
  • Written delegation of the decision to report
  • Register of decisions in place

The run-through

H+0 — Detection and timestamping

An indication of active exploitation reaches a security function: a monitoring alert, a customer report, a CERT advisory, an upstream publication.

First action: timestamp receipt, and open the register entry. That starting point is what will be examined in an inspection.

H+0 to H+2 — Qualification

The PSIRT establishes the facts:

  • does the vulnerability affect your products, which ones, in which versions?
  • is there reliable evidence of exploitation — consistent indicators, logs, analysis, a circumstantial report?
  • what is the installed base affected, and in which Member States?

Deliverable: a qualification sheet passed to the legal decider. Target interval: two hours.

H+2 to H+4 — Decision

The legal decider rules: report, do not report, or report voluntarily. Where serious doubt persists, the default rule is to report.

The decision and its reasoning are entered in the register, whatever it is.

H+4 to H+20 — Drafting

The PSIRT drafts the early warning from the template. Minimum content: product identification, Member States where it is made available, nature of the event, suspected malicious character where applicable.

Legal review before sending.

Before H+24 — Sending the early warning

Submitted through the single reporting platform. Keep the acknowledgement: it is the proof that the deadline was met.

Do not aim for H+23: aim for H+16, to absorb a technical failure on the platform.

In parallel — Informing users

Without undue delay, inform affected users of the vulnerability or incident and of the measures they can apply. That information does not wait for the final report.

Before H+72 — Full notification

General information on the product, nature of the vulnerability, corrective and mitigating measures taken and applicable by users. For an incident: assessment, severity, impact, available indicators of compromise.

Then — Remediation

Fix or workaround, testing, publication of the update, publication of the security advisory under Annex I, Part II, point 4.

D+14 after the fix is available — Final report

For a vulnerability: description, severity and impact, information on the threat actor where available, details of the fix. For a severe incident the deadline is one month: detailed description, likely root cause, measures applied and ongoing.

Afterwards — Lessons learned

Actual chronology against target chronology, friction points, updates to the reference and to the templates.

Roles during the cell

Role Responsibility
Incident commander Keeps the chronology, arbitrates priorities, shields the team from interruptions
Analyst Establishes the technical facts, produces the qualification sheet
Legal lead Decides on reporting, approves wording, tracks the parallel regimes
Communications Prepares information for users and customers, with Legal
Product engineering Develops the fix or workaround
Leadership Kept informed, arbitrates commercially significant decisions

On-call cover

A 24-hour deadline spans nights, weekends and public holidays. Concretely:

  • a technical rota and a legal rota, with deputies;
  • a single on-call number, known to support and to the teams;
  • a maximum escalation delay before switching to the deputy;
  • an up-to-date, tested call list.

Exercises

Two a year at minimum. One tabletop exercise for the decision, one full technical exercise running through to submission on the platform’s test environment.

What is measured: qualification interval, decision interval, submission interval, quality of the content produced, completeness of the register. The report is filed with the governance record; the gap between the interval achieved and 24 hours is a metric tracked at committee level.

Response card

To print and display.

ACTIVELY EXPLOITED VULNERABILITY — RESPONSE CARD

1.  TIMESTAMP receipt. Open the register entry.
2.  CALL the PSIRT on-call: [number]
3.  QUALIFY within 2 h: your products? which versions?
    evidence of exploitation? which Member States?
4.  PASS the sheet to the legal decider: [number]
5.  DECIDE. In doubt → REPORT.
6.  DRAFT the early warning (template: [location])
7.  SEND before H+16. Keep the acknowledgement.
8.  INFORM affected users, without waiting.
9.  H+72: full notification.
10. D+14 after the fix: final report.

Do not forget: NIS 2 and the GDPR may apply to the same event.