Crisis Communications Playbook

A crisis is any event that can seriously damage the trust customers, employees or investors place in your company, and that gets worse if you handle it badly. Score the event, write a one-page plan while nothing is wrong, run the first hour and the first day in a set order, apologise in four parts, answer the specific kind of incident you face, and then measure whether trust came back.

A startup with no communications team may find its founder writing the first public statement at midnight. This playbook is for founders and first marketers at Seed to Series B companies who want a plan ready before that night comes. It covers four kinds of incident a software company can face: a viral negative post or review, an outage, a data breach and a failure of an AI feature, with ready templates for each.

Earned media is about winning attention you want. This playbook is about handling attention you don’t. For pitching and press relationships, read the Earned Media Playbook.

If it is happening now, do this in order. Score it (Step 1), open one incident document and run the first hour (Step 3), then go to the step for your kind of incident: viral post or review, outage, data breach or AI incident. If personal data or someone’s safety is involved, call counsel before you publish anything beyond a holding line.

Not every bad moment is a crisis. Before you write anything, score the event: Reach, Harm, Truth and Velocity, 0 to 3 each (Figure 1).

Add the four scores and read the total against cut-offs you set yourself; Figure 1 shows Example Co.’s, which are fictional. A low total is noise (reply normally, or not at all), a middle total is an issue (one owner, a fix and a reply, handled inside the team that owns it) and a high total is a crisis (run Steps 3 to 5 now). One override: a Harm score of 3 makes it a crisis whatever the total, because a breach of personal data can carry legal notification duties that do not depend on how many people are watching (Step 8).

Truth raises the score because a true problem needs a fix, not only a reply. A false claim with high reach and velocity still needs a fast, calm correction (Step 6), not an apology for something that did not happen.

Crisis research asks a related question. Situational Crisis Communication Theory groups crises into a victim cluster (such as natural disasters, rumours and product tampering), an accidental cluster (unintentional technical failures) and a preventable cluster (such as human breakdown accidents and organisational misdeeds), and recommends more accommodating responses, such as apology or corrective action, as the organisation’s responsibility rises^[1]. The score above does not replace that analysis; it tells you how urgent the event is.

Score again whenever a number changes, and let whoever is on call do the first score straight away. Two traps to avoid. One is anchoring on volume: a post with fifty reposts can be noise, while a single letter from a regulator can be a crisis. The other is scoring once and never again: a post that is noise at 09:00 can double by lunchtime. Table 1 scores six example events, so you can see how the scale behaves.

A crisis plan written during a crisis is a draft, not a plan. Google’s Site Reliability Engineering book, written for engineering teams, gives a rule that applies just as well to communications: “Develop and document your incident management procedures in advance, in consultation with incident participants”^[2]. A startup’s preparation can fit on one page (Figure 2).

The one-page plan has seven parts:

1. An owner. One named person who runs communications during an incident, and a named backup. At a very small company this may be the founder. Google’s incident model separates the person who runs the incident from the communication role, whose holder is “the public face of the incident response task force” and whose duties include “issuing periodic updates”^[2]. At a very small company one person may hold both, but write them down as two jobs.
2. Decision rights. Who can publish a holding statement without waiting (the owner), who must approve a full statement (the CEO, plus counsel for anything touching personal data or law), and who can take the product or a feature offline.
3. A contact list. Phone numbers, not only email, for: the CEO, the engineering lead, the security lead, outside counsel, your forensics firm or security partner if you have one, your lead investor or board chair, your top customers’ main contacts, and your cyber insurer if you have a policy. Store it somewhere you can still reach if your own systems are down.
4. An approval chain with a clock. Set a time limit for each approval. Example Co. (fictional) allows 30 minutes for a holding statement with the owner’s approval only, and six hours for a full update with the CEO’s approval. Without a limit, approval becomes the delay.
5. A status page and a dark site. A status page, hosted apart from your main product so it stays up when the product is down, for outages (Step 7). A dark site is a page you build now and keep unpublished: a plain incident page with a headline, a date, a “what we know” section, an FAQ and a contact address, ready to fill in and publish in minutes.
6. Pre-approved holding statements. Short statements for the events you worry about most; Example Co. wrote four: outage, security incident, viral complaint and AI output problem. Have the CEO and counsel approve them in advance so only the facts need filling in. The templates near the end of this playbook are a starting point.
7. Monitoring. Alerts on your company and product names across social platforms, review sites and news; a support-queue alert when tickets spike above normal; and a shared channel where anyone in the company can flag “this might be something”. A warning can come from a customer or an employee, so make flagging easy.

At a small company the roles are few. Google’s incident model names four: incident command, operational work, communication and planning^[2]. A small company can start with an owner for communications, an incident lead who runs the technical response, a spokesperson (Step 5) and a scribe who keeps the timeline in the incident document. One person can hold more than one role; write down who holds which.

Practise it. In a tabletop exercise you walk the team through a scenario such as Example Co.’s and time how long the holding statement takes. Google’s chapter puts the principle simply: “Use the process routinely so it becomes second nature”^[2].

Speed matters, and so does tone. Research on “stealing thunder”, where an organisation discloses a crisis before the media does, found in an experiment that the strategy worked only when participants did not recognise persuasive intent in the message^[3]. In plain terms: tell people early, and tell it straight, not as spin.

The first hour

• First: confirm what you can. Open one living incident document with a timeline, the facts confirmed, the facts not yet confirmed and the decisions made. Google’s chapter calls keeping a living incident document the incident commander’s “most important responsibility” and says it “can be messy, but must be functional”^[2]. Name the incident lead and the communications owner in the first line.
• Next: score it (Step 1). Contain the harm first: Google’s ordering is “Stop the bleeding, restore service, and preserve the evidence for root-causing”^[2]. Pause the release, turn off the feature, freeze the affected accounts.
• Then, within the first hour if you can: publish a holding statement where people are already looking: the status page, a reply under the viral post, or both. Send the internal note to every employee at the same moment or just before (template below). Employees may be asked by friends and customers, and they should not learn about it from LinkedIn.

The first day, in this order

1. Employees: what happened, what we are doing, who speaks for the company, and “please don’t comment publicly; send questions to [owner]”.
2. Affected customers, directly: an email or a call from a named person, before any broad public statement where possible. Put what they need to do first; crisis research puts “instructing information”, telling people what to do to protect themselves, ahead of reputation^[1].
3. Lead investor and board: a short factual message before they read about it.
4. All customers and the public: a fuller update by the end of day one: what happened, who was affected, what you have done, what happens next, and when the next update will come.
5. Press: answer the reporters who ask, with one spokesperson and the same facts (Step 5). Do not send a press release about your own crisis unless the scale needs one.

Then give regular updates until it is resolved, each naming the time of the next one, and set a date for the postmortem (Step 10).

When you do not know yet, say so in three short parts: what you know, what you do not know yet, and when the next update will come. “We know invoices were sent with the wrong line items. We do not yet know how many customers were affected. Next update at 14:00.” Then keep the 14:00 promise even if the update only says “still investigating”.

When you got something wrong, I check an apology against four parts (Figure 4).

1. Acknowledge what happened, in plain words, and who it affected. “On Tuesday our software sent 14 invoices containing another business’s details to the wrong recipients.”
2. Take responsibility without qualifiers. “This was our error.” Not “mistakes were made”, not “a third-party component”, not “if anyone was affected”.
3. Fix it for the people harmed: what you have done and what you will do for them, with dates.
4. Prevent it: the change that stops it happening again, specific enough to check later. “Every release that touches invoice data now requires a second engineer’s review and an automated test that blocks mismatched line items.”

Match the apology to the responsibility. Coombs and Holladay recommend “highly accommodative crisis response strategies, such as apology or corrective action” for organisational misdeeds, and, for a victim crisis such as product tampering, instructing information alone, with denial added for rumours^[1]. Atlassian’s incident communication guidance makes the matching point about size: an apology “should sound sincere and be in proportion with the actual impact”^[4]. Proportion is yours to judge: a short blip and leaked customer data call for different apologies.

Table 2 sets out phrases that weaken an apology, and what to say in their place.

If counsel is involved, agree the wording of responsibility with them before you publish.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Having one prepared spokesperson keeps the facts consistent and keeps everyone else out of the line of questions.

Pick one spokesperson and a backup, and write both in the plan. At Example Co. it is the CEO. Everyone else, including investors and advisers, says “I’ll put you in touch with [name]” and nothing more.

Prepare three answers. Before any call, write two or three sentences for each of three questions: what happened, who was affected, and what are you doing about it. Add the one question you least want to be asked, and write an honest answer to it. Table 3 shows Example Co.’s.

Speak on the record. During a crisis, say only what you would be willing to see published with your name on it. If you do want to talk off the record or on background, agree the ground rules with the reporter before you say anything.

Say what you can instead of “no comment”. Say what you can, and why you can’t say more: “We’re still investigating the cause and I won’t guess. Here is what we know now, and we will publish an update at 4 p.m.”

Correct errors, calmly. If coverage gets a fact wrong, send the reporter a short note with the correct fact and the evidence, and ask for a correction. Do not argue about tone or headlines.

Stop other publicity. Pause scheduled launches, promotional posts and cheerful newsletters until the crisis is resolved.

A negative social post or review that starts to spread needs a short, ordered response. It has five moves.

1. Verify. Is the person a customer? Can you reproduce the problem? Is the screenshot real and current? Check before you reply, but check quickly.
2. Respond publicly, once. One reply where the post is: acknowledge the problem, state the facts you have confirmed, say what you are doing, and offer a named person and a direct contact. Keep it short and human. The reply is for everyone reading, not only the poster.
3. Move it private. Continue by email or phone.
4. Correct facts, not feelings. If the post is wrong on a fact, correct it once, politely, with the evidence. Do not dispute someone’s experience or frustration.
5. Close the loop in public. When it is fixed, add one short follow-up under your original reply, with the customer’s agreement if you mention them.

When not to respond. Not every post deserves a reply. Leave alone posts that score as noise in Step 1, accounts that only want a reaction, and claims about a dispute already with lawyers, where counsel should decide. Do not reply from several company accounts at once. Table 4 sorts the common cases.

Never astroturf. No fake reviews or posts, no staff posting as “happy customers” without saying who they are, no paying people to bury a complaint, and no threats. In the US, the FTC’s Rule on the Use of Consumer Reviews and Testimonials (16 CFR Part 465) has been in effect since October 21, 2024, and the FTC says it “authorizes courts to impose civil penalties for knowing violations”^[5]. The rule covers fake reviews (§ 465.2), and its review-suppression section (§ 465.7) covers using “an unfounded or groundless legal threat, a physical threat, intimidation, or a public false accusation” in response to a review to stop it being written or to get it removed, and misrepresenting displayed reviews as all or most of those submitted when negative ones have been suppressed^[6]. The FTC’s own Q&A confirms that “you can respond publicly to the review, and yes, you should watch what you say”, and that the rule does not stop you contacting customers to resolve their problem^[5]. Platforms have their own rules too; the Review Sites for Startups guide covers G2’s and Capterra’s.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

During an outage, customers want to know what is going on. A status page answers that question before they have to ask.

Use the four stages. Atlassian’s Statuspage guidance describes four incident stages, with wording such as: Investigating (“We’ve been alerted, and we’re looking into a potential problem”), Identified (“We’re announcing that we’ve identified a problem”), Monitoring (“We think we’ve found a solution and we’re monitoring it”) and Resolved (“We’ve resolved the incident”)^[4]. Figure 5 shows Example Co.’s four posts.

Write each update in this order. A plain title, what is affected and who, what you are doing, and when the next update will come. Atlassian advises you to “Choose a title that plainly explains the nature of the incident” and to “Let people know when they can expect to hear from you next”^[4]. Google’s incident chapter gives the communication role the duty of “issuing periodic updates”^[2].

Set your own timing in the plan. Post as soon as you confirm customers are affected, even if it only says you are investigating; name the next update time in every post and keep that promise even when there is nothing new; and end with a Resolved post that acknowledges the impact. Atlassian suggests you “acknowledge any frustration or loss of productivity people likely experienced”^[4].

Design the page for a worried reader. Four choices: host it apart from your product, so it stays up when the product is down; show which part of the product is affected, not only that something is “degraded”; let people subscribe by email so they hear without checking; and link it from your help menu and email footer before you need it.

After a major outage, publish a short public postmortem: what happened, why, what you changed. Step 10 explains how.

In a data breach, communications should follow the investigation and the law rather than lead them. The first call is to counsel and, if you have one, a forensics or security partner, before any public statement beyond a holding line. The FTC’s breach guide for business advises: “Assemble a team of experts to conduct a comprehensive breach response”, suggests you “Consider hiring independent forensic investigators to help you determine the source and scope of the breach”, and notes that legal counsel “can advise you on federal and state laws that may be implicated by a breach”^[7].

What communications does in a breach

• Says only what forensics has confirmed. Say “we are investigating” and give the next update time rather than guessing at scope.
• Puts instructions first. What should affected people do now: reset a password, watch for phishing, contact a named address.
• Is honest and complete. The FTC’s guide says: “Don’t make misleading statements about the breach. And don’t withhold key details that might help consumers protect themselves and their information”^[7].
• Avoids loaded words until the facts support them: “sophisticated attack”, “no evidence of misuse”, “only a small number of users”.
• Uses one incident page (your dark site from Step 2) for all updates and FAQs, so customers, reporters and regulators read the same facts.

Notification rules exist, and they have clocks

This is orientation only, so you know to ask counsel about them early (Figure 6).

• EU data protection (GDPR). Article 33 requires a controller to notify the supervisory authority of a personal data breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to people’s rights and freedoms. Article 34 requires the controller to tell affected individuals “without undue delay” when the breach is likely to result in a high risk to them^[8].
• US public companies. Since the SEC’s 2023 rules, registrants must “disclose on the new Item 1.05 of Form 8-K any cybersecurity incident they determine to be material”, generally “due four business days after a registrant determines” that the incident is material^[9]. In the final rule, the SEC revised the instruction so that companies must make the materiality determination “without unreasonable delay”^[10]. Filing may be delayed if the US Attorney General determines that disclosure “would pose a substantial risk to national security or public safety” and tells the SEC in writing^[9]. Item 1.05 appears in the SEC’s current Form 8-K (SEC Form 8-K^[11], revision 02-25). These rules apply to public companies only.
• US states. The FTC notes that “All states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information”^[7]. Ask counsel which of them apply to you.
• US health apps. The FTC’s Health Breach Notification Rule (16 CFR Part 318) covers vendors of personal health records, PHR related entities, and third-party service providers to them^[12],[13]. The rule defines a personal health record as an “electronic record of PHR identifiable health information on an individual” that “has the technical capacity to draw information from multiple sources” and is “managed, shared, and controlled by or primarily for the individual”^[13]. The FTC says its 2024 amendments underscore “the Rule’s application to most health apps and similar technologies”^[14]; whether your product fits the definition is a question for counsel. It requires notice to affected people “without unreasonable delay” and “within 60 calendar days after the breach is discovered”, notice to the FTC at the same time for breaches of 500 or more people, and notice to prominent media when “at least 500 residents of a particular state” are affected^[12]. It does not apply to HIPAA-covered entities, or to businesses acting only as HIPAA business associates^[12],[13].
• HIPAA-covered entities and their business associates follow the HHS Breach Notification Rule instead. A covered entity must notify affected individuals “without unreasonable delay and in no case later than 60 days following the discovery of a breach”, and prominent media for breaches affecting “more than 500 residents of a State or jurisdiction”. A business associate must tell the covered entity, without unreasonable delay and within 60 days of discovering the breach^[15]. If you sell to providers as a business associate, that notice to your customer is the first clock you will meet.

Contracts may add their own deadlines: a customer agreement may require you to tell the customer within a set number of hours or days. Check yours before you need them. Table 5 turns the clocks into a who-to-tell list for the first day.

For the security story you tell before anything goes wrong, see How to Make Security a Selling Point and the Security Questionnaire Answer Library. Promises made there are the ones a breach will test.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

An AI product incident is when your product’s output causes harm or embarrassment in public: a chatbot gives dangerous advice, an assistant invents a fact that a customer relied on, or a screenshot of an offensive answer goes viral. The playbook is the same as for any crisis, with four additions (Figure 7).

1. Reproduce it and keep the evidence. Save the prompt, the output, the model and version, the settings and the time. Check that the screenshot is genuine, and whether the person was deliberately trying to break the product’s safeguards. Find out before you respond, but don’t use “the user tricked it” as your public answer.
2. Decide whether it is one output or a pattern. Test similar prompts. One strange answer is a bug to fix; a repeatable failure means the feature should be limited or turned off until it is fixed.
3. Own the output. “The model hallucinated” is a description, not an apology. Say what you shipped, what went wrong and what you changed: a guardrail, a narrower scope, human review, or a feature switched off.
4. Check your claims. If your website says “accurate”, “safe” or “never makes things up”, the incident has just tested that claim in public. Change the claim before someone quotes it back to you. The Marketing AI Products Playbook shows how to check every claim before you publish, and How to Market an AI Product covers building trust you can keep.

Keep one evidence sheet per incident, and write it as you go: the date and time; the exact input and output; the model and version; the settings and any retrieved documents; who reproduced it and how; whether similar inputs fail; the customers affected; and the decision taken, by whom, and when. It is the page counsel and the postmortem will both ask for.

If the output touched health, money, employment, children or another regulated area, or if someone may have been harmed, bring counsel in at once, as in Step 8.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

Two jobs remain after the post stops trending: learn from the incident, and measure whether recovery is real.

Run a blameless postmortem. Write down what happened, the timeline, why it happened, what worked and what didn’t in the response, and the actions, each with an owner and a date. Google’s SRE book says postmortems are “expected after any significant undesirable event”, and calls blameless postmortems “a tenet of SRE culture”, because otherwise “people will not bring issues to light for fear of punishment”^[16]. Review the communications as well as the engineering: how long did the holding statement take, did customers hear from you before they heard about it, did any update promise a time and miss it? A one-page outline is enough: summary, impact, timeline, cause, what went well, what did not, communications review, and actions with owners and dates.

Publish what customers need. For a serious incident, publish a shorter version: what happened, why, and what changed. Then do the changes you promised, and tell customers when they are done. That last message is the one most teams forget.

Measure recovery against your own baseline. I give no benchmark for crisis recovery here. Compare each measure with a baseline period you fix before an incident; Example Co. uses the four weeks before it (Figure 8):

• Sentiment: the share of mentions of your name that are negative, week by week.
• Churn: cancellations in the weeks and months after, compared with your normal rate.
• Support volume: tickets per day, and how many mention the incident.
• Search and AI answers: how many of the top 10 search results for your company name mention the incident, and what AI answer engines say when asked about your company. Check on a regular schedule.

Worked example (fictional). Example Co. normally loses 1.5% of its 600 accounts a month: 9 accounts. In the month after the incident it loses 15. Excess churn = 15 − 9 = 6 accounts. At an average of $150 a month per account, that is 6 × $150 = $900 a month in lost recurring revenue, or $10,800 a year, which gives the board a number for what the incident cost and what preventing the next one is worth. Support tickets, normally about 40 a day, peaked at 210 on Tuesday and were back to 46 by day 10. Negative mentions were 4% of the total before, 61% on Tuesday and 9% three weeks later. Two of the top 10 search results for “Example Co.” still mention the incident a month on.

Templates: holding statement, customer email, status update, internal note, breach notice, statement about a person

These templates use fictional Example Co. and are a starting point, not finished wording. Change every bracket, cut anything that is not true for you, and have the CEO and, where personal data or law is involved, counsel approve your versions before you need them.

Holding statement (public, within the first hour)

Holding statement

We’re aware that [short, plain description of the problem] since [time, time zone]. We’re investigating now, and [what you have already done, e.g. “we have turned the feature off”]. If you are affected, [one instruction, e.g. “you don’t need to do anything yet” or “please reset your password”]. We’ll post our next update at [time] on [status page or incident page URL]. Questions: [named contact and address].

Customer email (to affected customers, same day)

Customer email

Subject: What happened with your invoices on [date], and what we’re doing

Hi [first name],

On [date] at [time], a change we released caused [what happened], affecting [what, for this customer specifically, e.g. “2 of your invoices sent to clients that morning”]. This was our mistake, and I’m sorry.

What you should do: [specific instruction, or “nothing; we have handled it”]. What we’ve done: [containment, e.g. “turned the feature off at 10:30 and reissued the affected invoices”]. What we’ll do next: [the fix and the prevention, with dates].

[Name], [title], will contact you by [time] today. You can also reach me directly at [email or phone].

[CEO name], CEO, Example Co.

Status update (one per stage)

Status update

Investigating: [Feature] is unavailable for [who]. We’re investigating. Next update by [time].

Identified: We’ve found the cause: [plain cause]. We’re [fixing / rolling back]. [Feature] remains unavailable. Next update by [time].

Monitoring: A fix is in place and [feature] is working again. We’re monitoring. Next update by [time].

Resolved: [Feature] has been working normally since [time]. We know this cost many of you [impact, e.g. “a morning of billing work”], and we’re sorry. We’ll publish what happened and what we’re changing by [date].

Internal note (to all staff, before or with the public statement)

Internal note

Subject: Incident today: what happened and how we’re handling it

Team, at [time] [what happened, in two sentences]. [Incident lead] is running the response and [communications owner] is handling all communications.

What we’ve done: [containment]. What customers have been told: [link to statement]. If anyone outside the company asks you, including customers, friends, reporters or investors: please don’t comment, on social media or anywhere else. Say “I’ll put you in touch with [owner]” and send them to [address]. If you notice anything new, post it in [channel].

Next internal update at [time]. Thank you for keeping calm with customers today.

Breach notice (to affected customers, after counsel has reviewed it)

Breach notice

Subject: A security incident that affected your data: what happened and what to do

Hi [first name],

On [date] we found that [plain description of what happened and when it started]. The information involved was [exactly which data, for this customer]. We have confirmed [what forensics has confirmed], and we are still investigating [what is not yet known].

What you should do now: [specific steps, e.g. “reset your password; watch for emails asking you to confirm account details”]. What we have done: [containment and fixes, with dates]. What we are doing next: [the prevention, specific enough to check].

We will update this page at [time]: [incident page URL]. You can reach [named person] at [phone and email]. We are sorry this happened.

Statement about an incident involving a person (an employee, an executive or a customer)

Statement about a person

We’re aware of [a post / a report / an allegation] about [a person’s role, not their name unless counsel agrees]. We take it seriously. [We have started an independent review / We are looking into it] and will not comment on the details while it continues. Anyone who has information can contact [named person] at [address] in confidence. We’ll update this statement by [date] or when there is a decision to share.

Before you publish: counsel reviews it; the person’s role and rights are respected; nothing prejudges the outcome; and colleagues who raised concerns are protected from retaliation.

This is general information, not legal, financial or medical advice. Check with a qualified professional.

What changes by stage?

What mistakes should I avoid?

• Silence in the first hour. Publish a holding statement as soon as you can (Step 3).
• Guessing. Say what you know and when you’ll know more (Step 8).
• Blaming someone else. A vendor, a user or “the model” may have played a part; say what you shipped and what you changed (Steps 4 and 9).
• Saying “no comment” and nothing more. Say what you can and when you will say more (Step 5).
• Deleting, threatening or astroturfing. In the US the FTC’s review rule covers fake reviews and review suppression (Step 6).
• Too many voices. One spokesperson, one reply (Steps 5 and 6).
• Forgetting employees. Tell staff before the public hears (Step 3).
• Declaring victory early. The incident is over when the measures in Step 10 are back to baseline and the promised changes are done.

This is general information, not legal, financial or medical advice. Check with a qualified professional.