Get in touch
info@canadiancyber.ca
Rafia Rizwan
February 18, 2026
SOC 2 does not expect zero incidents it expects readiness. In this guide, we break down what a SOC 2 incident response plan must include, what auditors actually review, and how testing, documentation, and clear roles determine whether you pass with confidence or face costly findings. If you're preparing for SOC 2, this article shows how to turn your incident response process into real resilience not just a compliance checkbox.
Canadian Cyber • SOC 2 • Incident Response
SOC 2 doesn’t expect you to have zero incidents. It expects you to know what to do when one happens.
Here is what a real IR plan includes and why it might save your company.
Some organizations still believe SOC 2 requires perfection. They think an incident a phishing attempt, an outage, a near-miss will derail the audit.
So they hide incidents. Downplay them. Hope auditors do not ask.
SOC 2 auditors know incidents are inevitable. They do not expect a pristine environment.
They expect something more valuable: proof you know what to do when things go wrong.
The difference between a company that passes SOC 2 and one that fails is not the absence of incidents.
It is the presence of a plan.
Incident response falls under Common Criteria 7 (CC7): System Operations, which evaluates your ability to detect, respond to,
and recover from events that could impact customer data.
| SOC 2 Trust Service Criteria | Incident Response Connection |
|---|---|
| Security | Detection + response to unauthorized access |
| Availability | Recovery from disruptions and outages |
| Confidentiality | Breach containment and exposure reduction |
| Processing Integrity | Investigation + verification of correct processing |
| Privacy | Notification, handling, and documentation of personal info incidents |
Auditors do not just read your incident response policy. They look for evidence that the policy works.
| Audit Evidence | What It Proves |
|---|---|
| Documented policy | You have a defined process |
| Incident logs | You track what happens |
| Ticket history | You actually respond and resolve |
| Post-incident reviews | You learn and improve |
| Simulation records | You test before a real crisis |
| Notification records | You communicate appropriately when required |
A proper IR plan is not a 50-page document that lives in a drawer. It is a practiced, proven process that empowers people to act under pressure.
Your plan must define what qualifies as an incident. Not every alert is an incident. Not every user error is a breach.
When an incident occurs, clarity trumps chaos. Your plan must define roles and backups.
| Role | Responsibility |
|---|---|
| Incident Commander | Manages response end-to-end; assigns; escalates |
| Security Analyst | Investigates, contains, eradicates, validates |
| System Owners | Isolate, restore, and verify affected systems |
| Communications Lead | Internal/external messaging, templates, approvals |
| Legal / Compliance | Regulatory guidance, notification thresholds, insurer coordination |
You cannot respond to what you cannot see. Your plan must document how incidents are detected.
This is the heart of the plan. For each incident type and severity, define the steps that prevent decision paralysis.
| Phase | Actions |
|---|---|
| Detection | Log event, assess severity, assign owner |
| Containment | Isolate systems, block activity, preserve evidence |
| Eradication | Remove threat, patch root cause, rotate credentials |
| Recovery | Restore services, validate normal operation, monitor closely |
| Post-Incident | RCA, lessons learned, corrective actions, update plan |
Incidents require communication internally and externally. Define channels, approval flow, and who speaks.
Every incident becomes evidence. Your plan must require consistent documentation.
| Minimum Fields | Why Auditors Care |
|---|---|
| Time detected, who detected, severity | Shows detection capability and triage |
| Actions taken + timestamps | Shows response discipline |
| Evidence preserved | Supports investigation and defensibility |
| Comms records (internal/external) | Shows appropriate notification handling |
| Root cause + lessons learned | Shows continuous improvement |
A plan that sits on a shelf is not a plan. It is a fantasy. SOC 2 expects periodic testing.
| Test Type | Description |
|---|---|
| Tabletop exercises | Walk through scenarios with the team |
| Simulations | Practice under realistic conditions |
| Penetration testing | Find gaps before attackers do |
| Backup restore tests | Verify you can actually recover |
We’ll review your plan, testing cadence, and evidence trail and tell you what auditors will flag, plus the fastest fixes.
| Gap | Why It Matters |
|---|---|
| Inconsistent logging | Missing evidence = “plan not operating” |
| Unclear ownership | Delays and confusion during incidents |
| Outdated procedures | Plan does not match current tools and systems |
| No testing | Auditors want proof it works |
| No post-incident reviews | Repeat issues indicate no learning |
| Level | Description | Typical Audit Outcome |
|---|---|---|
| 1. Ad-hoc | No formal plan; hope for the best | Critical findings |
| 2. Defined | Plan exists but not tested | Major findings |
| 3. Practiced | Tabletops and simulations run regularly | Minor findings |
| 4. Measured | Metrics tracked and improved | Clean opinion |
| 5. Resilient | Continuous adaptation integrated with business | Competitive advantage |
Your incident response plan is not a document for auditors. It is a lifeline for your business.
SOC 2 does not require perfection. It requires readiness. And readiness is not a feeling—it is a practiced, proven capability.
We’ll review your IR plan, evidence trail, and testing cadence and tell you what SOC 2 auditors will flag (and how to fix it fast).
| Element | Status |
|---|---|
| Documented incident response policy | ☐ |
| Defined incident severity tiers | ☐ |
| Named roles with backups | ☐ |
| Detection tools configured | ☐ |
| Response procedures per incident type | ☐ |
| Communication protocols defined | ☐ |
| Documentation templates ready | ☐ |
| Tabletop exercises scheduled | ☐ |
| Backup restoration tested | ☐ |
| Post-incident review process established | ☐ |
