---
{
  "title": "Cloud incident response",
  "summary": "Investigate identities, APIs, and delegated access as well as workloads.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Respond to identities and infrastructure together

Cloud incident response investigates unauthorized activity across identities, management APIs, workloads, and managed services. A compromised virtual machine is only one possible starting point. An exposed access credential, malicious application grant, or altered storage policy can create serious impact without a traditional endpoint infection.

Begin by identifying the account or tenant, affected resource, suspected identity, and time window. Those boundaries are provisional: new evidence may show that a role had access across several accounts or that the first visible workload was created after the original compromise.

## A suspicious workload appears

Consider a fictional team that receives an unexpected cloud spending alert. Several compute instances were created outside its normal deployment process. The responder checks who requested their creation, which role or credential was used, which images and network settings were selected, and whether the requests succeeded.

The team also examines how that identity obtained authority. A long-lived key might have leaked, or a legitimate role might have been assumed through an abused trust relationship. Deleting the instances addresses a visible symptom but leaves the underlying identity path available unless it is investigated and restricted.

[[cloud-audit-logs]] help reconstruct management activity. Workload logs, identity-provider events, network records, and service-specific data events may answer different questions. Keep the distinction clear when explaining whether the team observed resource creation, code execution, or access to stored information.

## Containment has dependencies

Disabling a credential or changing a role can interrupt production automation. Work with the service owner to identify dependent jobs and choose an authorized containment action. Immediate restriction may still be necessary when harm is ongoing, but the decision and its business effects should be recorded.

Preserve relevant configuration and records before deleting short-lived resources where practical. Avoid treating an exported virtual-machine disk as complete cloud evidence: identity settings, API actions, storage policies, and other control-plane records exist elsewhere.

Review whether the actor created additional accounts, access keys, application grants, scheduled workloads, or modified images. Password changes do not automatically invalidate every cloud credential or session; the service's credential and revocation behavior determines what is required.

## Define recovery evidence

Recovery should establish that unauthorized access paths were addressed, required services function, and monitoring covers the relevant actions. Rotate affected secrets through a controlled process and verify dependent services rather than assuming successful replacement because a key was generated.

For practice, run a tabletop exercise using the spending alert. Ask who can restrict the role, preserve records, approve workload deletion, and communicate financial impact. Then introduce a second account reached through the same role. [[incident-response]] provides coordination, while [[containment]] keeps urgent actions connected to a reasoned plan.

## Related concepts

- [[cloud-identity]]
- [[exfiltration]]