The incident response plan template SOC 2 auditors test

The plans we have read are written for companies with a security operations center: a war room, an on call rotation, a legal hold procedure. You have five people and a Slack channel. Adopt one and you have promised a process you cannot perform.

What the examination is actually testing

Incident response sits inside the Security common criteria, so it is in scope on every SOC 2 report.¹ Three criteria carry it. CC7.3 is triage: deciding whether an event is a security incident. CC7.4 is the response: contain it, fix it, tell the people who need to know. CC7.5 is recovery: restore what broke and close the actions the review found. Every Polara GRC assessment includes it, whatever other categories you add. The test is not whether your plan is thorough. It is whether the incidents in the period were handled the way the plan says, and whether the plan was exercised.² A short plan you follow holds up. A long plan you ignore does not.

Severity, defined so it works at 2am

A definition earns its place if one engineer, alone and half awake, can apply it in a single read. Tie each tier to something observable: customer data, production availability, and whether anyone outside is involved. The word critical is not a definition. Give each tier a trigger and a clock.

Roles when there are five of you

The usual role list is incident commander, communications lead, scribe, legal liaison and technical lead. Five roles, five people, two of them asleep. Collapse them, and say so in the plan. Naming one person twice is honest. Naming a role nobody holds is the finding.

One sentence does the work: at our size the incident lead and the technical responder are the same person below a SEV1, and every role names a backup. The rest of what bends at this headcount is in SOC 2 for a small team.

The notification clock, and where it comes from

This is the section templates get wrong. The Trust Services Criteria ask that you communicate security incidents to the parties affected by them, which is a duty rather than a deadline.¹ They do not name a number of hours, and no auditor will supply one for you. Your deadline comes from somewhere else, and you already signed it.

Your customer contracts

The security incident clause of the master services agreement or the data processing addendum, in hours or business days. Usually the shortest clock you are under, and it differs per customer.

Statute, where personal data is involved

Article 33 of the GDPR sets 72 hours to notify a supervisory authority of a personal data breach. U.S. state breach laws set their own timing. Ask counsel once, write it down.

What you published yourself

A status page promise or a trust page line is a commitment. An examiner can read it, so it is testable.

Write the shortest of the three into the plan as one number, and name the person who sends the notice. A clock nobody owns is not a clock.

The post incident review

Every incident gets one, and it should be short. The fix is what it is for. What makes it survive a sample test is a record carrying five fields.

1. Detection time, and how it was detected. Alert, customer report, or somebody noticing. The field most write ups drop.
2. Tier, and whether it changed. Raising a SEV3 to a SEV1 four hours in is the interesting part.
3. Timeline with timestamps. Detected, declared, contained, resolved, communicated. Five entries is enough.
4. Who was told, and when. Customers, any authority that applies, and the internal record.
5. Root cause and one owned action with a date. Five actions nobody does is worse than one that closes.

Hold it within a week, while people still remember the order things happened in. Then close the action item. An examination samples your incidents and reads whether those actions closed, which is one of the numbered evidence requests you will be sent.

The annual test that produces the evidence

You will be asked for evidence that the plan was exercised during the period. If nothing ever happened to you, a tabletop is the only evidence there is, so it is what an examiner will ask for. Book the hour once a year and invite the people the plan names.

1. Pick a scenario your stack can produce. An API key committed to a public repository. A laptop lost at an airport.
2. Run it live for an hour. Someone declares a tier out loud, someone drafts the customer notice, someone reads the contract for the clock.
3. Write down what broke. Nobody knew who holds the status page login. The findings are the point.
4. Keep the artifact. Date, attendees, scenario, findings, action items with owners. That satisfies the request.
5. Date it inside your period. An exercise held before the window opened does not cover it.

The incident response plan template, full text

This is the plan the Word and PDF files carry, with the severity table, the roles, the notification clock, the review and the annual exercise from the sections above. National Institute of Standards and Technology (NIST) Special Publication 800-61 Revision 3 is the federal guide to how incident response fits into cybersecurity risk management, and it is worth reading if you want the longer version.³

What to cut before you publish it

Read the plan back with one question in mind. Could somebody test me on this line next Tuesday? Cut whatever you would have to make up on the spot. Then cut it again.

• The war room and the bridge line, unless you have one.
• Any role you cannot put a name against.
• Response times you have never hit.
• The forensics vendor you have not retained.
• Any sentence starting with the security team.

What is left is two or three pages. At five people that is the finished document, not a draft of a longer one you owe somebody later. The policy set and what you put in scope shrink on 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.