SOC 2 incident response plan requirements

The plan is judged on two things an auditor can check: that severity, roles and timelines are written down before anything happens, and that you can produce a log of the incidents you had.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A SOC 2 incident response plan needs six components: a definition of what counts as a security incident, severity levels with a response time attached to each, named roles including who declares an incident and who talks to customers, an escalation and notification path with time limits, a requirement to log every incident, and a post-incident review. Add one more for Canadian companies: the PIPEDA breach assessment step, because the moment personal information is involved you are on a legal clock as well as a contractual one.

Auditors test this plan in three ways. They read it, they ask for the incident log covering the whole window, and they ask for evidence that you exercised it at least once. The second is where first-time companies fail, because the log was started in month seven.

What severity levels should we write down?

Four levels is the right number for a company under a hundred people. Three collapses too much together and five produces arguments at 2am about whether something is a three or a four. Attach a response time to each, and make the lowest one genuinely relaxed so that the top one stays meaningful.

Note the response targets are acknowledgement times, not resolution times. A plan that promises resolution inside four hours has promised something no engineering team can guarantee, and it is one of the clauses worth cutting from any template pack before approval.

The first 72 hours of a confirmed data breach

When personal information is involved, the incident timeline and the privacy timeline run together. This is the sequence to write into the plan.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

How does PIPEDA breach reporting fit into the plan?

PIPEDA does not set a numbered deadline the way some laws do. It requires that a breach of security safeguards involving personal information be reported to the Office of the Privacy Commissioner of Canada as soon as feasible after you determine it has occurred, if the breach creates a real risk of significant harm to an individual, and that affected individuals be notified as well. Separately, you must keep a record of every breach of security safeguards for 24 months, whether or not it was reportable.

Real risk of significant harm

Assessed on the sensitivity of the information and the probability of misuse. Significant harm includes humiliation, damage to reputation or relationships, loss of employment or business opportunity, financial loss and identity theft. Write the assessment criteria into the plan so the judgement is not made from scratch under pressure.

Record of every breach

The 24 month record obligation applies to all breaches, including ones you assessed as not reportable. Your incident log satisfies both this and the SOC 2 request, which is why the log should carry a field for the privacy assessment outcome.

Quebec personal information

If you hold personal information about people in Quebec, Law 25 adds its own confidentiality incident duties: notify the Commission d'acces a l'information and affected individuals where there is a risk of serious injury, and keep a register of confidentiality incidents. Law 25 also expects a designated person in charge of the protection of personal information, so name that person in the plan rather than leaving the role implied. The Law 25 guide covers the wider obligations and the PIPEDA guide covers the federal side.

None of this replaces your contractual notification duties. Enterprise customer agreements routinely require notice within 24 or 48 hours of discovery, which is faster than any statute, so the plan should list both clocks.

The sequence the plan should describe

1. Anyone can declare an incident. Say this explicitly and give the channel.
2. The on-call engineer acknowledges and assigns a severity within the target for that level.
3. An incident commander is named for anything at Sev 2 or above, and it is not the person doing the technical work.
4. Containment first, root cause afterwards. Preserve logs before changing anything, because you will need them for the assessment.
5. Assess whether personal information was involved, and if so run the real risk of significant harm test and start the notification clocks.
6. Record the incident in the log with detection time, severity, systems affected, actions taken and closure time.
7. Hold a post-incident review for Sev 1 and Sev 2, with the actions tracked somewhere an auditor can see them closing.

What gets an incident response plan turned into a finding?

An empty incident log. Auditors do not believe that a company had zero incidents in twelve months, and they are right: a phishing attempt, a locked-out account investigated as suspicious, a dependency vulnerability triaged under pressure all belong in the log. An empty log reads as a control that never operated. Log the small ones, including the Sev 4 near misses, from day one of the window.

No exercise evidence. The plan needs at least one tabletop inside the window, with a date, attendee list, the scenario used and what you decided to change afterwards. Ninety minutes and a page of notes satisfies it.

Notification promises you cannot meet. Templates written for US companies name state attorney general timelines and a flat 72 hour customer notification. If your contracts say 24 hours, the plan now contradicts your contracts. Reconcile the two before approval and write the strictest of them.

Named roles nobody holds. A plan naming a security operations centre, a forensics retainer or a communications lead invites an auditor to ask who those are. Delete what you do not have, and if you genuinely intend to call an external responder, name the firm and keep the contact details current. The policy templates page covers the same editing discipline across the whole set, and the policy checklist will confirm whether you need a separate breach notification procedure alongside this plan given the data you hold. The checklist lists the artifacts each of these steps has to produce.

Common questions