Building an incident response plan for a small team

phase 1: preparation

Most of the value is here, before anything happens.

Define what an incident is, and its severity. Agree a simple severity scale, for example: SEV1 is a serious, active compromise or data loss; SEV2 is a contained or suspected issue; SEV3 is minor. Severity drives who you wake and how fast.

Name the roles. Even on a small team, decide in advance who holds each role during an incident: an incident lead who runs the response and makes the call, a technical lead who does the hands-on work, and a communications owner who handles internal and external messages. One person can hold more than one role, but the roles must be named, not improvised.

Build the contact tree. Who to reach, in what order, with current phone numbers, including out-of-hours. Add the external numbers you would need fast: your cyber-insurer's hotline, outside IR or forensic help, and legal. Store it somewhere reachable when systems are down.

Pre-make the hard decisions. Decide now, calmly, the things you will not want to debate mid-incident: who can authorise taking a production system offline, who can approve paying for emergency external help, and the threshold for involving leadership and legal.

Know your reporting clocks, exactly. If you are in scope for NIS2: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. For DORA: an initial report within 4 hours of classifying an incident as major, and no later than 24 hours after first becoming aware; an intermediate report within 72 hours; and a final report within one month of resolution. GDPR requires breach notification to the supervisory authority without undue delay and, where feasible, within 72 hours. The DORA four-hour clock is the tightest in the EU and effectively rules out a manual scramble, which is the strongest argument for pre-building this plan. Write the deadlines that apply to you into the plan so they are not a surprise at 2am.

phase 2: detection and analysis

Know how you would find out. List your actual detection sources: alerts from your tools, a report from a user, a customer telling you, a vendor breach notice. For most mid-market teams, a person noticing something is still a primary channel, so make it easy to report and clear who receives it.

Triage and scope. When something comes in, the first questions are: is this real, how bad, and how far does it reach. Set the severity, and start scoping access immediately: what accounts, systems, and data are involved. This is where a current access picture pays off, because the first thing you need in an incident is to know what a compromised identity could reach.

Start the record. Open a timeline from the first moment and log actions, decisions, and timestamps. You will need it for the post-incident review, for any report, and for insurance.

phase 3: containment, eradication, recovery

Contain first. Stop the spread before you clean up. For access-driven incidents, which is most of them, containment is often identity work: disable or reset compromised accounts, revoke active sessions and tokens, and pull standing access the attacker could pivot through. Revoking a session matters as much as resetting a password, because attackers increasingly steal the session, not the credential.

Eradicate. Remove the foothold: the malware, the malicious OAuth grant, the attacker's persistence. Find how they got in, so recovery does not restore the same hole.

Recover. Restore systems and access in a controlled way, verify they are clean, and watch closely for the attacker coming back. Confirm the entry point is closed before you reopen.

A note specific to access: because most intrusions now begin with a valid credential rather than malware, your fastest containment lever is usually identity, disabling accounts, killing sessions, revoking grants. Teams that have practised this recover faster.

phase 4: post-incident activity

When it is over, hold a blameless review while it is fresh. What happened, how it was found, what worked, what did not, and what specific change would prevent or shorten the next one. The output is a short list of concrete fixes with owners, not a document that gets filed and forgotten.

This phase is where incident response feeds back into prevention. A surprising share of post-incident fixes are access fixes: an account that should not have had that reach, a leaver who was never offboarded, an integration with too much scope. The incident teaches you where your access was looser than you thought.

practise it before you need it

A plan you have never run is a hypothesis. A 60-to-90-minute tabletop exercise, walking the team through a realistic scenario, turns the document into something people have actually used once before the real thing. It surfaces the gaps, a phone number nobody had, a decision nobody owned, far more cheaply than an incident does.

the access angle, in short

Most incidents are access incidents. The standing access, stale accounts, and over-scoped grants that an attacker uses to move are the same ones a current access baseline surfaces. A tighter access baseline is one of the highest-leverage things a small team can do to make incidents both rarer and smaller: it reduces how often a compromised identity has somewhere useful to go, and it shrinks the blast radius when one does. Knowing what every account can reach, before an incident, is what lets the containment step in phase 3 move quickly instead of guessing.