Incident Communication and Stakeholder Management Questions

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

Run one incident with two tracks. Engineering keeps fixing and contains the problem, while a single communications lead moves verified facts from engineering to legal, then to compliance and communications. Legal decides whether a legal duty to notify exists and when the notification clock started. Speed comes from preparing every notification draft in parallel while investigation continues, so that when legal says go, the text is already written. (This is awareness-level: engineers do not decide legal questions, they supply reliable facts and timestamps.)

Roles and flow

Rules that keep this fast: one channel, one fact sheet (never facts passed by chat memory), and every fact carries a timestamp and a source.

The notification clock, with two real examples

(The article and item numbers are for orientation; interviewers care that you know two clocks exist and start at different events.)

• Under the GDPR (EU General Data Protection Regulation), Article 33 requires notifying the supervisory authority (the regulator) within 72 hours of becoming aware of a personal data breach, where feasible. Information may be supplied in phases if not all is known yet.
• In the US, a public company that determines a cybersecurity incident is material must file a Form 8-K (a current report to the US securities regulator, the SEC) under Item 1.05 within four business days of that materiality determination. Material means important enough that a reasonable investor would want to know: for example a breach that disrupts core operations or exposes large amounts of customer data. Deciding it is a judgement call made by counsel and executives, and the date they decide starts the clock. The SEC rule also requires that determination to be made without unreasonable delay after the incident is discovered, so the clock cannot be postponed by leaving the question open; the log should show when the assessment began and when it concluded.

Other regions and sectors have their own rules and forms. Counsel keeps that list, not engineering. Point to note: the clocks start from different events ("becoming aware" versus "determining materiality"), so the log must record both moments.

Worked example (illustrative)

Discovery confirmed Tuesday 09:10 UTC. 72 hours later is Friday 09:10 UTC. Checkpoints the tracker holds (the second clock is shown after this list):

• Tue 12:00: first fact sheet to legal; legal starts the region-by-region list.
• Wed 09:00: draft regulator notice and customer message ready (based on what is known, marked "to be supplemented").
• Thu 09:00: legal decision per region; final numbers frozen at that time.
• Thu evening: submit, leaving a buffer before Friday 09:10.

A sample row of the fact sheet: Records affected: at least 12,400 (preliminary) | Source: storage access logs | Timestamp: Tue 11:40 UTC | Owner: security lead | Status: confirmed, count may rise.

Second clock (US public company, illustrative): on Wednesday 14:00 UTC counsel and executives determine the incident is material. Business days start counting the next day: Thursday is day 1, Friday day 2, Monday day 3, Tuesday day 4. The 8-K is due by end of Tuesday. The tracker therefore holds two rows with different start events: Aware: Tue 09:10, GDPR due Fri 09:10 and Material: Wed 14:00, 8-K due Tue end of day.

Keeping speed while respecting rules

• File an initial notice with known facts rather than waiting for a full investigation, then supplement.
• Do not let engineering statements go public on their own. A casual "no customer data affected" in a chat or forum can be wrong and can be a regulatory problem.
• Draft in parallel for every region, so one region's review does not block another.

Pitfalls

• Starting the clock in your head at the wrong event. Ask counsel and write the decision down.
• Over-sharing unverified numbers to look transparent, then having to correct them to a regulator.

Direct answer. For a mid-sized SaaS company (roughly a few hundred people, tens of engineering teams, one status page, a support team), I would use a hybrid: a small, central comms function owns customer-facing communication, its tooling and its standards, while the teams that own the failing service supply the facts and are on the hook for accuracy. Central ownership of voice and channel, team ownership of truth.

Terms used below. SEV1 and SEV2 are severity levels: SEV1 is the worst (a major, widely felt customer-facing outage) and SEV2 is serious but narrower. The incident commander is the person running the response. The comms lead is the person who writes and sends the outward updates. The status page is the public web page where customers read incident updates. The impact log is a shared running record of confirmed facts about who is affected and how, so every message uses the same numbers.

Why not fully central. A central comms team that is not technical becomes a relay: it waits for engineers to explain, adds delay, and may misstate technical detail. It also cannot be on call for every service at mid-size scale without becoming expensive.

Why not fully team-owned. Ten teams writing ten differently-toned, differently-timed updates confuses customers, contradicts itself during multi-service outages, and skips the legal and support checks. Each team also rarely practises it, so quality is poor when it counts.

The hybrid, concretely.

Worked example. A SEV2 affecting only the reporting feature: the reporting team's on-call posts from the template, and the central function audits afterwards (it reviews what was posted against the template, and fixes tone or gaps for next time). A SEV1 login outage across three services: a trained comms lead posts one message from the shared impact log.

What would change my choice.

• Much smaller company (under about 50 engineers): team-owned with a shared template is enough; a central function would be overhead. The 50 is a rough rule of thumb, not a standard: at that size people know each other and share context, so a dedicated function costs more than it saves.
• Regulated industry or enterprise customers with contractual notice obligations: lean more central, with legal in the loop.
• Very large company with hundreds of services: central function plus embedded comms partners per business unit (a named comms person who sits inside each business unit, knows its products and customers, and follows the central standards).
• A history of inaccurate updates: tighten team accuracy accountability, not just centralise the pen.

Pitfalls. Central owner without authority to demand facts; team owners who are never trained; unclear handoff of severity thresholds (who decides "this is now a central incident?"). Define that threshold in writing: for example, customer-visible and more than one team, or expected to last over 30 minutes. The 30 minutes is an illustrative cutoff, roughly where customers start noticing and support tickets pile up; tune it to your own incident history.

Direct answer

Treat customer reports as evidence until proven otherwise. Tell customers plainly that we believe them and are investigating, ask for specific data that lets us find the failing requests, and give a next-update time. Internally, open a low-severity incident with one named owner, so the investigation has a channel and a clock. Never tell a customer "our monitoring shows no problem".

What to ask customers for

• Exact timestamps with time zone (three or four examples, not "sometimes").
• Request or correlation IDs (an identifier attached to each request so we can trace it through logs), or the full error text and HTTP status code.
• Account or tenant ID (a tenant is one customer's account in a system shared by many customers), region, and which endpoint or screen.
• Client details: browser or SDK version, mobile or web, network (office, VPN, mobile data).
• How often (1 in 10 requests? only large uploads?) and whether it began after any change on their side.
• Whether a retry succeeds, since that points to flaky dependencies rather than a hard failure.

Why dashboards can be clean while customers are right

1. Averages and 5-minute rollups (metrics squashed into one number per 5-minute bucket) hide short spikes. Check P99 (the latency that 99 in 100 requests beat). Example: in one 5-minute window, 9,800 requests take 100 ms and 200 take 10,000 ms. The average is (9,800 x 100 + 200 x 10,000) / 10,000 = 298 ms, which looks healthy, but sorting the requests from fastest to slowest, the 9,900th (the P99) is 10,000 ms, and 1 in 50 requests waited 10 seconds.
2. Metrics may cover the wrong layer: healthy servers behind a load balancer (the component that spreads traffic across servers), while the CDN (content delivery network) edge, the outer servers customers reach first, or the client side fails.
3. A small slice (one tenant, one region, one request size) vanishes inside a global rate. Cut by tenant and region.
4. Requests that die before reaching our code (DNS, which looks up a site's address; TLS, which encrypts the connection; the edge) never appear in application metrics.
5. Sampling (recording only a fraction of events) or log gaps may drop exactly the failures.

Internal communication

• One incident channel, one investigator, one person handling customer contact so support does not improvise.
• Post a hypothesis list ("edge, one shard, third-party dependency", where a shard is one slice of a split database) and mark each confirmed or ruled out.
• Give support an approved holding line and tell them what to collect, so every ticket arrives with the fields above.
• Set escalation triggers in advance: raise severity if three independent customers give matching evidence, or if a paying tier is affected.

Worked example (illustrative)

Customer message: "Thanks for flagging this. We can't see a fault on our side yet, but that doesn't mean you're wrong, and we are investigating. Could you send two or three request IDs with times (including time zone) where you saw an error, plus the error text? We will update you by 16:00 UTC even if we have nothing new."

Internal note: "Low-severity investigation opened. Owner: A. Kim. Three reports, all EU tenants, all file uploads. Checking edge logs and P99 for uploads first. Support: please collect request IDs, do not promise a fix."

Pitfalls

• Saying the fault is on the customer side before evidence exists.
• Asking for logs the customer cannot produce. Ask for things they can see.
• Silence: a "still investigating, next update at X" is worth sending.

Direct answer

Split the roles so the person fixing the problem never has to explain it. I would take the communications role explicitly, say so in the incident channel, and become the only bridge between the responder and everyone else. Stakeholders read a scheduled update; they do not message the responder. I read the responder's terse notes as data, not as rudeness.

Structured approach

1. Name the roles out loud. "I am communications lead. A. is fixing. J. is incident commander (the person coordinating and deciding). Send questions to me."
2. One channel for the fixer, one for readers. The responder works in a small working channel or call. Stakeholders get a separate read-only updates channel.
3. A fixed update rhythm. Every 30 minutes for a severe incident, as a clock time ("next update 15:30"). A predictable schedule removes most "any news?" messages.
4. Ask closed questions. Not "what's going on?" but "Is the database confirmed as the cause: yes, no, or unknown?" I can pick up answers by watching the channel and the terminal notes.
5. Absorb pressure. When an executive pings, I reply "next update at 15:30; here is the current state." If they push, I hand it to the incident commander, not the responder.
6. Watch the human. Long incidents need relief: offer a second engineer, food, or a handoff after several hours. Tired people make risky changes.

Worked example (illustrative)

Responder types: "rolled back, watching err rate".
My update: "14:40 UTC. Cause suspected: today's deploy. Rollback done 14:38. Error rate falling; confirming recovery. Next update 15:10."
Private message to responder: "Thanks. I have posted that. Reply 1 if recovery is confirmed, 2 if not, and I will do the rest."
Executive asks: "What is going on?" Reply: "Rollback completed, recovery being confirmed, next update 15:10. I will page you if that changes."

Trade-offs and pitfalls

• The communicator must not become a second decision-maker giving instructions to the responder. Decisions go through the incident commander.
• Avoid inventing facts to fill an update. "Unknown" is a valid line.
• Do not correct the responder's tone. Terse under stress is normal, and a blameless culture (no punishment for honest actions during an incident) depends on that.
• If an executive insists on talking to the responder, it goes through the commander, who decides whether the interruption is worth it.