An identity incident response playbook turns a suspected account takeover into timed, repeatable actions: contain, revoke, notify, and evidence. ITDR detections only help if SecOps, IAM, and GRC know who locks the account, who revokes tokens, and what artifacts auditors will later sample.
This how-to is written for security, IAM, and compliance teams that need operational IR—not a theoretical kill chain poster.
This guide covers:
- Trigger criteria and severity for identity incidents
- Containment and session/token/grant revocation steps
- Stakeholder notification without leaking sensitive detail
- Auditor-ready evidence packs for SOC 2 and ISO 27001
- How SecureSlate stores IR artifacts beside control evidence
GIF via GIPHY
Related guides:
- What is ITDR? Identity threat detection and response
- Cloud identity threat detection and response
- ITDR for SOC 2 and ISO 27001 evidence
- MFA fatigue attacks and session hijacking ITDR guide
- SOC 2 password requirements: how to stay compliant
Key takeaways
- Revoke first, debate later—active sessions and refresh tokens are the blast radius.
- Identity IR needs a RACI—IAM, SecOps, GRC, Legal, and Comms own different steps.
- Notifications are staged—internal ops first; customers/regulators only after legal triage.
- Evidence packs are built during response—not reconstructed weeks later from chat history.
- Close with hardening—MFA method reset, OAuth cleanup, and access review are part of recovery.
When to trigger identity IR
Trigger the full identity IR playbook when any of the following are confirmed or strongly suspected:
- Successful sign-in after MFA fatigue / push bombing
- Session or cookie theft indicators (AiTM, unusual refresh patterns)
- Privileged account compromise or unexpected role elevation
- Malicious OAuth grant or unknown high-scope app consent
- API key / service principal abuse with data access
- Insider misuse of a shared or break-glass identity
Do not wait for malware confirmation. Identity incidents commonly have none.
Open a single incident ticket immediately. Parallel chat threads without a system of record typically destroy timeline integrity.
Severity and decision matrix
| Scenario | Severity | Containment urgency | Typical notifications |
|---|---|---|---|
| Break-glass / global admin compromised | Critical | Immediate (minutes) | CISO, Legal, exec on-call |
| Standard user mailbox takeover | High | < 1–2 hours | Security + IT + user manager |
| Suspicious OAuth grant, no confirmed data access | Medium–High | Same day revoke | IAM + Security |
| Stale service account key anomaly | Medium | Same day disable/rotate | App owner + Security |
| Password spray blocked, no success | Low | Monitor / tune | Security ops only |
Escalate severity if customer data, payments, production cloud, or privileged SaaS are in scope.
Contain compromised accounts
Execute containment in parallel where safe:
- Disable or suspend the account (or force block sign-in) for confirmed compromise.
- Mark the identity “compromised” in the IdP if the platform supports risk flags.
- Reset password only after sessions/tokens are revoked—or simultaneously if playbooks allow—so attackers cannot re-auth mid-response.
- Reset MFA methods—remove attacker-registered authenticators; re-enroll via verified channel.
- Remove standing privileges added during the incident window.
- Quarantine related devices if endpoint signals exist (coordinate with EDR, not instead of IdP revoke).
For privileged users, assume lateral movement until proven otherwise: review recent role changes, app consents, and mailbox rules.
Revoke sessions, tokens, and grants
Identity containment is incomplete if tokens survive.
| Object | Action | Owner | Evidence |
|---|---|---|---|
| Interactive sessions | Force logout / revoke all sessions | IAM / SecOps | IdP admin log + timestamp |
| Refresh tokens | Invalidate refresh tokens | IAM | Token revoke confirmation |
| OAuth grants / app consents | Revoke suspicious apps; inventory remaining | IAM | Consent audit export |
| API keys / secrets | Disable and rotate | App owner + SecOps | Key rotation ticket |
| Federation trusts (if abused) | Disable app or rotate certs carefully | IAM architect | Change record |
| VPN / device certs | Revoke if tied to identity | IT | MDM/PKI log |
Order that typically works: sessions → refresh tokens → OAuth grants → API keys → password/MFA reset → privilege cleanup.
Document clock times for MTTC reporting—see ITDR metrics and KPIs for security leaders.
Threat-specific steps for push bombing and AiTM are in the MFA fatigue / session hijacking ITDR guide.
Notify stakeholders without chaos
Use staged notifications:
Internal (immediate)
- Security on-call / IR lead
- IAM administrator with revoke rights
- IT helpdesk (so password-reset social engineering is blocked)
- User’s manager (for workforce accounts)
- GRC (evidence and framework impact)
Conditional (after triage)
- Legal / privacy (breach analysis)
- Customer success / communications (if customer data may be affected)
- Executive sponsor for critical privileged incidents
- Cyber insurance contact if policy requires early notice
What to say (internal template)
- What happened (high level)
- What is contained vs still open
- What employees should do (e.g., ignore MFA prompts; use verified channels)
- Who owns next update and when
Avoid public detail until Legal clears. Premature external messaging commonly creates liability and incomplete facts.
Evidence pack for auditors
Build the pack during the incident, not after.
| Evidence item | Source | Why auditors ask |
|---|---|---|
| Incident ticket with timeline | ITSM / IR tool | Proves procedure followed |
| Detection alert / hunt notes | SIEM / ITDR | Shows how you knew |
| Session / token revoke logs | IdP | Proves containment |
| MFA reset and re-enrollment record | IdP | Proves authenticator hygiene |
| OAuth revoke export | IdP / SaaS | Proves persistence removed |
| Access review of affected roles/apps | IAM / SecureSlate | Proves privilege hygiene |
| Notification decisions | Legal / GRC | Proves governance |
| After-action + corrective actions | Security + GRC | Proves improvement |
Map artifacts to SOC 2 / ISO control IDs using ITDR for SOC 2 and ISO 27001 evidence. Password and authenticator policy evidence often overlaps SOC 2 password requirements.
Retain per your retention policy—commonly across at least one full audit observation period.
Roles and RACI
| Activity | SecOps | IAM | GRC | Legal | IT Helpdesk | Manager |
|---|---|---|---|---|---|---|
| Declare identity incident | A/R | C | C | C | I | I |
| Revoke sessions/tokens | C | R | I | I | I | I |
| Disable account / MFA reset | C | R | I | I | C | I |
| User verification / interview | R | C | I | C | C | C |
| Breach notification analysis | C | I | C | A/R | I | I |
| Evidence pack assembly | C | C | A/R | C | I | I |
| Customer communications | C | I | C | A | I | I |
Publish this RACI inside your IR plan before the first real event.
After-action and control hardening
Within 5–10 business days, typically complete:
- Root cause (phishing, AiTM, key leak, insider, misconfig)
- Detection gap analysis (what signal was late or missing)
- Hardening: phishing-resistant MFA for privileged users, shorter sessions, OAuth admin consent workflow, key inventory
- Access review of the blast-radius apps and groups
- Update the playbook with exact console clicks / API actions your IdP requires
- Tabletop the same scenario next quarter
Recovery is not “user can log in again.” Recovery is trusted identity + cleaned persistence + documented lessons.
Streamline with SecureSlate
Identity IR creates a pile of screenshots unless GRC has a home for them. SecureSlate helps teams attach revoke logs, timelines, access reviews, and corrective actions to the controls auditors already test—so ITDR response becomes repeatable evidence, not tribal knowledge.
Use SecureSlate to:
- Track identity incidents as risks with owners and due dates
- Store evidence packs against SOC 2 and ISO 27001 controls
- Run follow-up access reviews after compromise
- Keep policy attestations (acceptable use, access control, IR) current
Get started for free: Create your SecureSlate account
Prefer a walkthrough? Book a demo to map identity IR artifacts into your audit workflow.
FAQ: identity incident response
Should we disable the account or only revoke sessions?
For confirmed compromise, typically both: revoke sessions/tokens immediately and disable or block sign-in until MFA methods are reset and risk is cleared.
Who talks to the affected employee?
Usually SecOps or IT with a verification script; managers may support but should not run technical containment.
When do we notify customers?
Only after Legal/privacy triage determines personal data or contractual notice thresholds may be met. Internal containment should not wait on that analysis.
What belongs in the auditor evidence pack?
Timeline, detection source, revoke confirmations, MFA reset, privilege cleanup, notification decision, and corrective actions—mapped to control IDs.
How does SecureSlate help during IR?
It centralizes evidence and follow-up tasks (reviews, risks, policies) so response work survives staff turnover and audit sampling.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute or contain legal advice or create an attorney-client relationship. When determining your obligations and compliance with respect to relevant laws and regulations, you should consult a licensed attorney.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
