From alert to containment: building an identity incident response runbook

An identity alert firing at 2 a.m. is not the hard part. The hard part is what happens in the next twenty minutes, when someone has to decide whether a flagged service account is a false positive or an attacker already moving through downstream systems.

Most teams find out their process has gaps at exactly that moment, because the steps lived in someone's memory instead of a document. A written identity incident response playbook turns that improvisation into a repeatable sequence, so the response does not depend on which analyst is on call or how well they remember the last incident.

What belongs in an identity incident response playbook?

A usable playbook is built around decisions, not just tasks. For every stage, it should answer three things: who has authority to act, what evidence justifies escalation, and what the rollback looks like if containment breaks something in production.

An ITDR runbook template typically organizes this into five phases: detect and triage, contain, respond to the specific credential or identity involved, eradicate and recover, and review. Each phase needs its own owner and its own exit criteria, so a responder always knows when to move to the next step rather than guessing.

Phase 1: Detect and triage

Detection starts with an alert, but triage is where most of the real work happens. The immediate question is whether the identity behind the alert is human, a service account, or an AI agent, since each has a different blast radius and revocation path.

Triage should establish the identity's effective permissions before anything else, not just its assigned role. A service account with a narrow directly assigned role can still reach far more through inherited permissions, nested groups, and downstream API access. Skipping this step is the most common reason containment later proves incomplete.

Phase 2: Contain

Identity threat containment means cutting off what the compromised identity can still do while preserving enough evidence to understand what already happened. That usually means suspending the identity, terminating active sessions, and blocking further authentication attempts, all without deleting logs or artifacts an investigator will need later.

Speed matters here more than almost anywhere else in the runbook. The gap between detection and containment is where an attacker chains one compromised credential into access on several other systems, so this phase should be measured in minutes, not the length of a full investigation. Where agents or service accounts are involved, containment also needs to account for any tools the identity was connected to. Unosecur's checklist for governing AI agent tool connections is a useful reference for teams building out that specific containment step for agent-to-tool boundaries.

Phase 3: Compromised credential response steps

Once the identity is contained, the runbook needs concrete compromised credential response steps, since containment alone does not close the exposure:

• Revoke the credential immediately rather than waiting for the investigation to finish.
• Map every system the credential could reach, using effective permissions rather than the assigned role.
• Identify and revoke any secondary credentials the compromised identity could have accessed or generated.
• Notify the owners of downstream systems that inherited trust from the affected identity.
• Preserve logs and session data before rotation, since rotating too early can erase the evidence needed for root cause analysis.

The order matters. Rotating a credential before mapping what it could reach often leaves a second, undiscovered access path still open.

Phase 4: Eradicate and recover

Eradication confirms the attacker's access is actually closed, not just that the original credential no longer works. This is where teams check for persistence: new OAuth grants, added API keys, modified permissions, or additional identities the attacker may have created between compromise and detection.

Recovery restores normal access for the affected owner or system, but it should not restore the exact conditions that allowed the incident in the first place. If the original credential was long-lived and broadly scoped, recovery is the moment to reissue it as narrower and shorter-lived, rather than simply replacing it with an equivalent.

Phase 5: Review

A post-incident review works best when it happens within a few days, while details are still fresh, and focuses on process gaps rather than individual blame. The two questions worth asking every time are how long detection to containment actually took, and what would have shortened that window.

Reviews also surface whether the identity involved should have been decommissioned earlier. Stale credentials and unused service accounts are a recurring theme in incident reviews, which is why lifecycle discipline and incident response end up connected in practice. Unosecur's guide to AI agent lifecycle security from provisioning through decommissioning covers what that ongoing discipline should look like so fewer incidents start with an identity that should already have been retired.

Turning this into a repeatable template

A runbook only earns its keep if it gets used consistently across incidents, which means the fields need to stay the same every time: incident summary, escalation path, identity type, systems affected, containment actions taken, and revision history after the review. Teams maintaining this across human accounts, service accounts, and AI agents usually run into the same underlying problem: correlating identity data that lives in separate systems. Unosecur has written up how a unified identity fabric answers the questions security and compliance teams ask most about consolidating that view, which is often the difference between a runbook that works on paper and one that works during an actual incident.

Building the playbook is only the first step. The value shows up the next time an alert fires at 2 a.m., and the response does not depend on memory.