Screenata
All answers

How do I write an incident response plan for SOC 2?

December 7, 20252 min readSOC 2 Policies and Documentation

What an Incident Response Plan Needs

Your SOC 2 incident response plan (IRP) maps to CC7.3-CC7.5 in Trust Services Criteria. Auditors check that you have a documented process for handling security incidents — and that your team follows it.

The Five Sections

SectionWhat to Include
1. DetectionHow incidents are identified (monitoring tools, customer reports, automated alerts)
2. ClassificationSeverity levels and criteria (P1 = data breach, P2 = service outage, P3 = minor issue)
3. ResponseWho gets notified, what actions they take, escalation path
4. CommunicationHow you notify affected customers, internal stakeholders, and regulators if required
5. Post-incident reviewRoot cause analysis process, timeline for review, lessons learned documentation

A Startup-Sized Example

Detection

"Security events are detected through Sentry error monitoring, AWS CloudWatch alarms, and PagerDuty alerting. Customers can report issues to security@company.com."

Classification

  • P1 (Critical): Confirmed data breach, unauthorized access to customer data
  • P2 (High): Service outage affecting customers, credential compromise
  • P3 (Medium): Failed authentication attempts, minor configuration issues

Response

"P1: CTO notified within 15 minutes via PagerDuty. Affected systems isolated. Investigation begins immediately. P2: On-call engineer responds within 1 hour. P3: Tracked in Linear, addressed within 5 business days."

Communication

"Affected customers notified within 72 hours for P1 incidents. Status page updated for P2+ incidents."

Post-Incident Review

"Post-mortem document created within 5 business days. Team reviews root cause, timeline, and preventive measures. Document stored in Notion."

Tips

  • Keep it realistic. If your team is five people, don't describe a Security Operations Center rotation.
  • Name your tools. PagerDuty, Sentry, Slack #incidents — auditors want specifics.
  • Test it. Run a tabletop exercise once before your audit so you can tell the auditor you've tested the plan.

Related Questions

SOC 2 Policies and Documentation

How do I write a change management policy for SOC 2?

A SOC 2 change management policy describes how code and infrastructure changes are proposed, reviewed, approved, and deployed. For most startups, this means documenting your GitHub PR workflow, branch protection rules, and deployment process. The policy maps to CC8.1 in Trust Services Criteria.

SOC 2 Policies and Documentation

How do I write a SOC 2 policy when I'm not a compliance expert?

You don't need to be a compliance expert to write SOC 2 policies. Start by documenting what your team actually does — how you deploy code, manage access, and handle incidents. Then map those descriptions to SOC 2 language. Alternatively, use an AI compliance tool that reads your systems and generates policies for you.

SOC 2 Policies and Documentation

How do I write an access control policy for SOC 2?

A SOC 2 access control policy defines who gets access to your systems, how access is granted and revoked, and how you review access periodically. It maps to CC6.1-CC6.8 in Trust Services Criteria. For startups, document your identity provider setup, role-based access model, and offboarding process.

Ready to Automate Your Compliance?

See what your compliance program looks like with your real systems.

Book a demo