Incident Communication and Stakeholder Management Questions

Direct answer

Open by owning the call and lowering the temperature, not defending. Then give them a clear split: what we know, what we do not, and when they will hear next. Commit only to things you control: update times, a named contact, and a written summary. Do not guess a fix time or a cause.

Structure of the call

1. Open (first 30 seconds): introduce yourself, say you own their case, apologise for the impact, and let them speak. Do not interrupt or explain in the first minute.
2. Acknowledge specifics: repeat back their impact ("your users cannot sign in and your support lines are full"), so they know you heard the business problem.
3. What we know: confirmed facts only (start time, that it is broad, that the team is working on it, what is confirmed for their services).
4. What we do not know: be plain that the root cause and time to fix are unconfirmed, and why you will not guess.
5. Commitments: update every 30 minutes (even if "no change"), a direct number, a written summary within a day after recovery, and an initial root-cause report within about five business days.
6. Ask what they need: their most critical systems, workarounds they can use, and help drafting a message for their own users.

Example script (illustrative)

"Thank you for calling. I'm Priya, I'm responsible for your account through this. I'm sorry: I know your teams and customers are hurting. What I know: the problem began at 09:40, it is global, and our engineers are working on it now. What I do not know: the confirmed cause or how long recovery will take, and I would rather not guess. I will call you at 10:30 with an update whether or not it has changed. This is my direct number. Which of your services are most critical, so I can push those to the front?"

What not to say

• "It should be back soon." (a guess that becomes a broken promise)
• "It is not just you." (comfort for us, not for them)
• Any root cause that is not confirmed, or any blame on a partner or on their configuration.
• Jargon and internal ticket numbers.

Handling anger

Let them vent, keep your voice slow, avoid "calm down" or "as I said," and turn frustration into a concrete next step. If they escalate to a threat (contract, exit), acknowledge it and route it to the account owner and legal; do not negotiate on the call.

Trade-offs and pitfalls

• Saying "I don't know" feels weak, yet it is the honest position and it protects credibility later.
• Committing to more than you can deliver is worse than committing to less: a missed update time hurts more than a slow fix.
• Skipping the follow-up call breaks the one commitment they can hold you to.

Direct answer

In thirty minutes I would give the C-suite (the most senior executives, such as the CEO and COO) and legal a short, structured brief that separates confirmed facts from unverified ones and from unknowns, then spend most of the time on decisions and on statements: who speaks, what the holding statement (a short, pre-approved public message that acknowledges the issue without claiming facts we have not confirmed) says, and what gets held back until verified. "Verified" throughout means confirmed by the team that owns the data or system, from evidence such as logs, not from an assumption. The goal is that legal can judge exposure from facts, not from my guesses, and that nothing public contradicts what we later confirm.

Suggested thirty-minute agenda

What I say (three buckets)

• Confirmed: we are seeing failures for the checkout service since 13:52 UTC. Customers in all regions are affected. Rollback in progress.
• Suspected, not verified: a recent deploy is the leading suspect.
• Unknown: whether any customer data was exposed or lost, whether payments were charged twice, the full customer count.

I state each bucket in those words. I also say what evidence would move something from suspected to confirmed and roughly when I expect it.

What to hold back until verified

• Root cause and fault (including anything about a vendor, an employee or an attacker).
• Any claim about data: "no data was exposed", "no personal data affected".
• Customer or revenue counts.
• Any fix time or "resolved".
• Anything that assigns liability.

Legal and regulatory questions

The clocks that may start, such as contractual notice to customers (for example, a contract saying affected customers must be told within 72 hours of discovery) or data-protection notification rules (laws requiring regulators or individuals to be told of a personal data breach within a set time), depend on facts and jurisdiction (which country or state's law applies) and are legal's decision. The 72 hours is only an example. My role: give legal the exact detection time, the current scope, and a running log of confirmed facts with timestamps, and ask them what obligations might apply and by when. I should not assert a deadline myself. Legal may also ask that sensitive written analysis go through them; I should follow that.

Lining up public statements

1. One spokesperson (often communications or a named executive), no freelancing.
2. A holding statement prepared now and approved by legal: it acknowledges the issue, says we are investigating and will update by a time, and makes no claim on cause or data. For example:

We are aware that some customers are having trouble completing purchases.
Our teams are investigating and working to restore service. We will share
an update by 15:30 UTC. We are sorry for the disruption.

3. One fact log as the only source for statements, so status page, customer emails, social posts and sales talking points match.
4. A trigger list agreeing what verified fact allows which statement:

5. A review path that is fast: legal review of the holding statement now, and a short turnaround for updates.

Worked example (illustrative)

Executive: "Were customer cards exposed?" Answer: "We have no evidence of that today, but we have not finished verifying; the payments team will confirm by 15:00. Until then we will not say either way publicly." That phrasing is accurate, and it does not create a false assurance.

Trade-offs and pitfalls

• Reassuring early ("no data was lost") is the classic mistake; it is easy to say and expensive to retract.
• Saying nothing to legal until everything is certain can cost time on obligations that already started.
• Over-long technical briefings waste the thirty minutes; leaders need decisions, not debugging detail.

Direct answer

Interviewers expect the STAR frame: Situation (context), Task (your responsibility), Action (what you did and sent), Result (outcome and lesson). I would tell a specific story that way, with a clear situation, the messages I actually wrote, how I kept people informed and honest, and a concrete lesson. If you have never led communications in a major outage, use the closest honest example instead: a smaller customer-facing failure, a bad release you helped announce, a near-miss, or a tabletop drill (a rehearsal of a fake incident), and say plainly that it was smaller. Do not inflate it. If you only have two minutes, keep the essentials: one sentence of situation, the single hardest message you sent, how you kept the next-update promise, and one lesson. Below is an illustrative story skeleton (the numbers and names are placeholders; use your own real details, and do not embellish).

Situation

A change to a storage layer caused our file-sync product to fail for a large share of customers, and recovery took most of a working day because the fix required rebuilding data in stages. I was the communications lead (the person who owns all messages to people outside the response team) while a colleague acted as incident commander (the person coordinating the response). Executives wanted answers every hour, and several enterprise customers had contractual uptime promises (service-level agreements, or SLAs).

Task

Keep executives and customers accurately informed for the full duration without distracting the responders, and protect trust when we could not give a fix time.

Action (what I sent and how)

1. First message (within minutes): plain symptom, "investigating", next update time. It went on the status page (the public web page where customers see service health). No cause and no fix time.
2. A fixed rhythm: every 30 minutes at first, moving to hourly once stable, announced in the message so silence was expected.
3. Two versions of each update: a candid internal one (suspected cause labeled as suspected, asks of leadership) and a shorter customer one for the status page.
4. A "restored, still affected, unknown" format once partial recovery started, so no one mistook partial recovery for resolution.
5. Direct notes to key customers through account managers, using the same wording as the status page.
6. Handoff of the writer role at the end of my shift, named in the message.

Excerpt from a mid-incident message (illustrative):

Update 6, 15:00 UTC. Restored: reading files. Still affected: uploading new files. Unknown: when uploads will recover; we are rebuilding data in stages and will give an estimate once the first stage is verified. Next update 15:30.

Result

Executives stopped asking responders directly and customers received consistent messages. Describe results qualitatively like this unless you have real figures you can defend; do not invent precise numbers.

How I kept trust

• Never gave a fix time we could not support, but always gave the next update time and kept it.
• Corrected one earlier statement openly when we found it was too optimistic ("earlier we said X; now we know Y").
• Only said "resolved" after we had watched recovery.
• Published the promised review by the date I stated.

What I would do differently

• Prepare a status page template (a pre-written entry with blanks for symptom, start time and next update) and a holding statement (a short pre-approved message used until facts are known) before any incident, since we wrote the first message from scratch.
• Agree with enterprise customers in advance on what notice they get and when.
• Rotate the communications role sooner; my updates got vaguer late in the shift.

Trade-offs and pitfalls for this answer

• Do not tell a hero story; describe team roles and what you specifically did.
• A story with no failure or lesson sounds rehearsed. Pick one real thing that went imperfectly.
• Avoid unverifiable numbers ("reduced tickets by 60%"); use figures you can defend.

Direct answer. Designate one owner for the customer-facing message (the comms lead, the person who writes and sends outward messages, working under the incident commander, the person running the response), and make every team feed facts into a single shared impact log (one running document listing, per team, what is affected, since when and how sure they are) that the comms lead turns into one message. Customers should see one status entry describing total impact, expressed in terms of what customers can and cannot do, not in terms of each team's internal services.

Steps.

1. Single voice. Only the comms lead publishes. Teams do not post separate customer messages; if they have a service-specific page, it links to the central one.
2. Impact intake template. Each owning team fills the same short form in the shared channel: affected feature (customer wording), who is affected, since when, confidence (confirmed / suspected), and workaround. Same fields for everyone means the answers can be merged.
3. Translate to customer language. Three teams might say "auth-service degraded", "token cache miss" and "session store slow". The customer version is "some users cannot log in or stay logged in".
4. Take the union of impact, then reconcile conflicts. If team A says "no impact" and team B says "login failing", believe the customer-visible signal (synthetic checks, meaning scripted fake users that try real journeys like logging in, or support tickets) over an internal dashboard, and state the broader impact until evidence narrows it.
5. Tag confidence. Publish what is confirmed; mark the rest "we are investigating whether X is also affected". Avoid silently omitting a suspected area, since customers in that area will assume you do not know.
6. Refresh on a schedule. Each update restates the whole picture (not only the newest change), so a customer arriving late gets the full story.

Worked example. Team Auth reports login failures for 20% of users (they say). Team Billing says invoices are delayed. Team Search says "nothing wrong". Support tickets mention slow search results. Filled intake entries (impact log):

Team   | Feature (customer wording) | Who        | Since | Confidence | Workaround
Auth   | Logging in                 | ~20% users | 14:40 | confirmed  | Retry in a few minutes
Billing| Invoice generation         | All        | 14:50 | confirmed  | Invoices send later
Search | (none reported)            | -          | -     | -          | -

Support tickets then show slow search results, so a fourth entry ("Search: slow results, suspected, tickets") is added by the comms lead. Comms lead's post:

Investigating: Some customers are unable to log in, invoice generation is delayed,
and some are seeing slow search results. We are working on each and will post
our next update by 15:30 UTC.

Search's "nothing wrong" was overruled by customer evidence, and the post names what is confirmed versus not yet understood.

Pitfalls. Merging by team names rather than customer symptoms; understating impact to look better; letting each team publish and contradict each other; changing the wording of the same impact between updates without saying it changed.

Trade-off. One voice is slower than many, so the comms lead needs a fast intake path and pre-approved wording for the common cases.

Direct answer. Write one internal message per audience group, not one generic blast. Each states in plain terms: what failed, which of your systems are affected and how, what has been ruled out, what teams should do (or explicitly need not do), and when the next update comes. Give guidance as options with the trade-off, and leave the decision to the team that owns the service.

Draft (illustrative scenario: a third-party email-sending provider is down).

Subject: [SEV2] Email provider outage: impact by team, next update 15:30 UTC

What happened: Our email provider (Vendor X) has been failing to accept
messages since about 14:10 UTC. Vendor status page: investigating. No ETA.

Impact by team:
- Accounts team: password-reset and verification emails are not being
  delivered. Sign-ups and resets are affected. Login itself works.
- Billing team: invoice emails are queued and will send when the provider
  recovers. No action needed unless you need invoices sent today.
- Notifications team: alert emails are failing. Push and in-app alerts are
  unaffected.
- Not affected: anything that does not send email, including the API and
  dashboard.

What you may want to do (your call, you know your service best):
- Accounts: consider showing an in-app banner and offering the backup
  SMS code path. Trade-off: SMS costs more per message.
- Billing: nothing required.
- Notifications: consider temporarily routing critical alerts to push.

Please do NOT: retry-loop against the provider (it adds load and gets us
rate-limited on recovery) or tell customers a cause or ETA. Support has
approved wording; ask in #incident-comms.

Next update: 15:30 UTC or sooner if the vendor recovers.
Questions: reply in #incident-comms. Coordinator: Dana.

Terms used in the draft.

• SEV2 means severity level 2: a serious incident affecting customers or several teams, but not the worst tier (SEV1).
• Status page is the public web page where a company (or here, the vendor) posts live service status.
• Retry-loop / retry storm: code that resends a failed request again and again. If 20 services each retry every second against a provider that is struggling, that is 20 extra requests per second, and the moment it recovers they all hit at once. The provider may then throttle us (rate-limit, meaning it refuses requests over a quota), which delays our own recovery.
• Coordinator is the named person running the response (the incident commander) and the one who owns questions about the message.

Why it is written this way.

• Impact first, by team, so nobody has to read the whole message to find out whether they are affected. A team that is not affected still wants to be told so.
• "What we know / do not know" is explicit, because vague dependency outages breed rumours.
• Recommendations are labelled options with a trade-off, not orders. Teams own their own risk and know their own customers. The message only hard-restricts the two things that are unsafe for everyone (retry storms, customer-facing claims).
• A fixed next-update time stops the flood of "any news?" pings.

Pitfalls. Blaming the vendor in language you would not want quoted; instructing every team to do the same thing; omitting who to ask; promising the vendor's recovery time as if it were yours.