1. Purpose
This playbook defines the process for responding to a suspected or confirmed compromise of a cloud environment.
The objectives are to:
- Detect unauthorized cloud activity.
- Validate whether a cloud identity, account, workload, or service has been compromised.
- Contain attacker access quickly.
- Preserve cloud and security evidence.
- Identify affected resources and information.
- Investigate privilege escalation and lateral movement.
- Remove attacker persistence.
- Recover affected cloud services securely.
- Assess data exposure and business impact.
- Coordinate with the cloud provider and relevant suppliers.
- Meet applicable legal, regulatory, and contractual obligations.
- Identify root causes and improve cloud security controls.
This playbook should be used together with the organization’s Cloud Incident Response Procedure, Information Security Incident Management Policy, and broader Incident Response Procedure.
2. Scope
This playbook applies to compromise involving:
- Cloud accounts
- Cloud tenants/subscriptions/projects
- IAM users
- IAM roles
- Federated identities
- SSO identities
- Privileged administrators
- Service accounts
- Workload identities
- API keys
- Access keys
- OAuth tokens
- Cloud applications
- Virtual machines
- Containers
- Kubernetes
- Serverless workloads
- Databases
- Object storage
- Cloud networks
- Secrets
- Encryption keys
- CI/CD pipelines
- Infrastructure-as-Code
- Cloud security services
- Cloud backups and snapshots
- Third-party cloud integrations
The examples use AWS, but the response principles can be adapted to Azure, Google Cloud, or other cloud platforms.
3. What Is a Cloud Compromise?
A cloud compromise occurs when an unauthorized person, process, identity, application, or workload obtains access to cloud resources or cloud management capabilities.
Examples include:
- Stolen AWS access keys
- Compromised IAM account
- Compromised SSO identity
- Unauthorized role assumption
- Privilege escalation
- Exposed API credentials
- Compromised CI/CD credentials
- Malicious OAuth integration
- Compromised workload identity
- Unauthorized EC2 instance
- Unauthorized container deployment
- Public storage exposure
- Unauthorized database access
- Compromised cloud administrator
- Malicious changes to security controls
A successful login does not automatically establish the full scope of compromise. The organization should investigate actual permissions, resource access, actions performed, and evidence of persistence.
4. Cloud Compromise Response Lifecycle
Detect → Report → Validate → Classify → Contain → Preserve Evidence → Investigate Identity → Investigate Resources → Assess Data → Eradicate → Recover → Verify → Monitor → Learn → Improve
5. Cloud Compromise Trigger Conditions
Activate this playbook when:
- An unexpected cloud login is detected.
- An access key is exposed.
- An unfamiliar IAM role is created.
- Privileges unexpectedly increase.
- A privileged role is assumed unexpectedly.
- Cloud resources are created without authorization.
- Security controls are disabled.
- Logging is modified or disabled.
- Storage becomes publicly accessible.
- Unexpected data downloads occur.
- Encryption keys are accessed unexpectedly.
- Secrets are accessed unexpectedly.
- CloudTrail or equivalent audit logs show suspicious activity.
- GuardDuty/Security Hub or equivalent detects suspicious activity.
- A CI/CD credential is compromised.
- A supplier reports cloud compromise.
- A user reports suspicious cloud activity.
6. Immediate Response – First 15 Minutes
The priority is:
Stop unauthorized access without destroying evidence.
6.1 Create Incident Record
Record:
- Incident ID
- Detection date/time
- Detection source
- Cloud provider
- Cloud account/project/subscription
- Affected identity
- Affected resource
- Initial symptoms
- Initial severity
- Incident Manager
6.2 Activate Response Team
Notify appropriate personnel:
- Incident Manager
- Security Lead/CISO
- Cloud/DevOps
- IAM Owner
- Application Owner
- Data/Privacy Owner
- Legal/Compliance
- Business Owner
- Management
- Cloud Provider/Supplier Owner
7. Initial Validation
Determine:
- What cloud identity is involved?
- Is the identity legitimate?
- Was access authorized?
- What permissions did the identity have?
- Which resources were accessed?
- Which actions were performed?
- When did the activity begin?
- Is the attacker still active?
- Was privilege escalated?
- Were credentials created?
- Was data accessed?
- Were security controls modified?
- Was persistence established?
Separate:
Confirmed Facts → Probable Activity → Unknowns Requiring Investigation
8. Incident Severity
Low
Examples:
- Suspicious activity blocked before successful access.
- Exposed credential with no evidence of use.
Medium
Examples:
- Confirmed unauthorized access to a limited cloud resource.
- Limited non-production compromise.
- Low-impact credential compromise.
High
Examples:
- Production cloud account compromise.
- Privileged identity compromise.
- Unauthorized production changes.
- Customer information potentially accessed.
- Security controls modified.
Critical
Examples:
- Cloud administrator compromise.
- Widespread production compromise.
- Major customer-data exposure.
- Destruction of backups.
- Significant service disruption.
- Broad attacker persistence.
- Multiple cloud accounts/environments compromised.
Severity should follow the organization’s approved incident classification methodology.
9. Immediate Containment
Depending on the circumstances:
- Disable compromised IAM identities.
- Revoke active sessions.
- Revoke access keys.
- Rotate compromised credentials.
- Remove unauthorized MFA methods.
- Restrict compromised roles.
- Remove excessive permissions.
- Disable suspicious service accounts.
- Disable compromised API keys.
- Restrict suspicious network access.
- Isolate compromised workloads.
- Stop unauthorized instances/containers where appropriate.
- Restrict affected storage.
- Protect backups.
- Restrict CI/CD credentials.
- Temporarily suspend suspicious integrations.
Containment decisions should consider:
- Evidence preservation
- Business continuity
- Production impact
- Recovery requirements
- Attacker activity
- Critical services
10. Preserve Cloud Evidence
Potential evidence includes:
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- IAM activity
- IAM policy history
- IAM role assumptions
- Access-key activity
- S3 access logs
- VPC Flow Logs
- WAF logs
- Application logs
- Database audit logs
- EDR telemetry
- DNS logs
- Network logs
- CI/CD logs
- Git activity
- Configuration history
- Cloud security alerts
- Backup activity
- Snapshot activity
Protect logs from unauthorized deletion or modification.
11. Investigate the Compromised Identity
Determine:
- Identity name
- Identity type
- Owner
- Business purpose
- Authentication method
- MFA status
- Permissions
- Privileged roles
- Role assumptions
- Access keys
- API credentials
- OAuth connections
- Source location
- Device
- Session
- First suspicious activity
- Last suspicious activity
Review:
- Failed authentication
- Successful authentication
- New credentials
- New roles
- Policy changes
- MFA changes
- Group changes
- Trust-policy changes
- Role-assumption activity
12. Investigate Privilege Escalation
Determine whether the attacker increased their privileges.
Look for:
- Administrator policy attachment
- New IAM policies
- Role creation
- Trust-policy changes
- Cross-account access
- New service accounts
- Permission-boundary changes
- Group membership changes
- Delegation changes
- Service-role manipulation
Document:
Original Identity → Original Permission → Escalation Technique → New Permission → Resources Accessible
13. Investigate Persistence
Cloud attackers may establish persistence through:
- New IAM users
- New IAM roles
- New access keys
- New API credentials
- New OAuth applications
- New service accounts
- Modified trust policies
- Scheduled functions
- Lambda functions
- Startup scripts
- CI/CD credentials
- SSH keys
- New cloud resources
- Modified deployment pipelines
Search for unauthorized changes created during the suspected compromise period.
14. Investigate Resource Activity
Review potentially affected:
Compute
- EC2
- ECS
- EKS
- Lambda
- Other workloads
Storage
- S3
- EBS
- Snapshots
- Backup repositories
Databases
- RDS
- DynamoDB
- Other managed databases
Network
- VPC
- Security Groups
- Network ACLs
- Load balancers
- WAF
- DNS
Security
- KMS
- Secrets Manager
- GuardDuty
- Security Hub
- CloudTrail
Determine:
- What changed?
- Who changed it?
- When?
- From where?
- Was the change authorized?
- What impact did the change have?
15. AWS CloudTrail Investigation
CloudTrail should be used to construct an activity timeline where available.
Review:
- Console login
- API calls
- Role assumptions
- IAM changes
- Policy changes
- Access-key activity
- S3 activity
- EC2 activity
- RDS activity
- Security-group changes
- KMS activity
- Secrets Manager activity
- CloudTrail changes
- Backup/snapshot changes
Build:
Timestamp → Identity → Source → API Action → Resource → Result → Authorization Status
16. Investigate Data Access
Determine whether the attacker accessed:
- Customer data
- Personal data
- Confidential information
- Financial information
- Source code
- Secrets
- Encryption keys
- Backups
- Logs
- Configuration information
For each important data source determine:
Resource → Data Type → Access Method → Identity → Time → Volume → Destination
If unauthorized access or exposure is identified, activate the Data Breach Playbook where appropriate.
17. S3 Data Exposure Scenario
Example:
An attacker compromises an IAM role and accesses an S3 bucket containing customer information.
Investigate:
- Bucket policy
- IAM permissions
- Object access
- CloudTrail events
- S3 access logs where enabled
- Object downloads
- Object listing
- Public access configuration
- Access point configuration
- Encryption
- KMS usage
- Data-transfer activity
Determine:
- Which objects could be accessed.
- Which objects were actually accessed where evidence permits.
- Whether objects were downloaded.
- Whether public access existed.
- Exposure duration.
- Whether other buckets have similar weaknesses.
18. RDS / Database Compromise
Investigate:
- Database authentication
- Database users
- IAM authentication
- Query logs
- Connection sources
- Administrative activity
- Data exports
- Snapshots
- Configuration changes
- Security-group changes
Determine:
- Which database was accessed.
- Which account was used.
- What privileges existed.
- What queries were executed where logging permits.
- Whether data was exported.
- Whether records were modified or deleted.
19. Secrets and Credential Exposure
Determine whether the attacker accessed:
- AWS Secrets Manager
- Parameter Store
- Environment variables
- API keys
- Database credentials
- CI/CD credentials
- SSH keys
- OAuth tokens
- Application secrets
- Encryption keys
If exposure is suspected:
- Rotate the affected secrets.
- Revoke old credentials.
- Review where the credentials were used.
- Investigate dependent applications.
- Validate that the attacker cannot reuse the credentials.
20. CI/CD and Source-Code Investigation
Cloud compromise may originate from or spread into development systems.
Review:
- Git repositories
- GitHub/GitLab/other source control
- CI/CD pipelines
- Build credentials
- Deployment roles
- Secrets
- Repository access
- Workflow modifications
- Deployment history
- Container registries
- Infrastructure-as-Code
Look for:
- Unauthorized commits
- Modified pipelines
- Malicious workflow files
- New deploy keys
- New access tokens
- Unexpected deployments
- Unauthorized container images
If source-code or build infrastructure is compromised, activate the appropriate Source Code/CI-CD Compromise Playbook where available.
21. Cloud Network Investigation
Review:
- Security Groups
- Network ACLs
- VPC Flow Logs
- WAF
- Load balancers
- VPN
- Peering
- Transit Gateway
- Public IPs
- DNS
- Internet gateways
Look for:
- Newly exposed ports
- Unauthorized public IPs
- Unexpected outbound connections
- Modified security groups
- New network paths
- Unusual data transfer
- Unauthorized remote access
22. Cloud Workload Compromise
If EC2/ECS/EKS/Lambda or another workload is compromised:
Determine:
- Workload ID
- Owner
- Deployment source
- Image/version
- IAM role
- Network access
- Secrets accessed
- Data accessed
- Processes
- Outbound connections
- Persistence
- Configuration changes
Possible containment actions include:
- Isolating the workload
- Removing network access
- Revoking its IAM role
- Rotating secrets
- Preserving evidence
- Rebuilding from a trusted image
- Deploying a known-good version
23. Cloud Provider Coordination
Contact the cloud provider when appropriate.
Provide:
- Account information
- Incident reference
- Time window
- Affected resources
- Suspicious identities
- Indicators of compromise
- Relevant logs
- Required assistance
Coordinate provider actions with the organization’s incident manager.
Do not assume that the cloud provider will investigate or remediate the organization’s configuration automatically.
The provider’s responsibility and the organization’s responsibility depend on the applicable cloud service and shared-responsibility model.
24. Eradication
After containment and investigation:
- Remove unauthorized identities.
- Remove unauthorized roles.
- Remove malicious policies.
- Revoke compromised credentials.
- Rotate secrets.
- Remove unauthorized resources.
- Remove persistence mechanisms.
- Correct security-group changes.
- Restore secure storage policies.
- Remove malicious code.
- Rebuild compromised workloads.
- Patch exploited vulnerabilities.
- Correct insecure configurations.
- Restore logging and monitoring.
25. Recovery
Recovery should use trusted configurations and deployment sources.
Possible sequence:
Identity → Security Controls → Network → Infrastructure → Database/Storage → Application → Integrations → Monitoring → Business Service
Before returning systems to normal operation:
- Validate IAM.
- Confirm MFA.
- Validate least privilege.
- Verify security groups.
- Verify storage permissions.
- Validate encryption.
- Verify secrets.
- Confirm logging.
- Confirm monitoring.
- Scan workloads.
- Validate application functionality.
- Confirm backup capability.
26. Recovery Verification
Verify:
- No unauthorized identities remain.
- No unauthorized roles remain.
- Access keys are controlled.
- Secrets are rotated.
- MFA is configured.
- Privileged access is authorized.
- Logging is operational.
- Monitoring is operational.
- Security controls are restored.
- No unauthorized resources remain.
- Network configuration is secure.
- Data integrity is acceptable.
- Application services operate normally.
- No suspicious activity continues.
27. Data Breach Assessment
Determine whether the cloud compromise resulted in:
- Customer-data access
- Personal-data exposure
- Confidential-data access
- Credential exposure
- Source-code access
- Financial information exposure
- Regulatory information exposure
If a breach is suspected, assess:
What Data → Whose Data → Which Resource → Which Identity → What Access → What Time Period → What Evidence
Activate the Data Breach Playbook where applicable.
28. Business Continuity Assessment
Assess:
- Critical business services
- Production availability
- Customer impact
- RTO/RPO
- Backup availability
- Alternative infrastructure
- Recovery dependencies
- Supplier dependencies
- Manual workarounds
If required, activate:
- Business Continuity Plan
- Disaster Recovery Plan
- Cloud Backup and Recovery Procedure
29. Notification Assessment
Assess applicable:
- Legal requirements
- Privacy requirements
- Regulatory requirements
- Customer contracts
- Supplier agreements
- Insurance requirements
- Cloud-provider contractual obligations
Document:
- Requirement considered
- Applicable jurisdiction
- Decision
- Decision-maker
- Supporting evidence
- Notification deadline where applicable
Legal/Privacy/Compliance should coordinate notification decisions where appropriate.
30. Root Cause Analysis
Determine the primary cause of the cloud compromise.
Potential causes include:
- Stolen credentials
- Phishing
- Exposed access key
- Excessive privileges
- Vulnerable application
- Compromised CI/CD
- Publicly exposed service
- Weak authentication
- Misconfigured storage
- Insecure security group
- Compromised supplier
- Insecure workload
- Software supply-chain compromise
Also identify contributing conditions.
Examples:
- Lack of MFA
- Poor access reviews
- Excessive permissions
- Missing logging
- Weak monitoring
- Poor secrets management
- Inadequate network segmentation
- Unpatched software
- Insufficient cloud configuration monitoring
31. Corrective Action Register
| Finding | Risk | Corrective Action | Owner | Due Date | Evidence | Status |
|---|---|---|---|---|---|---|
| Excessive IAM permissions | High | Implement least privilege | Cloud Owner | Date | IAM review | Open |
| Exposed access key | High | Rotate credentials and strengthen secret management | DevOps | Date | Credential rotation evidence | Open |
| Missing MFA | High | Enforce MFA for privileged access | IAM Owner | Date | MFA report | Open |
| Insufficient CloudTrail monitoring | Medium | Improve centralized monitoring | Security | Date | Monitoring evidence | Open |
| Public storage exposure | High | Restrict public access and implement preventive controls | Cloud Owner | Date | Configuration evidence | Open |
32. Cloud Compromise Readiness Checklist
Preparation
- Cloud accounts/projects identified
- Cloud asset inventory maintained
- IAM roles and privileged identities identified
- MFA implemented
- Cloud logging enabled
- Cloud monitoring enabled
- Security alerts configured
- Backup requirements defined
- Recovery requirements defined
- Cloud incident playbook approved
- Cloud-provider contacts maintained
- Critical cloud services identified
During Incident
- Incident record created
- Incident classified
- Compromised identity identified
- Active attacker activity assessed
- Credentials contained
- Sessions revoked
- Evidence preserved
- Privilege escalation investigated
- Persistence investigated
- Resource changes investigated
- Data access assessed
- Network activity assessed
- CI/CD/source-code impact assessed
- Backup impact assessed
- Cloud provider engaged where required
Recovery
- Unauthorized identities removed
- Credentials rotated
- Secrets rotated
- IAM permissions corrected
- Security configuration restored
- Compromised workloads rebuilt where required
- Vulnerabilities remediated
- Logging restored
- Monitoring validated
- Data integrity validated
- Business services validated
Closure
- Data-breach assessment completed
- Notification requirements assessed
- Root cause documented
- Corrective actions assigned
- Residual risk assessed
- Lessons learned completed
- Management review completed
- Incident formally closed
33. Relationship With Other ISMS Documents
This playbook should connect with:
- Cloud Security Policy
- Cloud Incident Response Procedure
- Cloud Access Review Checklist
- Cloud Security Risk Assessment
- Cloud Secure Configuration Standard
- Cloud Services Register
- Cloud Backup and Recovery Procedure
- Cloud Exit Checklist
- Information Security Incident Management Policy
- Incident Response Procedure
- Account Compromise Playbook
- Data Breach Playbook
- Phishing Playbook
- Ransomware Playbook
- Source Code/CI-CD Compromise Playbook
- Vulnerability Management Procedure
- Privileged Access Management
- Access Control Policy
- Supplier Security Requirements
- Supplier Incident Response Procedure
- Risk Register
- Corrective Action Register
- Evidence/Records Management Procedure
34. ISO 27001 Connection
Cloud compromise response supports information-security incident management and related cloud-security controls.
Relevant areas may include:
- Information-security incident management
- Event reporting
- Incident assessment and response
- Learning from incidents
- Identity management
- Authentication
- Access rights
- Privileged access
- Cloud service security
- Configuration management
- Logging
- Monitoring
- Malware protection
- Vulnerability management
- Data leakage prevention
- Backup
- Supplier security
- Information classification
- Protection of authentication information
- Secure development and deployment
The exact controls applicable to the organization should be determined through the ISMS scope, risk assessment, Statement of Applicability, contractual obligations, legal requirements, and business context.
This playbook is not itself evidence that cloud-security controls are operating. Auditors may request actual CloudTrail/logging records, IAM reviews, configuration evidence, incident records, recovery tests, corrective actions, and management review evidence.
35. Internal Audit Checklist
An auditor can verify:
- Are cloud environments identified?
- Are critical cloud services identified?
- Are cloud identities and privileged roles controlled?
- Is MFA implemented?
- Are cloud activities logged?
- Are security events monitored?
- Are cloud incidents reported?
- Is a cloud incident-response process documented?
- Are credentials and secrets protected?
- Are access reviews performed?
- Are cloud configurations monitored?
- Are backups protected?
- Are recovery procedures tested?
- Are incidents investigated?
- Is evidence preserved?
- Is data exposure assessed?
- Are cloud-provider responsibilities understood?
- Are corrective actions tracked?
- Are lessons learned documented?
- Is residual risk assessed?
- Is management involved in significant incidents?
36. Final Cloud Compromise Audit Trail
A complete cloud-compromise response should create the following evidence chain:
Suspicious Cloud Activity → Incident Reported → Activity Validated → Incident Classified → Cloud Identity Identified → Access Contained → Evidence Preserved → Privileges Investigated → Persistence Investigated → Resource Activity Investigated → Network Activity Investigated → Data Access Assessed → Lateral Movement Assessed → Cloud Provider Engaged → Unauthorized Changes Removed → Credentials/Secrets Rotated → Secure Configuration Restored → Systems Recovered → Recovery Verified → Monitoring Increased → Notification Requirements Assessed → Corrective Actions Assigned → Residual Risk Assessed → Lessons Learned → Management Review → Incident Closed
37. Final Principle
Cloud Compromise Response = Secure the Identity + Contain the Access + Preserve Cloud Evidence + Investigate Privilege and Persistence + Protect the Data + Restore Trusted Configuration + Verify the Environment.
The objective is not simply to disable the compromised account.
The organization should be able to demonstrate:
Who was compromised → What permissions existed → What the attacker accessed → What changed → Whether data was accessed → Whether persistence was established → How access was contained → How the environment was restored → What evidence supports the investigation → What risks remain → What was improved.