Incident Communication and Stakeholder Management Questions

Direct answer

I pick tone and detail by asking: what will this reader decide or do with the message, and what does being wrong cost them? Engineers need mechanism and precision. Executives need impact, decision and time. Customers need effect on them, what to do, and honesty. Regulators need dated, factual statements, reviewed by legal. Across all four: state facts, state uncertainty, never guess, never blame.

By audience

Regulator specifics

Legal or compliance owns this text; engineers supply verified facts. Deadlines matter: under GDPR (the EU data-protection law) Article 33, a personal data breach must be notified to the supervisory authority (the national data-protection regulator, such as the ICO in the UK or the CNIL in France) without undue delay and, where feasible, within 72 hours of becoming aware. US public companies may have to file a Form 8-K Item 1.05 disclosure (an 8-K is a report of major events to the securities regulator, the SEC, and Item 1.05 covers cyber incidents) within four business days after determining a cyber incident is material (significant enough that an ordinary investor would consider it important to their decision to buy or sell the stock). Confirm the current rules with legal before relying on either.

Worked example: one fact, four tellings (illustrative)

Fact: a certificate expired, login failed for 40 minutes.

• Engineer: "EU gateway cert expired 09:02, renewed 09:41, no automated expiry alarm."
• Executive: "Login was down for 40 minutes in Europe. Fixed. We are adding an alert."
• Customer: "You could not log in for 40 minutes this morning. This is resolved. We apologise."
• Regulator (only if personal data was affected): "At 09:02 UTC on 12 March, login to our EU service failed for 40 minutes because of an expired certificate. Our investigation to date indicates no personal data was accessed or lost. We will confirm in writing by 15 March." Legal checks every sentence.

Pitfalls

• Euphemism ("minor", "some users") destroys trust; use numbers.
• Speculating on cause in public text.
• Promising fix times. Promise update times.
• Sending engineer language to executives or customer language to engineers.

Direct answer

Start from a default of publishing the postmortem (a written review of an incident: what happened, why, and what changes as a result), then remove only what falls into a few named risk classes. Both engineers and lawyers are partly right: engineers want candour that builds trust, lawyers want to avoid statements that create avoidable exposure. I would agree the classes up front, write the full internal postmortem first, then derive a shorter public version from it a few days later once facts are verified.

What stays internal (the risk classes)

1. Security-sensitive detail that could help an attacker (unpatched paths, configuration specifics).
2. Customer-identifying data or another company's confidential information.
3. Legal conclusions and advice, such as words like "negligent" or "violated". Facts are not conclusions: "the check was missing" is fine, "we were negligent" is not.
4. Unverified claims and speculation.
5. Contract-limited material, such as a vendor's name or terms.

Everything else (timeline, impact, real cause, what we changed) is a strong candidate for publication.

Two structures

Process

1. Complete the internal document with engineers.
2. Legal and security mark up each paragraph as publish, generalise, or hold, with a reason.
3. Communications drafts the public version from the marked-up copy, so nothing new appears.
4. Agree a publication date and announce it, so engineers know when the candour arrives.

Worked example (illustrative)

Plain-language key: a schema migration is a change to the structure of a database table; a lock makes other writers wait until the change finishes; a runbook is the team's step-by-step operating guide.

Internal line: "A schema migration held a lock on the orders table for 47 minutes, so writes timed out; the runbook did not say to run such migrations off-peak or in small steps; engineer X ran it." Marked up: keep the mechanism but generalise it (drop the table name), remove the name (blameless), keep the runbook gap. Public line: "A database change we made took longer than planned and blocked writes for 47 minutes. We have added a required review and a safeguard so changes like it cannot block writes."

Number check: both lines say 47 minutes, so the two versions can be compared fact for fact.

A fuller public excerpt built the same way:

Summary: On 12 March, between 09:10 and 09:57 UTC, some customers could not place orders.
What happened: A routine database change took longer than planned and blocked writes for 47 minutes.
What we are changing: Database changes now need a second reviewer and an automatic pre-check.

Deciding disputes

Ask legal for the specific risk behind each objection. "Might look bad" is not a risk; "it names a customer's data" is. If the disagreement remains, the incident owner escalates to a named decision maker (for example the head of engineering with the general counsel), rather than letting the draft wait.

Pitfalls

• A public postmortem so vague it teaches nothing, which wastes the trust it was meant to earn.
• Publishing days late without saying when: silence looks like avoidance.
• Two versions that contradict each other.

Direct answer. Split the work into a small number of named comms roles so nobody improvises who talks, pre-write the messages whose facts do not depend on the incident (holding statements, meaning a short "we know about it and are looking" post that claims nothing about cause or fix; cadence promises, meaning a commitment to post again at a regular interval; "we are aware" notices), and require sign-off only for anything that states cause, customer data impact, legal exposure, or a time to fix. The status page (the public web page where a company posts live service status) is where most of these messages land. Then change the process by phase: fast and template-driven early, accuracy-gated in the middle, review-heavy at the end.

Roles (borrowed from the incident command model that Google's SRE book popularised). An incident commander (IC) is the single person coordinating the response. A communications lead (comms lead) owns every outward message.

Pre-approved vs needs sign-off.

By phase.

1. Detect and declare (first 15 minutes). Speed wins. Comms lead sends the pre-approved holding message the moment severity is declared. No cause, no ETA.
2. Mitigate. Cadence is the product: an update every 30 minutes even if it says "no change". Every factual claim comes from the ops lead's log, checked by the IC. Sign-off applies to any new claim.
3. Resolve. "Resolved" only after the IC confirms symptoms are gone for an agreed observation window. Send a short plain-language summary of customer impact.
4. Postmortem (a blameless written review of what happened and how to prevent it). Draft within days, reviewed by legal and security before external publication. This is the slow, high-sign-off phase.

Worked example of a pre-approved holding message.

[10:14] Investigating: Some customers are seeing failed checkouts.
We are investigating and will post our next update by 10:45.

The wording promises a time, not a fix. That is why it needs no approval.

Proactive variant for an AI feature. For a feature whose output quality can degrade silently (a model producing wrong or unsafe answers), do not wait for complaints: pre-approve a "we are seeing degraded answer quality in [feature]; results may be unreliable, verify important outputs" notice, and pre-agree the trigger (for example, an evaluation alarm, meaning an automated test that regularly scores the model's answers against known-good examples and alerts when the score drops, or a spike in user reports) that lets the comms lead send it. Safety-relevant wording (harmful output, data exposure through the model) still goes to legal and security first.

Pitfalls. Templates that nobody has rehearsed; one person holding both IC and comms lead on a SEV1 (they will drop one); approvers without a response deadline (silence must default to "send the holding message, hold the claim"); pre-approving so much that the message says something untrue.

Direct answer

Trust during a widespread outage comes from four habits: speak early, speak regularly, be honest about what is unknown, and use plain language. Panic comes from silence and contradictions, so give one source of truth for customers and one for staff, and make sure the first, interim and final messages each have a distinct job.

Principles that hold across every message

• One source of truth per audience (a status page for customers, a stakeholder channel for staff), with identical facts in both.
• Say what customers experience, not internal systems.
• Acknowledge impact in one sentence; skip long apologies until the end.
• Unknown is allowed, as long as it comes with the next update time.
• Never speculate or over-reassure; a claim that later proves false costs more than a period of uncertainty.

First update (job: prove we know and are on it)

Timing: within minutes of confirming customer impact, even if you only know the symptom. Content: what customers see, that you are investigating, next update time. Example (illustrative, file-sync service):

Investigating: Some files are not syncing across devices. Files are not lost; your files on each device remain accessible [only if verified]. We are investigating and will update by 10:30 UTC.

Interim updates (job: show progress and keep the rhythm)

Content: what changed (scope, cause identified, mitigation started), what remains unknown, next update time. Keep the same rhythm even when nothing changes:

Identified: A change to our storage layer is causing sync failures. We are reverting it. Sync remains delayed for affected users. Next update 11:00 UTC.

If the cause is unknown, say so: "We have not yet identified the cause; we have narrowed it to the storage layer."

Final update (job: close the loop and rebuild confidence)

Resolved: Sync is working normally as of 12:40 UTC. Between 09:50 and 12:40 UTC some users saw delayed syncing. Cause: a faulty change to our storage layer, now reverted. We will publish a full review (postmortem: a blameless written account of what happened and how we will prevent a repeat) by Friday.

Internal versus external

Internal audiences get the same facts plus operational detail (owners, suspected causes labeled as suspicion, asks). External audiences get the customer-facing subset. Never let external readers learn something from a screenshot or social media that the status page did not say.

Preventing panic

• Announce the rhythm early ("we will update every 30 minutes") so silence between updates is expected, not alarming.
• Provide clear guidance on what customers should do or avoid ("no action needed").
• Coordinate so support, sales and executives repeat the same words.

Trade-offs and pitfalls

• Early and incomplete beats late and polished, with the caveat that early claims must be true.
• Do not declare resolution until recovery has been observed for a reasonable period; reopening an incident is harder on trust than a slightly later "resolved".
• Do not overpromise on the review date; promise one you will meet.

Direct answer

I would start with a one-page matrix that ties each severity level to five things: audience, channel, cadence, sender, and escalation trigger. A severity (SEV) level is a rating of how bad an incident is, where SEV1 is the worst (customers cannot use the core product), SEV3 is minor and contained, and SEV4 (in the matrix below) is an issue with no customer impact at all. Start with three levels (SEV1 to SEV3) and add SEV4 only if you get many trivial issues that need tracking but no messaging. Keep it to at most four levels, name one owner for communications on every incident, and pilot it in a drill before mandating it.

The matrix (a starting point to tune)

The incident commander (the person coordinating the response) owns the severity call, and anyone may raise it. When in doubt, declare higher and downgrade later, because under-declaring costs more than over-declaring.

Escalation tiers and triggers

• Time-based: no mitigation within a set window (for example 30 minutes after declaration for SEV1) pages the next tier, meaning the next more senior on-call level (for example the VP of engineering). This is a second, separate rule from the 15-minute executive page in the matrix.
• Impact-based: more customers, a second product, or data exposure raises severity.
• Uncertainty-based: nobody can name an owner or a next step, so escalate for more hands.

Template audiences (write the messages once, in advance)

Keep three templates: responders (technical), internal business (impact, workaround, next update time), and customers (plain language, no internal names). Each field is filled from the same incident notes so they never disagree.

Cross-region variant

If you run in several regions, add a column for the regional owner. Impact statements name the region ("EU customers"), updates follow the sun (ownership of the message passes to whichever on-call engineer is in working hours, with a written handover), and customer text is localized by the region's support team. Ask legal which contractual or regulatory notification clocks (legal deadlines for telling customers or regulators, such as a number of hours after discovery) apply per region rather than assuming one global number.

Worked example

Payment failures for 30 percent of attempts at 14:00 (an assumed figure for illustration): that is SEV1 because the core revenue path is impaired. The commander declares SEV1 and opens a bridge at 14:05. Three matrix rules then fire in order (declaration at 14:05, so the 15-minute rules land at 14:20): the communications lead posts the first status page entry by 14:20; the executive on-call is paged by 14:20 (the 15-minute rule); and executives get their email by 14:35 (the 30-minute rule). Separately, the time-based trigger counts 30 minutes from declaration: with no mitigation at 14:35, the next tier (the VP of engineering) is paged. Each time you send something, say which rule fired so nobody has to guess.

Trade-offs and pitfalls

• A 12-cell matrix nobody remembers is worse than a 4-cell one everybody follows. Start small.
• Without a named communications owner, engineers do both jobs badly.
• Test it with a tabletop drill (a rehearsal where the team talks through a fake incident) and revise after the first real one.