Starter template · roles, severities, steps, comms

Know exactly who does what when something goes wrong.

A starter incident response plan you can adapt this afternoon: clear roles, a severity scale, a six-step response process, and a communications plan. The worst time to figure out how to handle a breach is during one — this gives you the decisions already made.

4 sections, ready to adapt

Draft in an afternoon

For CTOs & security leads

Why you need a plan before you need it

The middle of a security incident is the worst possible time to decide who is in charge, what counts as serious, and who is allowed to tell customers. Panic makes those decisions badly. A written incident response plan moves the hard choices to a calm moment so that when an alert fires at 2 a.m., the team executes a rehearsed process instead of improvising under pressure. The plan itself is rarely the clever part — its value is that the decisions are already made and the roles are already assigned.

This is a starter plan: complete enough to use today, simple enough that your team will actually read it. It is also the kind of artifact a SOC 2 audit will ask you to produce. Adapt the roles to your org, set your own severity triggers, and rehearse it. If you are not sure what a penetration test does to reduce the odds you ever invoke this plan, that primer is a good next read.

1. Roles & responsibilities

Incident Commander — the single decision-maker who runs the response, declares severity, and is accountable for the outcome. Name a primary and a backup.
Technical Lead — directs investigation and containment, coordinates the engineers doing the hands-on work, and reports findings to the commander.
Communications Lead — owns all internal and external messaging, including customers, leadership, and where required, regulators and law enforcement.
Scribe — keeps the timeline: every action, decision, and discovery with timestamps, which is essential for the post-incident review and any legal process.
Legal and Compliance contact — advises on breach-notification obligations, contractual duties, and regulatory deadlines.
Executive sponsor — the leader who can authorize spending, approve external disclosure, and make business-risk calls quickly.

2. Severity levels

SEV-1 Critical — active breach, confirmed data exposure, or full outage of a core service. All hands, immediate executive involvement, response begins now.
SEV-2 High — significant degradation, a contained intrusion, or exposure of limited sensitive data. Rapid response during business hours with on-call escalation.
SEV-3 Moderate — a limited-impact issue or a suspected event under investigation. Handled by the on-call engineer, escalated only if it grows.
SEV-4 Low — minor issue, single-user impact, or a false alarm worth logging. Tracked and resolved through the normal queue.
Define the trigger for each level in advance, and let anyone declare an incident — it is cheaper to downgrade a false alarm than to discover a real one too late.

3. The six-step response process

1. Detect and report. Anyone who notices a potential incident reports it through one known channel. The on-call responder acknowledges and opens an incident record.
2. Triage and declare. Assess scope and impact, assign a severity, and appoint the Incident Commander. Start the timeline immediately.
3. Contain. Stop the bleeding: isolate affected systems, revoke compromised credentials, and block the attack path — while preserving evidence for investigation.
4. Eradicate and recover. Remove the root cause, patch the vulnerability, restore from clean backups, and verify the systems are healthy before returning to service.
5. Communicate. Execute the communications plan on the timeline you committed to: internal updates, customer notice, and any required regulatory or partner notification.
6. Review. Within a week, run a blameless post-incident review. Document the root cause, the timeline, and concrete actions to prevent a recurrence — then assign and track them.

4. Communications plan

Internal updates: a single status channel, a regular update cadence, and one person posting so the team is not distracted by status-chasing.
Customer notification: pre-written templates for confirmed-incident and resolved messages, plus the criteria and timeline that trigger sending them.
Regulatory and legal notification: know which regulators or partners must be told, the deadlines that apply, and who signs off before anything goes out.
Executive briefing: a concise format leadership can absorb fast — what happened, current impact, what is being done, and what they need to decide.
Public statement: a holding statement ready in advance, and a clear rule that only the Communications Lead or an authorized executive speaks publicly.
Contact list: an up-to-date roster with phone numbers, kept somewhere reachable even if your primary systems are down.

How to put it into practice

Start by naming real people for every role, with named backups, because a role with no owner is a gap. Set the severity triggers in plain language so anyone can declare an incident without second-guessing. Pre-write the communications templates — the confirmed-incident notice, the resolved notice, the executive briefing — while you are calm, because nobody writes well during a crisis. Keep the contact list somewhere reachable even if your primary systems are down.

Then test it. Run a tabletop exercise once or twice a year: pick a realistic scenario, follow the plan exactly as written, and fix every gap the exercise exposes. An untested plan reliably fails at the worst moment. To lower the odds of ever invoking it, pair the plan with proactive testing — a penetration test and a web application pentest surface the weaknesses an attacker would use before they become your SEV-1.

How this connects to our work

A response plan handles the moment after something goes wrong; our security work is about making that moment rare. Every engagement that touches sensitive data pairs proactive testing with a readiness review of exactly this kind of plan. We help teams turn a generic template into one that fits their architecture, their obligations, and their on-call reality, and we feed the findings from a penetration test straight back into the plan's containment steps.

If you are building the product as well as securing it, the same discipline runs through our SaaS platform development work, where logging, monitoring, and incident readiness are part of the build, not an afterthought. For preparation specifics around an audit, read the SOC 2 pentest prep guide, or get in touch to talk through your plan.

Frequently asked questions

Who needs an incident response plan?

Any company that stores customer data or runs a production system. You do not need to be large; you need to know who does what when something goes wrong. A short, rehearsed plan beats a long one nobody has read, and a SOC 2 audit will require one.

How is an incident response plan different from a disaster recovery plan?

Disaster recovery is about restoring service after an outage or data loss. Incident response is about handling a security event — a breach, intrusion, or data exposure — including containment, investigation, legal obligations, and communication. They overlap but answer different questions.

How often should we test the plan?

Run a tabletop exercise at least once or twice a year and after any major change to your team or architecture. Walk through a realistic scenario, follow the plan as written, and fix every gap the exercise reveals. An untested plan tends to fail at the worst possible moment.

What is the most common mistake in incident response?

Improvising communication. Teams contain the technical issue but mishandle who gets told, when, and what they are told — which is what turns an incident into a reputational and legal problem. Pre-writing the communications plan and naming a single decision-maker prevents most of that damage.

Related resources & reading

Web App Pentest Checklist

Find the weaknesses before they become a SEV-1.

Vendor Security Questionnaire Template

Ask vendors about their incident-response and breach-notification posture.

SOC 2 Pentest Prep Guide

Why an incident response plan is part of audit readiness.

Penetration Testing

Reduce the odds you ever have to invoke this plan.

Want fewer incidents to respond to?

A response plan is the safety net. Proactive testing is the first line. We can run a penetration test, help you adapt this plan to your environment, and rehearse it with your team. See how engagements are priced or book a call.