Incident response plan template (SOC 2), free and sized for five people
Two or three pages you can follow at 2am beat twenty you cannot. Here is the short version, ready to copy.
You can copy this whole plan for free. It is an incident response plan template SOC 2 examiners can test against a team of five, and it has four working parts: how serious is it, who does what, when you must tell people, and what you write down after. A fifth part, a yearly drill, gives you proof when nothing went wrong.
Two or three pages is the finished size. Download it as Word or PDF, fill in the names and numbers, then delete anything you would not actually do.
Why the short plan is the safe plan
Incident response lives inside the Security common criteria, which every SOC 2 report covers.1 The examination does not score your plan for ambition. It checks two things: that incidents in the period were handled the way your plan says, and that the plan was exercised.2
That flips the usual instinct. Each extra promise is one more thing to fail. A plan that pages someone within fifteen minutes turns every slow night into an exception printed in your report. Write the version you will follow when tired.
Part A: how serious is it
Base each level on something a person can see, not on a feeling. Customer data touched, production down, an outside party involved. Each level gets a trigger, a person to wake, and a clock. Test it by asking whether one engineer, alone at night, could pick the right level in one read.
| Level | You see | Who gets called | Deadline |
|---|---|---|---|
| SEV1 | Customer data reached by someone who should not have it, or production down for all | Incident lead, by phone, now | Contained same day, notice clock starts at declaration |
| SEV2 | A control failed and could have exposed data, or production degraded for some | Incident lead, within the hour | Contained same day, reviewed within five days |
| SEV3 | One account, device or dependency affected, and no data was reached | Ticket, next business day | Closed inside your stated remediation window |
| Not an incident | Scanner finding with no sign of use, failed login, phishing mail nobody clicked | Nobody | Vulnerability queue |
Part B: who does what when there are five of you
Big company plans list a commander, a scribe, a comms lead, a legal contact and a technical lead. You do not have five spare people at 2am. Merge the roles and say so in writing. One name in two roles is honest. A role with no name is a finding.
| Role | Owns | Small team version |
|---|---|---|
| Incident lead | Declares the tier, runs the response, calls the end | One name, one backup. Both can be engineers |
| Technical response | Containment, evidence capture, the fix | The incident lead below SEV1. State that in the plan |
| Customer communication | Status page, customer notices, the contract clock | One line: held by the CEO, backup the CTO |
| Record keeper | Timeline, decisions, timestamps | Whoever is not fixing. With two awake, the lead writes it afterwards |
A single line in the plan covers it: below SEV1 the incident lead and the technical responder are one person, and every role has a backup. The other controls that bend at this size are in SOC 2 for a small team.
Part C: when you must tell people
The criteria require that affected parties hear about security incidents. They do not set a number of hours, and your auditor will not pick one for you.1 The real deadline is already on paper somewhere. Find it in three places and keep the shortest.
- Your contracts. The security incident clause of each master agreement or data processing addendum. Deadlines vary by customer, so list the tightest.
- The law. Under Article 33 of the GDPR, a personal data breach goes to the supervisory authority within 72 hours. U.S. state breach laws carry their own timing. Ask a lawyer once and record the answer.
- Your own public words. Anything on your status page or trust page is a promise an examiner can read and test.
Write one number into the plan and name the person who sends the notice. A deadline with no owner will be missed.
Part D: the write up afterwards
Every incident gets a short review, held within a week while memories are fresh. Its job is the fix. Its record needs five fields so it survives being sampled:
- When it was detected, and whether by alert, customer or a person noticing.
- The level, and any change to it during the response.
- Timestamps for detected, declared, contained, resolved and communicated.
- Who was told outside the company, and when.
- The cause, plus one follow up with an owner and a due date.
Then close that follow up. Examiners sample incidents and check whether the actions closed, and it shows up among the requests on a SOC 2 evidence list.
Part E: the yearly drill
If nothing ever went wrong, you still need proof the plan works. A one hour tabletop, once a year, is how a quiet company produces it. Invite the people the plan names and run a scenario your stack could really face, like a cloud key pushed to a public repository or a laptop left in a taxi. Say the level out loud, draft the customer notice, look up the contract deadline. Then record the date, attendees, scenario, what went wrong and the follow ups. Hold it inside your examination period, or it does not count for that period.
Cut these before you adopt it
Read every line and ask whether you could show proof of it next week. If the answer is no, delete it. Typical cuts from a borrowed plan:
- A war room or bridge line you do not have.
- Roles with no person behind them.
- Response times you have never met.
- A forensics firm you have not hired.
- Anything that begins “the security team will”.
What remains is the whole document for a team your size. Your policy set and your scope get smaller by the same logic.
Two plans sit next to this one. The business continuity and disaster recovery plan takes over when an incident becomes an outage, and the logging and monitoring policy sets the alerts that open an incident in the first place.
What it costs to get this written
Doing it yourself from this page costs an afternoon. Paying someone else to write it is usually part of a larger consulting job, and those are priced for bigger companies:
- Comp AI states that a vCISO or compliance consultant might charge $150 to $400 an hour, which can total $20,000 to $50,000 for a full SOC 2 prep engagement. Source, checked 2026-07-30.
There is a middle path. cybersoftware writes the incident response policy as one of thirteen documents drafted from your own stack, with your names in it, and tracks the reviews and drills that prove you follow it. Onboarding is $2,000 one time. Or pick $4,000 one time instead, which adds the SOC 2 Type 1 examination and report. Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. It starts once the 3-month observation window completes.
cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Begin with the free readiness assessment, which takes about 15 minutes, or see every price on pricing.
Questions
What must a SOC 2 incident response plan cover?
Can a five person company run an incident response plan?
What is the deadline for telling customers about a breach?
Is a tabletop exercise required if we never had an incident?
Is it fine to start from a generic plan?
Sources
Get audit-ready without a compliance team
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Start with a free readiness assessmentcybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.