How to Create an Incident Response Plan for SOC 2

Why SOC 2 Requires an IRP

SOC 2 CC7.3 requires the organisation to evaluate and determine the significance of detected security events. CC7.4 requires that identified security incidents are responded to in accordance with a defined procedure. CC7.5 requires recovery from identified security events and communication to affected parties.

Without a documented and tested IRP, your SOC 2 audit will contain exceptions against CC7.3–CC7.5. These are among the most visible controls in an audit because they directly relate to how you protect customer data when things go wrong.

Required IRP Components

A SOC 2-compliant IRP must contain: scope and objectives, incident classification criteria, detection sources (monitoring tools, employee reports, customer reports, third-party notifications), response team structure and contact information, escalation thresholds, incident response phases (preparation, detection, containment, eradication, recovery, post-incident review), communication plan, and evidence preservation guidelines.

The document should be accessible to all responders during an incident — store it in a location that does not depend on the systems that might be compromised. A printed copy plus a cloud document accessible from personal devices are both good practices.

Severity Levels

Define severity levels to drive proportional responses. A typical three-tier structure: P1 (Critical) — active breach, confirmed data exfiltration, ransomware, or complete service unavailability affecting customers. Response time: immediate, all hands. P2 (High) — suspicious activity that may indicate compromise, significant service degradation, or potential data exposure. Response time: within 1 hour. P3 (Medium/Low) — anomalous activity requiring investigation, no confirmed impact. Response time: within business hours.

Each severity level should have a defined response lead, escalation path, and communication requirement. P1 incidents should automatically trigger customer notification evaluation and executive involvement.

Response Phases

Preparation: maintain the IRP, conduct tabletop exercises, ensure detection tools are operational, and maintain an up-to-date contact list. Evidence for auditors: the IRP document itself, last review date, and tabletop exercise records.

Detection and Analysis: when an alert fires or an incident is reported, triage to determine severity. Assign an Incident Commander. Begin maintaining an incident log (timeline of events, actions taken, decisions made).

Containment, Eradication, Recovery: isolate affected systems, remove the threat, restore services, and verify recovery. Each step should be documented in the incident log.

Post-Incident Review: within 5 business days of resolution, conduct a lessons-learned meeting. Document root cause, impact, timeline, and any process improvements. This document is key SOC 2 evidence.

Tabletop Exercise

A tabletop exercise is a structured discussion where your response team walks through a simulated incident scenario. It is required by SOC 2 to demonstrate that your IRP has been tested. Annual frequency is the minimum; twice yearly is better practice.

A good tabletop scenario for a SaaS company: "Your AWS GuardDuty alerts to an unusual API call pattern from an IAM user at 2 AM. A spike in data egress follows. Walk through your response." The exercise should cover: who is called, what systems are investigated, what containment actions are taken, and when customers would be notified.

Document the exercise: date, participants, scenario used, decisions made, and action items arising. This documentation is your evidence for CC7.4.

Customer and Regulatory Notification

Your IRP must address when and how customers are notified of security incidents. Most customer contracts and SOC 2 auditors expect notification within 72 hours of determining a breach has occurred. Build a notification template in advance — drafting communications mid-incident under pressure leads to errors.

DPDP Act: requires notification to the Data Protection Board of India and affected data principals as soon as possible — specific timeframes will be in Rules. GDPR: requires notification to supervisory authorities within 72 hours and to affected individuals without undue delay.

Even if you do not have EU or Indian customers yet, build these obligations into your IRP now. They are easier to add at design time than to retrofit after an incident.

IRP Template Outline

Section 1 — Purpose and Scope. Section 2 — Definitions (security incident, breach, severity levels). Section 3 — Roles and Responsibilities (Incident Commander, Security Lead, Communications Lead, Executive Sponsor). Section 4 — Detection Sources. Section 5 — Incident Classification and Severity Levels. Section 6 — Response Procedures by Phase. Section 7 — Communication Plan (internal escalation, customer notification, regulatory notification). Section 8 — Evidence Preservation. Section 9 — Post-Incident Review Process. Section 10 — Testing and Review Schedule. Appendix A — Contact List. Appendix B — Incident Log Template.