Cloud incident response plan: best practices and a step-by-step guide

The incident response lifecycle, adapted for the cloud

NIST SP 800-61 Rev. 3 no longer presents incident response as a stand-alone four-phase cycle. It maps response activities to the CSF 2.0 functions: Govern, Identify, Protect, Detect, Respond and Recover. In practice most teams still organise their runbooks around the familiar phases below, and that works fine as long as preparation and lessons learned feed back into governance.

Step 1: Prepare the plan, the people and the platform

Define scope and governance

State which environments the plan covers: every cloud account, subscription and project, plus the SaaS platforms that hold business data (Microsoft 365, Google Workspace, Salesforce and similar). Record data classifications, because a leak of customer personal data escalates faster than an exposed test bucket.

Assign an owner for the plan, a review cadence (at least yearly, and after major incidents or architecture changes) and the link to your business continuity and disaster recovery plans. Under NIS2, Article 20 requires management bodies of essential and important entities to approve the cybersecurity risk-management measures and oversee their implementation, so board-level sign-off is no longer optional for in-scope companies.

Assign roles before you need them

Name a deputy for every role and keep an out-of-band contact list. If the attacker has your Microsoft 365 tenant, Teams is not a safe war room.

Design the platform for response

• Central, tamper-resistant logging. Send CloudTrail, Azure activity logs, Microsoft Entra ID sign-in and audit logs, Google Cloud Audit Logs, VPC/NSG flow logs and DNS logs to a dedicated log account or workspace that production administrators cannot delete from. Use object lock or immutable storage for the archive.
• Retention that matches investigations. With a breach lifecycle measured in months, 30 days of logs is too little. Set retention by data class and legal requirements.
• Break-glass access. Keep a small number of emergency accounts with hardware MFA, stored and monitored separately, so responders are not locked out when the identity provider is the thing under attack.
• Pre-built forensic capacity. A separate forensics account or subscription with tooling ready, where you can copy snapshots for analysis without touching production.
• Segmentation and least privilege. Separate accounts per environment, scoped roles and service control policies limit how far an incident can spread.
• Immutable recovery points. Versioned, cross-account backups and images you can rebuild from, protected from the same credentials that run production.

Step 2: Detect and triage cloud incidents

Good detection in the cloud combines provider-native threat detection with your own correlation. Native services know the platform; your SIEM knows your business context.

• Enable Amazon GuardDuty, Microsoft Defender for Cloud or Google Security Command Center in every account and region, not only production.
• Forward findings and identity logs to one SIEM so an Entra ID sign-in anomaly and an unusual AWS API call from the same user show up as one case.
• Alert on high-signal events: root or global administrator sign-in, new access keys for privileged users, disabled logging, public storage policies, new regions in use, sudden spikes in compute.
• Add threat intelligence so alerts linked to known malicious infrastructure move to the top of the queue.

A simple triage matrix

Example runbook: suspicious use of an access key

1. Confirm the activity in the audit log: source IP, user agent, regions and API calls in the last few hours.
2. Deactivate the key (do not delete it yet) and revoke active sessions for the principal.
3. Check what the key could reach and what it did: new users, roles, keys, instances, data reads.
4. Snapshot affected instances and export the relevant logs to the forensics account.
5. Notify the incident commander, and legal if data access is likely.
6. Rotate any secrets the principal could read, then remove persistence the attacker created.

Step 3: Preserve evidence the cloud way

Forensics in the cloud is mostly about speed and automation. Write these steps into every runbook that ends in termination or rebuild:

• Take disk snapshots and, where your tooling supports it, a memory capture before isolating or stopping a VM.
• Tag isolated resources with the incident ID so nobody "cleans up" evidence.
• Copy snapshots and log extracts to the forensics account; record who accessed them and when.
• Keep all systems on synchronised time (NTP, UTC in logs) so you can correlate events across providers.
• Know how to request information from your provider. Contracts with SaaS vendors and MSSPs should state what logs they keep, for how long, and how fast they hand them over.

The AWS Security Incident Response Guide walks through these practices in detail for AWS; the same principles apply on Azure and Google Cloud.

Step 4: Contain, eradicate and recover

Short-term containment

• Isolate instances by swapping their security group or NSG for a deny-all group that allows only forensic access.
• Deactivate keys, revoke tokens and sessions, and force password and MFA resets for compromised identities.
• Block public access on exposed storage; apply an explicit deny policy or service control policy if the attacker holds admin rights.
• Add WAF rules or rate limits for application-layer attacks.

Long-term containment and eradication

• Remove backdoor users, roles, keys, scheduled tasks, Lambda functions or container images the attacker added.
• Rebuild workloads from known-good images and infrastructure as code instead of "cleaning" them in place.
• Fix the root cause: the over-permissive role, the leaked secret in the CI/CD pipeline, the unpatched image.
• Add a guardrail (policy-as-code, SCP, Azure Policy) so the same misconfiguration cannot come back.

Recovery and validation

Restore critical services first from clean backups, then verify integrity: run tests, compare configuration against IaC, and check that access policies are as intended. Keep heightened monitoring on the affected accounts for a defined period, for example 30 days, because attackers often try to return. Your cloud disaster recovery design determines how fast this step can go.

Step 5: Communication, legal and regulatory deadlines

Notification deadlines start when you become aware of the incident, not when the investigation ends. Put them in the plan with named owners.

NIS2 is a directive, so national law sets the exact authority and reporting format; check your country's implementation. Also check customer contracts: many B2B agreements set their own notification windows.

Prepare templates for internal updates, customer notices and regulator reports in advance. Agree a severity-based notification matrix: who is told at critical, high, medium and low severity, and how quickly. Always route external statements through legal.

Step 6: Test, measure and improve

Exercises

• Tabletop exercises at least twice a year: walk through a leaked access key, a compromised global administrator or ransomware on cloud VMs with technical, legal and communications staff in the room.
• Technical drills at least yearly in a non-production account: run the containment runbooks for real and time them.
• Restore tests that prove you can rebuild from IaC and backups in a clean account.

Metrics

Automate the repeatable steps

Automation removes minutes from every incident. Common candidates: deactivating a key flagged by GuardDuty, isolating an instance on a high-severity finding, and opening a ticket with the evidence attached. In Azure, Microsoft Sentinel playbooks built on Logic Apps do the same job. Keep a human approval step for actions that could cause an outage.

Platform notes for AWS, Azure and Google Cloud

AWS

• Use an organisation-wide CloudTrail trail covering all regions, with management events and data events for sensitive S3 buckets.
• Enable GuardDuty with a delegated administrator account, and aggregate findings in AWS Security Hub.
• Route high-severity findings through Amazon EventBridge to your paging or ITSM tool so a responder is alerted within minutes.

Azure

• Enable the relevant Microsoft Defender for Cloud plans on all subscriptions.
• Audit access with Microsoft Entra ID sign-in and audit logs; use Conditional Access to block risky sign-ins during an incident.
• Use Microsoft Sentinel analytics rules and playbooks for correlation and response.

Google Cloud

• Enable Security Command Center at organisation level.
• Keep Cloud Audit Logs and VPC Flow Logs, and export them to a locked log project.
• Google Security Operations (formerly Chronicle) provides SIEM and SOAR if you standardise on Google.

Multi-cloud

The main multi-cloud weakness is visibility. Normalise logs from every provider into one SIEM, keep one set of severity definitions, and write runbooks that name the equivalent action on each platform. Test the API calls your automation depends on, because providers change them.

How Opsio helps

Opsio's SOC service and managed detection and response run 24/7 monitoring and response for AWS and Azure environments from our teams in Sweden and India. We help clients write and test their plan, set up central logging and automate the first containment steps.

For Branäsgruppen, one of Sweden's largest ski resort groups, Opsio runs critical applications across multiple Availability Zones with daily incremental and weekly full backups kept for 60 days. The Branäsgruppen case reports a mean time of 2 days to identify and resolve critical issues and 99.9%+ application uptime.

Frequently asked questions

What are the best practices for incident response in the cloud?

Turn on audit logging everywhere and store it centrally, follow NIST SP 800-61 Rev. 3, write runbooks for common cloud incidents, automate evidence capture, contain through identity and network controls, rebuild from IaC, and test the plan with regular tabletop exercises.

How is cloud incident response different from on-premises?

You share responsibility with the provider, evidence comes from logs and APIs rather than physical disks, resources can vanish in seconds, and most attacks use stolen identities. Containment is usually an IAM or policy change rather than unplugging a server.

What should a cloud incident response plan template include?

Scope and governance, roles with deputies and contact details, severity definitions, log sources and retention, runbooks per incident type, evidence handling, a notification matrix with GDPR and NIS2 deadlines, provider escalation contacts, recovery steps and a testing schedule.

How do you integrate incident response with cloud security tools?

Feed findings from GuardDuty, Defender for Cloud or Security Command Center and identity logs into one SIEM, map each alert type to a runbook, and automate low-risk first steps such as key deactivation or instance isolation, with human approval for disruptive actions.

How often should a cloud incident response plan be tested?

Run tabletop exercises at least twice a year, at least one technical drill a year, and an extra review after any major incident or architecture change. Update runbooks after each test.