How to develop a crisis management plan for startups (without a legal team or a spare quarter)
The week I'm thinking about started with a Slack message at 6:40 on a Tuesday: our payment processor had frozen the account. No warning, no ticket number, just a login screen that said "account under review." We had eleven days of runway in that account. Forty-one customers were about to get failed charges, and I had no idea who was supposed to call them, what we were allowed to say, or whether our terms of service even covered this. We survived it. Barely. And the reason we survived was luck, not preparation.
That's the ugly truth about crisis management for startups: the plan you need isn't the one a Fortune 500 legal department writes. It's a two-page document that fits in your head at 6:40 in the morning when your hands are shaking. Below is the version I built afterward, tested twice, and I'll tell you where it failed.
Key takeaways
- A startup crisis plan should be two pages, not forty. If it doesn't fit on your wall, you won't read it under stress.
- Name a single spokesperson. Everyone else stays silent. This one rule prevents most self-inflicted damage.
- Your five biggest risks are almost always: money, key person, a top client, a data breach, and a public founder statement.
- Run one 90-minute tabletop exercise per quarter. That's it. That's the whole testing budget a seed-stage company needs.
- Write the investor message before the crisis, not during it. Panic produces bad emails.
What are the 5 P's of crisis management?
People ask me this constantly, and the honest answer is that the 5 P's aren't scripture. Different consultants list different words. What matters is the underlying logic, so here's the version I actually use with startups, because it maps onto decisions you can make with eight people in a room:
- Predict — list what could actually break you. Not "the economy." Specific things.
- Prepare — decide who does what, in advance, in writing.
- People — your team, your customers, and their safety and trust come before your reputation.
- Publish — one voice, one channel, one message, fast.
- Post-mortem — what changed, what you'll fix, what you learned. Skip this and you'll repeat the crisis.
Some frameworks swap in Prevent, Perform, or Partners. Doesn't matter. The sequence is what counts: think before, act during, review after. If your plan only covers the middle phase, you have a fire extinguisher, not a plan.
Why the framework matters less than you think
Here's where I'll be blunt. I've watched two founders memorize the 5 P's and then freeze completely when a journalist emailed asking about a leaked customer list. Memorizing categories doesn't create reflexes. Rehearsing specific scenarios does. The 5 P's give you a checklist for building the plan. The plan itself has to be concrete: names, phone numbers, exact sentences you're allowed to say.
What makes a startup crisis different from a corporate one
Two hundred employees. A comms department. An outside counsel on retainer at $900 an hour. That's the world most crisis-management advice is written for, and none of it fits you.
A startup has three constraints that change everything:
| Constraint | What it means in a crisis | Lean workaround |
|---|---|---|
| No dedicated comms person | The founder is the spokesperson by default | Write three holding statements now, keep them in a shared doc |
| Short cash runway | You have weeks, not quarters, to recover trust | Prioritize the revenue-critical relationships first |
| Concentrated dependencies | Losing one client or one payment rail can be fatal | Map your single points of failure before they snap |
| Small team, overlapping roles | The same person handles tech and customer calls | Pre-assign a deputy for every critical role |
That last row is the one people miss. In a fifteen-person company, your CTO is also your incident commander and probably your on-call engineer. If they're the one having a bad day, you need a name written down for who steps in. Ours was the head of support. She'd never touched infrastructure in her life, but she could read a runbook out loud and keep people calm, which turned out to be the actual job.
Map your single points of failure first
Take thirty minutes. List every dependency that, if it vanished tomorrow, would stop you operating. For us that was: one payment processor, one cloud region, one enterprise client at 31% of revenue, and one engineer who understood our billing code. Four items. Four risks. That's your entire priority list, and it's shorter than you feared.
Building the two-page plan
Page one is a grid. Page two is scripts. That's it.
Page one: the response grid
Four columns: scenario, first 30 minutes, owner, who we tell. Fill in five rows. Ours looked roughly like this, and I'll admit the fourth row was added only after we nearly needed it:
- Payment or infrastructure outage — owner: CTO, notify: affected customers within two hours
- Data breach or leak — owner: CTO plus external counsel, notify: legal first, then customers, never the reverse
- Loss of the largest client — owner: founder, notify: board within 48 hours
- Founder unavailable or incapacitated — owner: designated deputy, notify: board immediately
- Public accusation or viral criticism — owner: founder as sole spokesperson, notify: nobody until facts are confirmed
Notice what's missing: any mention of a press release, a crisis agency, or a war room. At seed stage those are theater. What you need is a decision tree short enough to follow while your heart rate is at 140.
Page two: the scripts
Write three sentences you'll never improvise. One for customers, one for your team, one for investors. Keep them under sixty words each. The customer version we used during the payment freeze was:
"We're aware some charges failed today. Your account is safe and no data was affected. We'll have this resolved within 24 hours and will email you the moment it's fixed. Reply here if you need anything now."
Fifty words. It bought us eight hours of goodwill. Vague reassurance would have cost us customers.
The crisis communication plan: one voice, three audiences
The single most common startup mistake in a crisis is having three people answer the same question differently. I've done it. Our support lead told a customer "it's a billing glitch" while I was telling an investor "there may be a compliance issue." Same event, two stories. That investor called back within an hour, and the conversation was considerably worse than it needed to be.
Rule: one spokesperson, and during the acute phase that person is usually the founder. Not because founders are good at this, but because investors and customers want to hear from the person whose name is on the company.
What to say to your investors
Investors have seen this before and they mostly want three things: what happened, what it costs, and what you're doing about it. Send that in the first 48 hours, in plain language, before they read about it elsewhere. Hiding a problem from your board is the one move that reliably converts a manageable incident into a fundraising disaster.
If you have a board, add one line to your plan: who calls whom, and in what order, when the news is bad. Ours is now written into the plan itself, with phone numbers, because email is too slow at 7 a.m.
What never to say
- "No comment." It reads as guilt even when you're innocent
- Speculation about cause before you've confirmed it
- Anything you wouldn't want screenshotted
Testing: the part everyone skips
An untested plan is a document, not a capability. I learned this the hard way when we ran our first tabletop exercise and discovered that our "emergency" phone tree relied on a Slack workspace that would be down in exactly the scenario we were rehearsing. Obvious in hindsight. Invisible until we practiced.
Run one exercise per quarter. Ninety minutes. Pick a scenario from page one, announce it, and watch what happens. Don't fix anything mid-exercise; just take notes. Then spend twenty minutes afterward on the three things that broke.
Two other habits worth building: keep a shared "crisis log" during real incidents so you're not reconstructing events from memory later, and set a calendar reminder every six months to update phone numbers and ownership. People leave. Plans rot quietly.
How often should you update the plan?
Twice a year, plus any time your team changes by more than a couple of people or you add a major dependency. If your plan still names someone who left last spring, it's not a plan. It's a liability with a nice cover page.
The thing nobody tells you
Every crisis I've been through had the same shape: the actual event was less expensive than the improvised response to it. The frozen account cost us nothing in the end. The two weeks of confused messaging, contradictory emails, and one investor who found out third-hand cost us far more.
So don't start by writing a document. Start by naming your four single points of failure and the one person who speaks when things go wrong. That's an hour of work, and it's most of the value. The rest is rehearsal, and rehearsal is just deciding in advance that you'd rather be embarrassed in a meeting than in public.
Which scenario would actually take you down right now? Write it down. Then write the name of the person who handles it. You've just started your crisis plan, and it took less time than reading this article.
