Incident response in the cloud follows the same lifecycle but the environment changes how you do it.
The Incident Response Lifecycle
The NIST four-phase model for handling a security incident.
Tap or hover a part to learn more.
Be ready.
Plans, playbooks, tooling, contacts and training built before anything happens. The phase most often skipped and later regretted.
Check your understanding
1. Which phase includes 'lessons learned'?
2. Why capture volatile data before powering a machine off?
What's different in the cloud
- Shared responsibility — you investigate your layer (data, identity, config); the provider handles theirs.
The Shared Responsibility Model
Who secures what in the cloud — the concept most cloud breaches ignore.
Tap or hover a part to learn more.
Security OF vs IN the cloud.
The provider is responsible for the security OF the cloud (physical data centres, hardware, the virtualisation layer); you are responsible for security IN the cloud (your data, identities, configuration and access). Most breaches come from the customer side.
Check your understanding
1. Under the shared responsibility model, your data is secured by…
2. As you move from IaaS to SaaS, the customer's responsibility…
Keep learning
- Cloud-native logs — services like AWS CloudTrail, Azure Monitor and cloud audit logs are your primary evidence — enable and centralise them before an incident.
- Ephemeral & elastic — resources spin up and vanish, so snapshot volumes and preserve logs quickly for forensics.
- Identity-centric — most cloud incidents involve compromised credentials/keys, so revoke and rotate fast (IAM).
- Automation — use infrastructure-as-code and playbooks to contain and rebuild cleanly.
Preparation (logging, least privilege, automation) matters even more in the cloud.