ITDR Response Runbook: The First 30 Minutes After an Identity Alert
CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time at 29 minutes, with the fastest at 27 seconds. It also found that 82 percent of 2025 detections were malware-free. When an identity alert fires, the response has to be decided before the alert, not during it.
This post is a runbook template you can adapt. Our LinkedIn article, The ITDR alert fired. Who owns the response?, covers why the ownership gap exists. Here is how to close it.
Before the alert: four decisions to write down
Alert ownership. Which identity alerts the SOC acts on immediately, and which page the IAM on-call first.
Pre-approved actions. Session revocation, forced reauthentication and disabling non-privileged accounts, with the SOC holding the rights to do them.
Named platform owners. One accountable person per identity platform, for example Okta, Microsoft Entra ID, Active Directory and your PAM vault, with an out-of-hours contact.
Restoration authority. Who decides when a privileged account goes back into service, and what evidence they need first.
Minutes 0 to 5: contain the identity
Revoke all active sessions and refresh tokens in the identity provider.
Disable the account if the signal is high confidence, such as token replay from a new device combined with impossible travel.
For privileged accounts, rotate any vaulted credentials the identity checked out.
Minutes 5 to 15: close the way back in
Review MFA methods added or changed in the last few days and remove any the real user cannot confirm.
Check for new OAuth consent grants, app registrations, mail forwarding rules and role assignments created by the identity.
Check whether a help desk reset preceded the alert. If so, treat the reset path as part of the incident.
Minutes 15 to 30: verify, scope and hand off
Verify the real user through a channel the attacker does not control: a callback to a number on file or a live ID check.
Pull sign-in and audit logs for the window of compromise and list the applications, data and roles the identity touched.
Hand the scope list to the incident lead, then plan restoration: reenroll with a phishing-resistant method and confirm no persistence remains.
What to automate, and what stays human
Automate session and token revocation for high-confidence detections, and forced reauthentication for medium-confidence ones. Pre-approve account disable for non-privileged users. Keep a human in the loop for break-glass accounts, executive accounts and service accounts that run production systems, where the wrong action can cause an outage that looks like an attack.
Test the runbook every quarter
Run one tabletop exercise per quarter, per identity platform. Rotate the scenario: a stolen session token, a help desk social engineering call, a compromised service account. Time each step, note which permission was missing and who had to be woken up, and turn those notes into next quarter's fixes.
Frequently asked questions
What is the difference between ITDR and a SIEM?
A SIEM collects and correlates events. ITDR focuses on identity behavior and configuration changes, such as token replay, MFA method changes and privilege escalation, which often look normal as individual log lines.
Should the SOC or the IAM team own identity incidents?
Both, with a written split. The SOC should be able to contain fast with pre-approved actions. IAM should own restoration, platform changes and anything touching privileged or service accounts.
Check your readiness in two minutes
Take our 10-question ITDR readiness scorecard for an instant score across detection, ownership, revocation and practice. To get the runbook, the SOC and IAM agreement and the first tabletop done together, our ITDR Readiness Sprint is a fixed-fee engagement with a known scope and timeline.
Built by the people who ran it.
Comments