Crisis Communication

Immediate response protocols for emergencies

---

title: "Immediate Response Protocols for Emergencies"

module: 10

module_title: "Crisis & Recovery"

order: 1

access: "paid"

summary: "How to handle the first 30 minutes of an outage, breach, or critical production bug: assess quickly, notify the right people, update on a regular cadence, and document as you go. Includes ready-to-adapt notification, update, and resolution messages so you never go dark during an emergency."

related:

  • "coordinating-team-communication-during-incidents"
  • "managing-your-own-emotions-under-pressure"
  • "post-mortem-conversations-with-clients"
  • "following-through-on-commitments"

---

Immediate Response Protocols for Emergencies

When systems go down, a security breach is discovered, or a critical bug hits production, your first 30 minutes set the tone for everything that follows. Having clear protocols prevents panic, gets the right people informed, and shows that you're competent even when things are on fire.

Why this matters

In an emergency, poor communication is as damaging as the technical problem itself. Silence makes clients assume the worst. Uncoordinated responses create confusion. Slow notifications erode trust. A clear, practiced response protocol minimizes all of these.

The time to figure out your emergency response isn't during an emergency. It's now.

The principles

Assess quickly. What's actually happening? What's the real severity? Fifteen minutes of investigation before communicating beats an immediate panicked message followed by three corrections.

Notify immediately. Once you know the scope, get the right people informed through the right channels. Speed matters here.

Provide regular updates. Even "still investigating, no new information" is better than silence. Set an update cadence and stick to it.

Document as you go. Timeline, actions taken, decisions made. This saves hours during the post-mortem and protects you if questions come later.

What good looks like

Initial notification (within 30 minutes of discovery):

"URGENT: Production system outage affecting all users as of 2:15pm. Team is investigating. Will provide update by 3pm with status and ETA. [Name] is coordinating response."

Regular updates (every 30-60 minutes):

"Update 3pm: issue identified as database connection pool exhaustion. Implementing fix now. ETA 3:30pm. All data safe. Next update at 3:30pm."

Resolution:

"RESOLVED 3:45pm: service fully restored. Root cause: [explanation]. Fix: [what we did]. Prevention: [what we're implementing]. Post-mortem to follow tomorrow. No data loss."

Why It Works

Fast, specific, regular, demonstrates control. The client knows what's happening without having to ask.

Tips

  1. Create your emergency contact list and response protocol before you need it
  2. Define severity levels and appropriate responses for each
  3. Establish dedicated communication channels for emergencies
  4. Follow the pattern: assess, notify, update, resolve, follow up
  5. Provide updates on schedule even if nothing has changed
  6. Be specific about impact and estimated resolution time
  7. Never go dark during an emergency
  8. Always follow up with a post-mortem

How this connects

Emergency response requires managing emotions under pressure (staying calm when everything is breaking), clear communication (concise and factual), team coordination (who's doing what), and follow-through (the post-mortem and prevention measures).

Things to try

  • Write your emergency response protocol now, before you need it.
  • Build an emergency contact list with phone numbers.
  • Define severity levels: what's critical vs. high vs. moderate?
  • Run a mock emergency walkthrough with your team.
  • After any real incident, conduct a blameless post-mortem.

Template: Initial Outage Notification

Use this when: you've just confirmed a production outage, breach, or critical bug and need to tell the client within the first 30 minutes.

Channel: Email

```template

Subject: [URGENT] [SYSTEM / PRODUCT] issue affecting [WHO / WHAT] as of [TIME]

Hi [NAME],

Flagging this right away: we're seeing [PLAIN DESCRIPTION OF THE PROBLEM] affecting [SCOPE — e.g. "all users" or "the checkout flow"], starting around [TIME].

[NAME] is coordinating our response and the team is investigating now. [IF KNOWN: one line on data safety, e.g. "No data has been lost."]

We'll send the next update by [TIME — 30 to 60 minutes out] with what we've found and an ETA, and we'll keep that cadence until it's resolved. If you have questions in the meantime, reply here and it'll reach us.

[YOUR NAME]

```

Template: Resolution Announcement

Use this when: the incident is fully resolved and you're closing the loop with the client.

Channel: Email

```template

Subject: [RESOLVED] [SYSTEM / PRODUCT] issue — service restored at [TIME]

Hi [NAME],

[SYSTEM / PRODUCT] is fully restored as of [TIME]. Here's the summary:

What happened: [ROOT CAUSE IN PLAIN LANGUAGE].

What we did: [THE FIX].

Impact: [WHAT WAS AFFECTED AND FOR HOW LONG]. [IF TRUE: "No data was lost."]

Preventing a repeat: [THE SPECIFIC CHANGE YOU'RE MAKING].

I'll send a fuller post-mortem by [DATE] once we've reviewed it internally. Thanks for your patience while we worked through it.

[YOUR NAME]

```

Back to Topics