Security Incidents Aren't Ops Incidents: Why Your Runbook Needs Two Tracks

Most incident response processes are built around one shape of problem: something broke, find out why, fix it, tell people. That shape works fine for a database running out of connections or a bad deploy causing 500s. It works badly for a security incident, and teams that treat the two the same way end up making mistakes that matter a lot more than a slow rollback.

The core difference is this: in an operational incident, your first instinct (get more eyes on it, share details widely, post updates as you learn) is correct. In a security incident, that same instinct can tip off an attacker, destroy evidence, or turn a contained breach into a legal and regulatory mess. The processes need to diverge, and most on-call runbooks don't say where.

Why the standard playbook breaks

A typical incident runbook assumes a few things that don't hold during a security event:

It assumes wide visibility helps. For an outage, paging the whole team into a channel and thinking out loud is useful. For a suspected breach, every person added to that channel is a person who might leak details, use a compromised device to discuss it, or unknowingly tip off whoever is inside your systems if they're still watching Slack, email, or ticketing tools.

It assumes you should fix things immediately. Standard incident response says restore service fast. Security response often says the opposite: don't touch anything yet. Killing a compromised process or rotating credentials too early can destroy the forensic trail you need to understand what happened and alert the wrong people that you've noticed them.

It assumes the postmortem is internal. Most postmortems stay inside engineering. A security incident might require notifying customers, regulators, or law enforcement within a legally mandated window, sometimes 72 hours or less depending on your jurisdiction and industry. Waiting for a leisurely retro doesn't work.

It assumes MTTR is the goal. Fast resolution is usually good. In security, resolving too fast, by just patching the hole and moving on, means you may never find out what was accessed, for how long, or whether the attacker left something behind.

The things that actually need to change

You don't need an entirely separate tool or team to handle security incidents well. Most companies can't staff that. What you need is a second track within your existing process that kicks in when specific triggers are met.

1. A narrower initial channel

Instead of paging into the standard incident channel, security incidents should route to a smaller, named group: security lead, engineering lead, legal (if you have in-house counsel or retained counsel), and whoever detected the issue. Expand from there deliberately, not by default.

Name this group in advance. "Whoever's around" is not a security incident team. If you don't have dedicated security staff, decide now who plays this role, even if it's the same person who's usually on the ops on-call rotation.

2. Preserve before you patch

The instinct to shut down a compromised account, kill a process, or roll a credential immediately is often wrong. Before taking action:

• Snapshot logs, especially ones with short retention windows (auth logs, WAF logs, load balancer access logs)
• Capture the state of the affected system if possible (memory dump, running processes, network connections)
• Note exact timestamps of what you observed and when

Only after you've captured what you can should you move to containment. If the risk of continued access is severe (active data exfiltration, for example), contain first and accept the forensic loss. That's a judgment call, and it's one reason having a named decision-maker matters more here than in a typical outage.

3. A different communication default

For an outage, "post updates as you learn things" is right. For a security incident, communication should be need-to-know until you understand scope. That includes internal communication. Don't discuss a suspected breach in a channel with hundreds of members, and be careful about which tools you use if there's a chance the attacker has access to your normal collaboration tools.

External communication (customers, regulators) should go through legal review before it goes out, every time. This is slower than your normal incident comms process on purpose.

4. Explicit legal and compliance triggers

Build a short reference table into your process, something like:

You don't need a lawyer's depth of knowledge to run an incident, but your on-call staff should know these triggers exist and know to loop in whoever handles compliance the moment one might apply. Waiting until the postmortem to ask "did we need to report this" is too late.

5. Evidence-grade documentation

Regular incident timelines are written for internal learning. Security incident documentation may end up in front of a regulator, an insurer, or a court. That changes how you write it:

• Record who accessed what, when, and why, not just what the system did
• Avoid speculation in the primary timeline. Keep hypotheses in a separate section clearly marked as unconfirmed
• Preserve the original documentation. Don't edit the incident record after the fact; add updates with new timestamps instead

What stays the same

It's not all different. Some fundamentals of incident response still apply directly:

• You still need a clear incident commander or lead making decisions
• You still need a single source of truth for the timeline
• You still benefit from a structured severity assessment
• You still run a retrospective afterward, even if parts of it are legally privileged and can't be shared broadly

The goal isn't to build a completely separate process from scratch. It's to know, in the first five minutes, which track you're on, and to make sure your on-call team has practiced the security track at least once before they need it for real.

Practice it before you need it

Most teams run fire drills or game days for outages. Very few run one for a suspected breach. If your security incident process has never been exercised, the first time your team encounters it will be the worst possible time to learn that nobody knows who's supposed to talk to legal, or that your log retention doesn't actually cover the window you'd need.

A tabletop exercise once or twice a year, walking through a plausible scenario (leaked credential, suspicious admin login, a vendor notifying you of a breach on their end) surfaces gaps cheaply. Finding out your process doesn't work during an actual incident is a lot more expensive.

Security incidents will keep looking, on the surface, like any other page: an alert fires, something's wrong, someone's on call. The difference is what happens in the first ten minutes after that. Build the fork into your process now, so the person answering the page doesn't have to invent it under pressure.