1. Purpose

The Account Compromise Incident Response Playbook provides a step-by-step response process when an organizational user, administrator, service account, cloud identity, or other credential is suspected or confirmed to be compromised.

The objective is to:

• Confirm whether the account is compromised.
• Prevent further unauthorized access.
• Preserve relevant evidence.
• Determine what the attacker accessed or changed.
• Identify affected systems and information.
• Remove unauthorized access.
• Recover the account securely.
• Identify the root cause.
• Assess residual risk.
• Prevent recurrence.

This playbook supports the organization’s Information Security Incident Management Policy and Incident Response Procedure.

---

2. Scope

This playbook applies to:

• Employee accounts
• Administrator accounts
• Privileged accounts
• Cloud accounts
• SaaS accounts
• SSO/federated identities
• Service accounts
• API credentials
• Access keys
• OAuth tokens
• Application identities
• CI/CD identities
• Database accounts
• Vendor/supplier accounts
• Temporary accounts

Examples include:

• Microsoft 365/Google Workspace account compromise
• AWS/Azure/GCP identity compromise
• GitHub account compromise
• SaaS administrator compromise
• Stolen API key
• Compromised service account
• Compromised CI/CD credential

---

3. Trigger Conditions

Activate this playbook when one or more of the following occurs:

• Unusual login detected
• Login from unexpected geography/device
• Impossible-travel alert
• MFA fatigue or unexpected MFA requests
• Password discovered or reported as compromised
• Credential appears in a security alert
• Unauthorized password change
• Unauthorized MFA change
• Suspicious OAuth authorization
• Unauthorized privilege escalation
• Unusual API activity
• Unexpected cloud resource creation
• Unauthorized configuration changes
• User reports account takeover
• Security monitoring identifies suspicious account activity
• Supplier reports compromised credentials

---

4. Severity Classification

Use the organization’s approved incident-severity methodology.

An illustrative model:

Severity	Example
Low	Suspicious login blocked before successful authentication
Medium	Confirmed account compromise with limited access
High	Compromised privileged or production-access account
Critical	Compromised account with confirmed customer-data access, major production impact, or widespread compromise

Severity should consider:

• Privilege level
• Systems accessible
• Information accessible
• Customer data
• Personal data
• Production access
• Duration of compromise
• Evidence of attacker activity
• Number of affected accounts
• Business impact
• Regulatory/contractual impact

---

5. Roles

Role	Responsibility
Incident Manager	Coordinates response
Security Lead	Directs investigation
IAM Administrator	Secures identity and access
IT/Cloud Team	Supports technical investigation
Application Owner	Assesses affected applications
Data/Privacy Owner	Assesses data exposure
Legal/Compliance	Reviews obligations
Business Owner	Assesses business impact
Management	Handles major-risk decisions

---

6. Immediate Response

When an account compromise is suspected:

DO

• Start an incident record.
• Record the detection time.
• Identify the affected account.
• Preserve relevant logs.
• Determine whether the attacker is currently active.
• Assess privilege level.
• Begin containment according to severity.
• Notify the Incident Manager.

DO NOT

• Delete evidence unnecessarily.
• Immediately wipe the affected device before evidence is considered.
• Communicate unverified conclusions externally.
• Re-enable a compromised account without verification.
• Assume that changing the password alone has resolved the compromise.
• Ignore connected applications, tokens, sessions, or API credentials.

---

7. Step 1 — Identify the Account

Record:

• Account name/ID
• Account type
• User/owner
• Department
• Business purpose
• Privilege level
• Systems accessible
• Production access
• Cloud access
• SaaS access
• Service-account status
• MFA status
• SSO/federation status
• Last known legitimate activity

Determine whether the account is:

Standard User → Privileged User → Administrator → Service Account → Cloud Identity → Application Identity

---

8. Step 2 — Confirm the Compromise

Review available evidence.

Authentication

Check:

• Successful logins
• Failed logins
• Source IP addresses
• Locations
• Devices
• Authentication methods
• MFA events
• Session activity
• Password changes
• MFA changes

Account changes

Check:

• Password changes
• MFA changes
• Recovery email/phone changes
• Group membership
• Role changes
• Privilege changes
• OAuth applications
• API credentials
• Access tokens

System activity

Check:

• Files accessed
• Applications accessed
• Cloud resources accessed
• Database activity
• Administrative actions
• Configuration changes
• Emails/messages sent
• Repository activity

---

9. Step 3 — Preserve Evidence

Before making extensive changes, preserve relevant evidence where practical.

Potential evidence:

• Authentication logs
• SSO logs
• MFA logs
• IAM logs
• Cloud audit logs
• Endpoint logs
• VPN logs
• Firewall logs
• Application logs
• Email logs
• SaaS audit logs
• Git/repository logs
• API logs
• Security alerts
• Screenshots
• Incident timeline

Record:

• Evidence source
• Date/time
• Time zone
• Person collecting evidence
• Location
• Relevant timeframe

Evidence should be protected from unauthorized modification.

---

10. Step 4 — Determine Whether the Attacker Is Still Active

Look for recent activity such as:

• Active sessions
• Recent logins
• New MFA methods
• New access tokens
• New API keys
• New OAuth applications
• New administrator privileges
• New forwarding rules
• New cloud roles
• New SSH keys
• New devices
• New persistence mechanisms

If active unauthorized access is suspected, prioritize containment.

---

11. Step 5 — Contain the Account

Depending on the identity platform, appropriate actions may include:

• Disable the account
• Force password reset
• Revoke active sessions
• Revoke refresh tokens
• Revoke API tokens
• Remove unauthorized MFA methods
• Remove unauthorized OAuth applications
• Remove unauthorized roles
• Disable access keys
• Remove SSH keys
• Restrict network access
• Block malicious IPs where appropriate

For a privileged account, containment should be prioritized because of the potential blast radius.

---

12. Step 6 — Protect the Identity System

If the compromise involves an identity administrator, investigate the identity-management environment itself.

Check for:

• New administrators
• Modified roles
• New authentication methods
• New trusted devices
• New federation settings
• New applications
• New service principals
• New OAuth grants
• Conditional-access changes
• Security-policy changes
• MFA policy changes

If necessary, escalate the incident because the identity platform itself may be compromised.

---

13. Step 7 — Investigate Accessed Systems

Identify all systems accessible by the compromised identity.

Create a simple access map:

Compromised Account → Roles → Applications → Systems → Information

Review activity within the relevant timeframe.

For example:

System	Access	Activity	Potential Impact
Email	User	Messages accessed	Confidentiality
GitHub	Developer	Repository activity	Source code
AWS	Developer	IAM/API activity	Production risk
CRM	User	Customer records	Customer data
Database	None	No evidence	No known impact

---

14. Step 8 — Investigate Privilege Escalation

Determine whether the attacker increased privileges.

Check for:

• Administrator role assignment
• IAM policy changes
• Group membership changes
• Sudo/admin activity
• Cloud role assumption
• New privileged accounts
• Service-account access
• Delegated permissions

If privilege escalation occurred, expand the investigation to all resources accessible through the elevated privileges.

---

15. Step 9 — Investigate Persistence

Attackers may maintain access even after a password is changed.

Check for:

• New MFA methods
• OAuth applications
• API keys
• Access keys
• SSH keys
• Email forwarding rules
• Mailbox delegates
• Scheduled tasks
• Startup mechanisms
• New user accounts
• Cloud roles
• Service principals
• Application secrets
• CI/CD credentials

Remove unauthorized persistence mechanisms.

---

16. Step 10 — Assess Data Exposure

Determine whether the compromised account could access:

• Customer information
• Personal information
• Financial information
• Confidential information
• Source code
• Credentials
• Security information
• Intellectual property

Determine whether there is evidence of:

• Access
• Download
• Modification
• Deletion
• Exfiltration
• Disclosure

Document the distinction between potential access and confirmed access.

---

17. Step 11 — Check for Lateral Movement

Determine whether the compromised identity was used to access other accounts or systems.

Check:

• Authentication from the compromised account
• Remote access
• Administrative access
• Cloud role assumption
• Database access
• Internal applications
• VPN
• File shares
• Other SaaS applications
• Source-code repositories
• CI/CD systems

If another identity appears compromised, create or link a related incident.

---

18. Step 12 — Credential Reset and Rotation

After appropriate evidence preservation and containment:

User account

• Reset password.
• Enforce MFA.
• Remove unauthorized MFA methods.
• Revoke active sessions.
• Revoke tokens.

Privileged account

In addition:

• Review all privileged activity.
• Review role assignments.
• Rotate associated credentials.
• Review service-account access.
• Review administrative changes.

API/service account

• Revoke exposed credentials.
• Generate replacement credentials.
• Update dependent applications securely.
• Review recent API activity.
• Confirm old credentials no longer work.

---

19. Step 13 — Check the User’s Device

If the compromise may have resulted from malware, phishing, token theft, or endpoint compromise:

• Isolate the device where appropriate.
• Preserve relevant evidence.
• Run approved security scans.
• Review browser/session activity.
• Check suspicious applications.
• Check saved credentials.
• Check browser extensions.
• Check persistence mechanisms.
• Apply required security updates.

Do not assume that resetting the account alone resolves an endpoint compromise.

---

20. Step 14 — Phishing Assessment

If phishing is suspected, investigate:

• Original message
• Sender
• URL/domain
• Attachment
• Authentication page
• Credential submission
• MFA interaction
• Email headers
• Other recipients

Determine whether other employees received the same campaign.

If necessary:

• Block malicious domains
• Remove malicious emails
• Notify affected users
• Search for additional compromised accounts

---

21. Step 15 — Cloud Account Compromise

If the compromised identity has cloud access, activate the Cloud Incident Response Procedure.

For an AWS environment, investigate relevant activity such as:

• CloudTrail
• IAM
• IAM Identity Center
• Access keys
• Role assumptions
• Security-group changes
• S3 activity
• EC2/ECS activity
• RDS activity
• KMS activity
• Secrets Manager
• CloudFormation/Terraform activity

Check whether the attacker:

• Created resources
• Changed IAM policies
• Accessed databases
• Accessed storage
• Created access keys
• Modified security controls
• Disabled logging
• Created persistence

---

22. Step 16 — Source-Code and CI/CD Assessment

If the account has development access, review:

• Git commits
• Pull requests
• Repository permissions
• Deployments
• Pipeline executions
• Secrets
• Environment variables
• Package changes
• Container images
• Infrastructure-as-Code changes

If unauthorized code or infrastructure changes occurred:

1. Identify the change.
2. Preserve evidence.
3. Determine whether it reached production.
4. Revert or replace the change.
5. Review associated credentials.
6. Validate production integrity.

---

23. Step 17 — Eradication

Remove all known unauthorized access and persistence.

Examples:

• Delete unauthorized accounts.
• Remove unauthorized roles.
• Revoke tokens.
• Revoke API keys.
• Remove malicious OAuth applications.
• Remove unauthorized MFA methods.
• Remove SSH keys.
• Rotate secrets.
• Patch exploited vulnerabilities.
• Remove malicious code.
• Rebuild compromised systems where appropriate.

---

24. Step 18 — Recovery

Restore the affected account and services to a trusted state.

Before restoring access:

• Confirm the root cause is addressed.
• Confirm unauthorized persistence is removed.
• Reset credentials.
• Re-enroll MFA if necessary.
• Verify roles.
• Verify permissions.
• Review connected applications.
• Confirm monitoring.

For privileged accounts, perform an additional access review before reactivation.

---

25. Step 19 — Post-Recovery Monitoring

Increase monitoring temporarily after recovery.

Monitor:

• Login activity
• MFA events
• Privilege changes
• Token creation
• API activity
• Cloud activity
• Email activity
• Repository activity
• Data access

The monitoring period should be appropriate to the incident risk.

---

26. Step 20 — Determine Root Cause

Possible root causes include:

• Phishing
• Credential reuse
• Password compromise
• Malware
• Token theft
• Missing MFA
• MFA bypass
• Excessive privileges
• Inadequate access review
• Vulnerable endpoint
• OAuth abuse
• Exposed API key
• Cloud misconfiguration
• Supplier compromise

Example:

Root Cause: Employee entered credentials into a phishing site.

Contributing Factors:

• No phishing-resistant MFA
• Insufficient user awareness
• Excessive application permissions

Corrective Actions:

• Enforce stronger MFA
• Remove unnecessary permissions
• Improve phishing detection
• Conduct targeted awareness training

---

27. Step 21 — Impact Assessment

Document:

Confidentiality

Was information accessed or disclosed?

Integrity

Were systems, data, code, or configurations modified?

Availability

Were systems unavailable or disrupted?

Privacy

Was personal information involved?

Business

Was customer service, revenue, or business operation affected?

Regulatory/Contractual

Are notification or reporting requirements triggered?

---

28. Step 22 — Notifications

Depending on impact, notify appropriate parties.

Potential stakeholders:

• Management
• Security
• IT
• Business owner
• Privacy
• Legal
• Compliance
• Customers
• Suppliers
• Cloud providers
• Regulators
• Insurance provider

External communication should be approved and based on verified facts.

---

29. Step 23 — Corrective Actions

Record actions such as:

Finding	Corrective Action
Weak authentication	Strengthen MFA
Excessive privilege	Implement least privilege
Stolen credentials	Improve credential protection
No access review	Establish periodic access review
OAuth abuse	Restrict OAuth applications
Long-lived API keys	Implement short-lived credentials
Insufficient monitoring	Improve identity monitoring

Each action should have:

• Owner
• Due date
• Priority
• Status
• Evidence
• Verification

---

30. Step 24 — Lessons Learned

Ask:

1. How was the compromise detected?
2. How long did the attacker have access?
3. Was containment sufficiently fast?
4. Were logs sufficient?
5. Could the attacker escalate privileges?
6. Was MFA effective?
7. Was persistence identified?
8. Was data exposure determined?
9. Were all connected systems reviewed?
10. What control improvements are required?

---

31. Account Compromise Closure Criteria

Do not close the incident until the response team has reasonably confirmed:

• Compromise is contained.
• Active sessions are addressed.
• Password/credentials are reset or rotated.
• MFA is secured.
• Unauthorized tokens are revoked.
• Unauthorized OAuth applications are removed.
• Unauthorized roles/privileges are removed.
• Persistence mechanisms are removed.
• Accessible systems have been assessed.
• Data exposure has been assessed.
• Lateral movement has been investigated.
• Root cause is documented.
• Recovery is verified.
• Required notifications are completed.
• Corrective actions are assigned.
• Residual risk is assessed.
• Incident record is complete.
• Closure is approved.

---

32. Example — Compromised AWS Developer Account

Scenario

A developer reports unexpected MFA prompts followed by an unusual AWS login.

Detection

Security monitoring identifies an unfamiliar login followed by AWS API activity.

Investigation

The team identifies:

Developer Identity → IAM Role → Production AWS Account → S3/RDS/ECS

CloudTrail shows unusual API calls.

Containment

• Disable/restrict compromised identity.
• Revoke active sessions.
• Rotate credentials.
• Review IAM roles.
• Review recent policy changes.

Investigation

Review:

• CloudTrail
• IAM
• S3 access
• RDS activity
• ECS activity
• Security-group changes
• Secrets Manager
• Cloud configuration changes

Impact

Determine whether the attacker:

• Accessed customer data.
• Modified production.
• Created resources.
• Created persistence.
• Accessed secrets.

Recovery

• Remove unauthorized IAM changes.
• Rotate affected credentials.
• Restore approved configuration.
• Validate production.
• Increase monitoring.

Closure

Document:

Detection → Containment → Investigation → Impact → Eradication → Recovery → Root Cause → Corrective Actions

---

33. Example — Compromised SaaS Account

A finance employee’s SaaS account is compromised.

The attacker changes the password and adds a new MFA device.

Response:

1. Disable the account.
2. Preserve SaaS audit logs.
3. Revoke active sessions.
4. Remove unauthorized MFA.
5. Reset password.
6. Re-enroll approved MFA.
7. Review administrative changes.
8. Review data accessed.
9. Check for exports/downloads.
10. Check connected OAuth applications.
11. Check forwarding/integration rules.
12. Determine whether customer/personal information was accessed.
13. Monitor the account.
14. Document root cause and corrective actions.

---

34. Evidence Checklist

Retain, where applicable:

• Incident ticket
• Authentication logs
• MFA logs
• SSO logs
• IAM logs
• Cloud audit logs
• SaaS audit logs
• Endpoint evidence
• Email/phishing evidence
• API activity
• OAuth activity
• Access-token information
• Privilege changes
• Configuration changes
• Data-access evidence
• Credential-reset evidence
• Recovery evidence
• Communications
• Root-cause analysis
• Corrective actions

---

35. Internal Audit Checklist

An auditor can verify:

• Account-compromise playbook exists.
• Trigger conditions are defined.
• Roles are assigned.
• Compromise validation is performed.
• Evidence preservation is addressed.
• Authentication activity is reviewed.
• Privilege escalation is investigated.
• Persistence mechanisms are considered.
• Connected applications are reviewed.
• Cloud access is investigated where applicable.
• Credential rotation is performed.
• MFA is secured.
• Data exposure is assessed.
• Lateral movement is considered.
• Root cause is identified.
• Recovery is verified.
• Corrective actions are tracked.
• Lessons learned are documented.
• Closure criteria are applied.

---

36. Relationship With Other ISMS Documents

Document	Relationship
Information Security Incident Management Policy	Overall governance
Incident Response Procedure	General incident-response process
Cloud Incident Response Procedure	Cloud-specific investigation and containment
Cloud Access Review Checklist	Validates cloud permissions
Identity and Access Management Policy	Defines access requirements
Password/Authentication Policy	Defines authentication requirements
Vulnerability Management Procedure	Handles exploited vulnerabilities
Phishing/Email Security Procedure	Handles phishing-related incidents
Data Breach Procedure	Handles personal-data breaches
Supplier Incident Response Procedure	Handles supplier compromise
Cloud Backup and Recovery Procedure	Supports recovery
Corrective Action Register	Tracks remediation
Risk Register	Tracks residual risks

---

37. ISO 27001 Connection

This playbook provides operational guidance for responding to a specific incident scenario.

The organization should determine applicable controls through:

Context → Risk Assessment → Risk Treatment → Applicable Controls → SoA → Implementation → Evidence → Continual Improvement

The playbook itself is not evidence that the organization can respond effectively.

Actual evidence should demonstrate execution:

Compromise Detected → Investigation → Containment → Evidence → Recovery → Verification → Corrective Action

---

38. Final Account Compromise Response Trail

A complete response should produce:

Suspicious Activity
→ Account Identified
→ Compromise Validated
→ Severity Classified
→ Evidence Preserved
→ Active Sessions Identified
→ Account Contained
→ Tokens/Credentials Revoked
→ MFA Secured
→ Privileges Reviewed
→ Persistence Removed
→ Connected Systems Investigated
→ Data Exposure Assessed
→ Lateral Movement Checked
→ Root Cause Identified
→ Account Recovered
→ Monitoring Increased
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Incident Closed

---

39. Final Principle

Account Compromise Response = Secure the Identity + Stop the Attacker + Investigate the Access + Remove Persistence + Protect the Data + Verify Recovery

The critical mistake is treating an account compromise as simply a password-reset event.

A compromised account should be treated as a potential entry point into every system, application, cloud environment, dataset, and integration that the identity could access.