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.¹ Polara scopes Security only, and that is fixed rather than a customer setting. 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 passes. A long plan you ignore does not.

Section 1. 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.

Section 2. 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.

Section 3. 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.

Section 4. 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.

Section 5. 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, which is what makes it mandatory rather than good practice. 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.

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.