Cloud Security Troubleshooting Playbook

Start With the Question That Limits the Blast Radius

What is the smallest confirmed set of cloud resources, identities, and data that this alert could affect - and what evidence supports that answer?

That question prevents two dangerous reactions to a production security alert: treating a weak signal as a full compromise, or dismissing a real compromise because the first event looks isolated. A useful triage process gives you a defensible scope before you disable accounts, rotate credentials, block traffic, or delete resources. Those actions can protect the environment, but they can also destroy evidence or interrupt a live service.

The goal is to classify the alert, establish its time window, identify affected assets, and begin investigation without changing more than necessary. You will use the 5W1H Triage Map - Who, What, When, Where, Why, and How - to organize facts across Azure, Amazon Web Services (AWS), or another cloud platform. By the end, you should have a short incident record, an initial severity decision, a safe evidence plan, and clear conditions for escalation.

Start every investigation with a timestamp, the alert source, and the alert’s exact wording. Do not rely on a dashboard title such as “suspicious sign-in.” Record the user or workload identity, source address, target resource, action, and detection time. Those fields let you compare the alert with identity logs, audit events, network flow records, and workload logs instead of guessing from a label.

Ask yourself: can another engineer read your first five minutes of notes and understand what happened, what remains unknown, and what action you have avoided? If not, your investigation needs structure before it needs more tools.

Build the 5W1H Triage Map

The 5W1H Triage Map turns an alert into a bounded investigation. Fill it from observed evidence, not assumptions. Mark each statement as confirmed, probable, or unknown. That distinction matters because severity decisions often fail when a probable explanation gets recorded as fact.

1. Who identifies the actor and the credentials involved. Check the human user, service principal, managed identity, role session, access key, or workload account. In Azure, review the Microsoft Entra ID sign-in and audit records. In AWS, review AWS CloudTrail events and the principal identity. Confirm whether the identity normally accesses the account, subscription, region, or service.

2. What describes the action and its result. Separate attempted actions from successful actions. A denied request to read a storage bucket does not prove data exposure. A successful policy change, secret read, or role assumption requires a different response. Capture the API operation, resource name, response code, and any object or record identifiers.

3. When defines the investigation window. Use Coordinated Universal Time (UTC) in the incident record so teams in different locations compare events correctly. Start at least 30 minutes before the first alert and continue until the latest related activity. Extend the window when a credential may have existed for longer or when logs show earlier reconnaissance.

4. Where maps the activity to cloud account, subscription, region, virtual network, workload, and source location. A sign-in from a new country may matter less than an unexpected access path from a familiar corporate network. Conversely, an attacker using a valid virtual private network (VPN) exit point can make location alone unreliable. Treat location as one signal, not proof.

5. Why records the detection reason and the business context. An impossible-travel alert may result from a mobile network, proxy, or token reuse. A new administrator role may come from an approved deployment or from privilege escalation. Compare the event with change tickets, deployment records, and on-call activity before assigning intent.

6. How explains the access path and the likely technique. Determine whether the actor used a password, multifactor authentication (MFA) session, access key, token, role assumption, automation pipeline, or exposed endpoint. Then check what permissions that path allowed. The same suspicious source produces different risk when it reaches a read-only test account versus a production administrator role.

Classify the alert after you populate the map. Use three practical states: benign or expected, suspicious but unconfirmed, and confirmed security incident. Mark an alert benign only when evidence explains the event and shows no unauthorized result. Mark it suspicious when the actor or behavior lacks a trusted explanation, but successful impact remains unproven. Mark it confirmed when logs show unauthorized access, a successful destructive or privileged action, data exposure, persistence, or a control failure with credible evidence of exploitation.

Then scope impact across four dimensions: identities, resources, data, and time....