Prioritising & Sequencing — Unit 16, Upper-intermediate English

**Severity-1 runbook · excerpt**

**First and foremost**, isolate the auth service and revoke compromised tokens. **Prior to** any customer email, Security must confirm scope and Legal must approve wording. **At the outset** of the bridge call we agreed that safety **takes precedence over** speed to restore write access. Enterprise tenants are our **top priority** for accurate comms.

**In the meantime**, Support should apply the read-only **workaround** documented in KB-441. Patching requires **immediate action**; cosmetic UI fixes are a **secondary concern** and remain in the **backlog** until stability returns. **Before moving on**, incident leads must list events **in chronological order** so context is not lost. Status pages should not promise dates until Legal clears text.

Forensics runs **in parallel** with patching so we do not lose logs. Budget transfer is **pending approval**; we **defer to** Security on access rules and **time-box** discovery to forty-eight hours. **As a next step**, Comms will draft enterprise notices once Legal signs off. Partner integrations can wait — they are not on the critical path this week.

**Subsequently**, we will **stagger the rollout** by region rather than reopening globally at once. Pricing changes will follow **in due course**. **Once completed**, QA will notify Support and training will resume. Our **short-term focus** is incident stability; a **long-term objective** is multi-region failover. This response **lays the groundwork** for GA, but poor **sequencing** could still delay recovery — review the checklist before the next bridge. Do not reopen write access until Security explicitly clears the environment.

**Annex — why this order, and what to do when it cannot be followed**

The sequence above is not arbitrary, and responders who understand the reasoning make better decisions when the runbook does not fit the incident in front of them.

**Why isolation precedes investigation.** The instinct of most engineers is to determine what happened before acting, and in almost every other context that instinct is correct. In an active compromise it is wrong, because the attacker's access continues while you investigate. Isolation costs availability; investigation costs containment. **We have decided in advance** that we would rather explain an unnecessary outage than an avoidable extension of a breach.

**Why comms come last and not first.** This is the most contested item in the runbook. The argument for early comms is that customers discover incidents from other sources and lose trust. The argument that prevailed is narrower: an early statement that later proves wrong is more damaging than a late statement that is right, and in five of our last six incidents the initial scope assessment changed materially within the first four hours.

**When the runbook does not apply.** If the incident does not match this pattern — and roughly a third do not — the commander **should depart from** this document and say so on the bridge. A runbook followed into an unsuitable situation is worse than no runbook, because it supplies false confidence to everybody watching. Departures are reviewed afterwards for learning, never for blame.

**The one instruction that never yields.** Do not reopen write access until Security explicitly clears the environment. This is not a priority to be traded against restoration time, and no commander has authority to waive it. In March 2024 write access was restored eleven minutes before Security cleared it; the second compromise that followed cost eleven days.

**Everything else in this runbook is a default, and defaults are meant to be overridden by people who can explain why.**