Incident Management:Building a process you'll actually follow

Before you can manage incidents, you need a clear line between two things people constantly confuse.

• An incident is when you actually lose confidentiality, integrity or availability: data exposed to the wrong people, records tampered with, or a service your customers rely on going down.
• An event is a near miss or a suspected case that, on inspection, did not break any of the three. A phishing email nobody clicked is an event.

Getting the line wrong hurts in both directions. Treat every suspicious email as an incident and you drown the team in noise until it stops taking the process seriously. Treat a real incident as nothing and you can miss a contractual or legal obligation you were bound to meet. The practical fix is to let everything into the same register, then tag and confirm the non-incidents as events, so effort goes where it counts.

It is tempting to start with twenty scenario playbooks. Two things matter far more, and the playbooks can wait.

One responsible owner. A short policy should name the person who owns incident response. They pull together the right team for each incident, since different incidents need different people, set up the communication channels including a fallback for when the usual ones fail, and decide, based on severity, who else belongs in the room, up to top management. That structure, thought through in advance, is what lets you move fast.

Everyone knows how to report. An incident rarely surfaces where you expect. It might come from support, a customer success manager, a salesperson who hears something from a client, or your own monitoring throwing errors. All of them need to know how to raise it. Inside the tool you already use, whether that is a dedicated ISMS tool, Jira or Notion, you need one incident record, the ticket people open, that captures the report and walks it through the whole process.

Get those two right first. Scenario plans come after.

These stages mirror the widely used four-phase incident response life cycle from NIST SP 800-61: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

Not every incident deserves the same response, so grade them. A simple scale of one to four is enough for most teams. For each level, your policy should spell out three things.

• The attributes that define an incident of that kind
• A concrete example
• Who gets involved, and what has to be communicated

Severity also drives escalation. A level-one incident might pull in top management and external communication, while a level-four is handled quietly by whoever is on call. It helps to align these levels loosely with the impact scale in your risk assessment. They need not use identical wording, but a "major service outage" should mean roughly the same thing in both places.

A good response is a fast one, measured less by how quickly you write the report and more by how quickly the right things start happening. The moment someone opens the incident record, a sequence should fire on its own.

• The on-call is alerted, and the incident owner, plus the CTO where needed, is pulled in
• A crisis team forms and agrees a communication channel
• A decision log starts running

Documentation is not the bottleneck here. Triggering that sequence is.

Once you have classified an incident, three things run in parallel rather than in sequence: containing and recovering, preserving evidence, and meeting your reporting obligations. Treating them as consecutive steps is how evidence gets destroyed during cleanup, and how a notification deadline quietly passes.

Speed matters because attackers are often inside long before anyone notices. Mandiant's 2026 M-Trends report puts the global median dwell time, the gap between compromise and detection, at 14 days. Ransomware tends to move within a day, while the stealthiest intrusions persist for months, some approaching a year. Preparation is what buys you that speed, in three forms.

• Your people know how to spot and report an incident
• Your logging reaches back far enough to find the root cause
• Your backups are usable because you know which copy is the last clean one

Not every incident is a ransomware crisis. Far more common is the everyday, awkward kind, like an employment contract emailed to the wrong colleague, or one client's results sent to another. Handling those well is rarely about forensics. It is about following the process calmly. Contain it, ask the recipient to delete it, tell the affected party, and keep the relationship intact.

Some of the most damaging failures are not technical. They are missed notifications. During an incident you may be legally or contractually required to inform others, and you need to know three things about each obligation.

• Who must be told: a data protection authority, a sector regulator, affected customers, your insurer
• By when: for example, a 72-hour breach-notification window under the GDPR, or a customer SLA
• Who decides and reports on your side, which usually depends on severity

You do not need every rule memorised. You need to know the obligation exists, and you need a check built into the incident record early enough that it fires before a deadline passes. That is another reason to open the record early. It starts your own process, not just the external clock.

You do not need to preserve evidence for every incident. When a forensic or legal investigation is even possible, you do. Two rules cover it.

• Store evidence somewhere access-controlled and tamper-evident, where it cannot be quietly altered
• Keep anything potentially malicious isolated from live systems, in a separate workspace or an isolated storage location

If you have not set this up in advance, add a check to your process that prompts you to secure evidence before it is lost.

An incident is not closed when the fire is out. It is closed when you have learned from it. Every incident should end with two steps.

• A root cause analysis, so you fix the cause and not the symptom
• A check for whether similar incidents have happened before

Move the lessons out of the incident record into a running backlog, and, if your size warrants it, review that backlog quarterly or annually to spot recurring patterns. For a small team this need not be elaborate. Get the response team together, talk it through with a transcript running, tidy the notes, and turn the lessons into concrete improvement points. Those improvements are corrective actions. They belong in your corrective action log and get worked through your corrective-action workstreams, which is how a one-off incident becomes a lasting fix.

In an audit, one thing matters above all. Do you actually follow your own process? The most common findings are predictable.

• A well-written incident procedure that went unused when a real incident occurred
• A register stuffed with events that were never incidents, showing the line was never drawn clearly
• No evidence that classification, escalation, reporting and lessons learned actually happened, only a policy that says they should

Build the basics in order.

1. Write a short policy naming who owns the response and how the team forms
2. Make sure everyone knows how to spot and report an incident
3. Put one reporting-and-handling template, the incident record, in the tool you already use
4. Add a simple severity scale
5. Build in an early check for reporting obligations

Then do the part almost everyone skips. Test it. A plan nobody has ever tested is just paper, and paper is no use at the moment you need it.