Cyber incident management: the lifecycle and the clocks.

When a serious cyber incident lands, the technical fix is only half the job. The other half is coordination under pressure — deciding what happened, who needs to know, and which regulators are now counting down. Cyber incident management is the discipline that holds both halves together. This guide covers the lifecycle, how management differs from response, and the statutory reporting clocks that start the moment an incident is classified.

Management vs response

The two terms get used interchangeably, but the distinction matters when an incident is live. Incident response is the technical work: detect, contain, eradicate, recover. It's what your SOC or IR team does at the keyboard. Incident management is the wider coordination wrapped around it — command and decision-making, internal and board communication, customer and legal notification, regulatory reporting, and the post-incident review that feeds back into preparation. Response is a component of management. A team can execute flawless containment and still fail management by missing a 72-hour regulatory deadline.

The six-phase lifecycle

Frameworks including NIST SP 800-61 and ISO/IEC 27035 describe similar cycles. A practical six-phase version:

1. Preparation. Plans, roles, runbooks, and the profile work that tells you in advance which regulators bind you. The best time to learn your reporting obligations is not during the incident.
2. Detection & analysis. Recognize that something is happening and establish scope, entry point, and impact.
3. Classification & triage. Decide whether this is a reportable major or significant incident. This is the pivot point — see below.
4. Containment, eradication & recovery. The core response work: stop the spread, remove the cause, restore service safely.
5. Notification & reporting. Inform the parties owed information — customers, data subjects, and regulators — each on their own deadline and in their own format.
6. Post-incident review. A blameless review that turns the event into improved preparation. Regulators increasingly expect a documented final report anyway.

Why classification starts the clock

A common and costly misconception is that reporting deadlines run from when the incident began. In practice they run from awareness or classification of a qualifying event. Under GDPR the trigger is becoming aware of a personal-data breach; under DORA and NIS2 it's classifying an incident as major or significant. That classification moment — call it T-zero — is when every applicable clock starts at once. Which is exactly why fast, accurate classification is worth investing in: minutes lost deciding whether an event qualifies are minutes off a four-hour deadline.

DORA, NIS2, and GDPR deadlines

One incident can trip several regimes simultaneously. A ransomware event at a payments processor can be a DORA major incident, a NIS2 significant incident, and a GDPR personal-data breach at the same time — three clocks, three formats, three recipients. The EU baseline:

EU baseline; national transposition varies. Informational, not legal advice. Last verified July 2026. Our incident clocks guide works through each in detail.

When the incident is a third party's

Increasingly, the incident you have to manage didn't happen on your systems at all — it happened at a vendor. That changes the mechanics: your visibility is second-hand, your containment options are contractual rather than technical, and the reporting clocks may still apply to you because it's your data or your service that's affected. Managing a third-party incident well depends on work done long before it: knowing which vendors hold what, and having notification terms already in the contract. We cover that in the companion guide on cyber risk response, and it starts upstream with sound third-party risk management.