Incident Response in the Cloud

Chapters 2-5 built the technical investigation skills. This chapter is about the process wrapped around an incident — managing it as an event with stakeholders, communication needs, and a defined lifecycle, not just diagnosing it technically.

Severity Triage — Not Every Incident Is the Same

Severity levels (commonly Sev1-Sev4 or P1-P4) are based on impact, not raw technical severity — a completely broken production system affecting every customer is a different category from a minor cosmetic bug, even if the underlying code change behind each was similarly small. Dimensions that matter: how many users are affected, whether a workaround exists, whether data is at risk (cloud1-10's compliance material), and whether revenue or an SLA is at risk. Triage happens fast — often within minutes — and gets revised as more information comes in, not decided once and left fixed.

The Incident Commander Role

In a significant incident, one person is designated to coordinate the response — not necessarily the person actually fixing the technical problem. This role tracks status, makes communication decisions, and decides when to escalate further. Separating "who's fixing it" from "who's coordinating it" is genuinely valuable at scale, since someone deep in a technical fix often can't simultaneously manage communication well too.

Customer Communication During an Incident

• Communicate early, even with incomplete information — customers already know something is wrong; silence reads as worse than an honest "we're investigating."
• Avoid speculating about root cause publicly before it's actually confirmed — a genuinely common mistake; stating an unconfirmed cause and having to walk it back later damages trust more than simply saying "still investigating."
• Maintain a regular update cadence, even with nothing new to report ("still investigating, next update in 30 minutes"), rather than long silences.

Escalation Paths

When to escalate beyond the initial responder: hitting the limits of your own access or knowledge (echoing cloud1-6/cloud2-3's least-privilege material — genuinely not having the access needed to fix something is fine, and escalating is the correct response, not a failure); the incident exceeding a severity/time threshold the organization has already defined; or needing a specialist (database, security) for something outside general troubleshooting scope. Escalating early when in doubt is usually right — the cost of an unnecessary escalation is much lower than the cost of a prolonged, unresolved incident.

When to Involve Cloud Provider Support

Sometimes the issue genuinely sits on the provider's side of Chapter 1's shared responsibility model — "of the cloud," not "in the cloud." Chapter 8 covers working with provider support in full; worth knowing here as one specific, legitimate escalation path.

Postmortems — Learning From the Incident

A postmortem happens after resolution, using the timeline and findings already documented during the investigation (Chapter 4's "document as you go" habit). The goal is genuinely blameless — focus on what allowed the failure to happen (process or system gaps), not who made a mistake. A good postmortem includes: the timeline, the root cause (Chapter 5's 5 Whys), contributing factors (Chapter 5's honesty about multiple factors), and concrete action items with owners — a postmortem without action items is just a story, not a learning process.

This connects directly to this site's own owasp1-9 logging-failures category: good incident logging and documentation (Chapter 4) is what makes a genuinely useful postmortem possible at all — insufficient logging undermines incident forensics generally, exactly the point owasp1-9 makes.

A Support-Relevant Incident Lifecycle

A full loop — not "fix it and move on."

Hands-On Exercises