Document ID: SOC2-IRP-001 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: CISO / Security Operations
Purpose
This plan defines [Organisation Name]‘s process for detecting, responding to, and recovering from security incidents affecting production systems and customer data. It implements CC7.3 (respond to identified security events), CC7.4 (respond to security incidents), and CC7.5 (communicate and disclose) of the SOC 2 Common Criteria.
1. Incident Severity Classification
| Severity | Definition | Examples | Initial Response Target |
|---|---|---|---|
| P1 — Critical | Active breach or complete service outage; customer data confirmed or suspected compromised | Active ransomware, confirmed data exfiltration, prod database breach | Immediate — within 15 minutes |
| P2 — High | Significant security event with potential customer impact; partial outage | Unauthorised admin access, unconfirmed breach, >50% service degradation | Within 1 hour |
| P3 — Medium | Security event with limited scope; no confirmed customer impact | Failed intrusion attempt (contained), suspicious activity under investigation | Within 4 hours |
| P4 — Low | Minor security event; no customer impact | Policy violation by employee, spam/phishing (not clicked), failed login spike | Within 24 hours |
2. Incident Response Phases
Phase 1 — Identify
- Alerts received from SIEM, monitoring, IDS, or manual report
- Initial triage to classify severity and determine if this is a true security incident
- Assign Incident Commander (IC) — CISO for P1/P2, Security Lead for P3/P4
- Open incident ticket in [ticketing system]; assign unique incident ID
- Notify relevant stakeholders per escalation matrix
Phase 2 — Contain
- Isolate affected systems to prevent spread
- Revoke compromised credentials immediately
- Preserve evidence — take memory dump and disk image before remediation
- Do not delete logs; enable enhanced logging on adjacent systems
- Block attacker IP/domain at perimeter if applicable
Phase 3 — Eradicate
- Identify root cause (exploit, credential compromise, misconfiguration, insider)
- Remove malware, backdoors, or attacker persistence mechanisms
- Patch or reconfigure vulnerable components
- Verify no attacker persistence remains before proceeding
Phase 4 — Recover
- Restore systems from clean backups (verify backup integrity before restoration)
- Rebuild compromised systems from known-good images rather than patching in-place where possible
- Conduct post-restoration security scan before returning to production
- Monitor closely for 72 hours after restoration
Phase 5 — Communicate
- Internal: Notify Engineering, Legal, Customer Success, and Executive Team per severity
- Customer: Notify affected customers per contractual obligations (see Section 5)
- Regulatory: Notify regulators per applicable law (GDPR — 72 hours; state breach laws — varies)
Phase 6 — Post-Incident Review
- Conduct PIR within 5 business days of incident closure
- Document root cause, timeline, impact, and corrective actions
- Update controls, runbooks, or policies based on findings
- Present to CISO; P1 incidents reported to Board
3. Escalation Matrix
| Severity | Notify Immediately | Notify Within 1 Hour | Notify Within 24 Hours |
|---|---|---|---|
| P1 | IC, CISO, CEO, Legal, Engineering Lead | All staff affected; board chair | Customers (if impacted); regulators (if required) |
| P2 | IC, CISO, Engineering Lead | Customer Success | Management team |
| P3 | IC, Security Lead | CISO | N/A |
| P4 | Security analyst | N/A | Security Lead (daily digest) |
4. Evidence Preservation Checklist
Before any remediation:
- Capture full memory dump of affected system(s)
- Take disk image (read-only) of affected system(s)
- Export all relevant log files to write-once storage
- Document system state (running processes, network connections, open files)
- Preserve cloud infrastructure state (snapshots, CloudTrail/audit logs)
- Document chain of custody for all evidence
- Notify Legal before sharing evidence with third parties
5. Customer Notification Requirements
| Scenario | Notification Timing | Channel |
|---|---|---|
| Confirmed breach of customer data | Within 72 hours of confirmation | Email + in-app; direct call for enterprise customers |
| Suspected breach (under investigation) | Within 24 hours of escalation to P1 | Email with “Investigating” status |
| Service outage >4 hours | Within 1 hour of detection | Status page; email for enterprise |
| Vulnerability affecting customer data (patched) | Within 30 days, at next scheduled communication | Release notes or security advisory |
Notification content must be reviewed by Legal before sending.
6. Post-Incident Review Template
Incident ID: ____________ | Severity: _______ | Date: ____________
| Field | Details |
|---|---|
| Summary | Brief description of the incident |
| Detection Method | How was the incident detected? |
| Timeline | Key timestamps from detection to resolution |
| Root Cause | Technical and process root cause |
| Customer Impact | Number of customers affected; data types involved |
| Containment Actions | Steps taken to stop the incident |
| Eradication Actions | Steps taken to remove the threat |
| Recovery Actions | Steps taken to restore service |
| Total Duration | Detection to full resolution |
| Corrective Actions | Changes to prevent recurrence (with owners and due dates) |
| Lessons Learned | Process improvements identified |
7. Review
This plan is reviewed annually and tested via tabletop exercise at least once per year. P1/P2 incidents trigger an immediate review.
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | March 2026 | [Author] | Initial issue |