Incident Response Plan for a Startup: A Fill-In Outline

Small teams often skip roles because everyone is 'just helping'. That's how two people fix the same thing while nobody updates customers. Define three roles, even if one person holds two of them:

• Incident commander: makes decisions, keeps the timeline, and decides when to escalate or stop. This person should not also be the one typing commands.
• Operations lead: investigates and fixes. Requests help from other engineers through the commander.
• Communications lead: posts internal updates and customer-facing messages on a fixed rhythm, so engineers aren't interrupted for status.

Write the name of the primary and backup for each role for the current on-call period. A plan that says 'the CTO' with no backup fails the day the CTO is on a flight.

Keep the opening sequence short enough to memorize:

1. Acknowledge the alert and open a dedicated channel or call for the incident.
2. Name the incident commander out loud or in the channel.
3. Assign a provisional severity using your severity definitions, and revise it as facts arrive.
4. Post a first internal update that states what is known, what isn't, and the time of the next update.
5. Check the obvious first: the last deploy, recent config changes, and upstream provider status pages.
6. If customers are affected, have the communications lead publish a short status message before the cause is known.

For paging and incident tooling, see the comparison in PagerDuty vs Opsgenie vs incident.io.

Suspected compromise changes priorities. Speed of recovery competes with preserving evidence, and some decisions belong to people outside engineering. Add a short branch to your plan:

• Preserve logs and snapshots before rebuilding or deleting anything, and restrict who can access them.
• Rotate exposed credentials and revoke sessions as soon as you know which are affected.
• Involve leadership early, and loop in legal counsel and your cyber insurer if you have one, since notification duties and policy conditions vary by jurisdiction and contract.
• Keep the discussion in a private channel, and avoid speculating about cause in customer-facing text.
• Separate the containment task from the investigation task, so nobody wipes a machine someone else still needs.

Legal notification obligations depend on where your customers are and what data was involved, so treat this as a question for your attorney, not something to decide mid-incident. If ransomware is the scenario you worry about, the ransomware response plan template goes deeper.

Agree on a cadence in advance. A common pattern is an internal update every 30 minutes for a major incident and a customer-facing update whenever status changes, even if the message is 'still investigating'. Silence reads worse than an unfinished answer.

Draft three message shapes ahead of time: initial acknowledgment, ongoing update, and resolution. Each should say who is affected, what they'll notice, and when the next update comes. Leave out root-cause guesses until the review. Keep the tone plain and skip apologies that sound scripted; a direct statement of impact and next step is more respected.

An incident isn't finished when the graph recovers. Within a few working days, hold a review that produces a written timeline, contributing factors, and follow-up tasks with an owner and date each. Keep the review about the system and process, not about who pressed the wrong button.

Then update the plan itself: did the roles work, was severity clear, did the contact list have stale numbers? Schedule a tabletop exercise every six months or so, where the team walks through a made-up scenario using only the plan. Paging and incident tooling can help with the mechanics, and options like incident.io or PagerDuty are worth a look once the process itself is clear.