How-To10 June 2026 7 min read

How to Handle a Security Incident: SOC 2 CC7.3 Guide

When a security incident occurs, CC7.3 requires a defined response. Step-by-step guide: detection, containment, communication, and post-incident review.

Key Takeaways

CC7.3 requires you to evaluate detected events and determine if they constitute security incidents.
Assign an Incident Commander within 15 minutes of declaring a P1 incident.
Maintain a live incident log throughout the response — it is both operationally useful and your primary SOC 2 evidence.
Customer notification decision: within 72 hours of determining a breach occurred.
Post-incident review within 5 business days is required to close the incident formally for SOC 2 purposes.

In this guide

Detection and Triage
Incident Declaration
Containment Steps
Internal and External Communication
Evidence Preservation
Recovery and Verification
Post-Incident Review

Detection and Triage

Security incidents most commonly begin as alerts from GuardDuty, Security Hub, CloudWatch alarms, or employee reports. When an alert fires: acknowledge the alert within 15 minutes (P1) or 1 hour (P2). Assign an initial responder who will conduct triage.

Triage questions: is this a known false positive? Is there evidence of actual compromise (data exfiltration traffic, unusual API calls, suspicious login patterns)? What is the potential impact (which systems, which data)? Based on the answers, classify severity and determine whether to declare a formal incident.

Incident Declaration

When you declare a formal incident: open an incident ticket in your ticketing system, assign an Incident Commander (IC), notify your incident response Slack channel, and begin the incident log.

The Incident Commander owns the response. They do not necessarily perform every technical action — they coordinate, communicate, and make decisions about escalation, containment, and communication.

Notify executive stakeholders for P1 incidents immediately. For P2, notify at the 1-hour mark if not resolved.

Containment Steps

Containment priorities: prevent further damage before full investigation. For suspected account compromise: immediately suspend the compromised IAM user or Okta account, rotate all credentials the user had access to, and revoke active sessions.

For network-based incidents: isolate affected EC2 instances by modifying their security groups to deny all inbound and outbound traffic, or use AWS Systems Manager Session Manager for forensic investigation without network re-exposure.

Document every containment action in the incident log with: timestamp, actor, action taken, and outcome. This log is your CC7.3 and CC7.4 evidence.

Internal and External Communication

Internal communication: use a dedicated incident Slack channel. Update every 30 minutes during active P1 incidents. Be factual and avoid speculation about cause or impact until you have evidence.

Customer communication: decide at the 72-hour mark from incident detection whether customer notification is required. If personal data was potentially accessed or exfiltrated, notification is typically required. Draft the notification from a prepared template — do not draft from scratch under pressure.

Regulatory notification: DPDP Act requires notification to the Data Protection Board as soon as possible when a personal data breach occurs. GDPR requires notification within 72 hours. Build these into your decision checklist.

Evidence Preservation

Before taking containment actions that might destroy forensic evidence: take an EBS snapshot of affected instances, export relevant CloudTrail logs, capture GuardDuty findings, and document the current network traffic patterns.

Do not delete logs, modify files, or restore systems from backup before capturing forensic state. Create an S3 bucket with Object Lock enabled for incident forensic evidence.

Recovery and Verification

Once the threat is contained and eradicated: restore affected systems from known-good backups (verify backup integrity before restoring), re-enable access for affected users after credential rotation, and verify system integrity.

Run a full Security Hub scan and GuardDuty review after recovery to confirm no new findings. Document that security tools confirm clean state.

Formally close the incident: update the incident ticket with root cause, impact summary, and recovery confirmation.

Post-Incident Review

Conduct a post-incident review within 5 business days of incident closure. Attendees: IC, technical responders, relevant engineering leads, and optionally executive stakeholders for P1 incidents.

Post-incident review agenda: timeline reconstruction, root cause analysis (5 Whys or similar), impact assessment, detection assessment (how long until detected?), and action items (specific tasks to prevent recurrence, with owners and due dates).

Write a post-incident report and store it in your compliance tool. This document is key CC7.3–CC7.5 evidence. Auditors will read post-incident reports to evaluate the quality of your incident response programme.

Frequently Asked Questions

Does a false positive alert need to be documented for SOC 2?

Not in the same depth as a real incident, but you should maintain a record that the alert was reviewed and determined to be a false positive. A simple ticket or log entry: alert source, alert content, responder, conclusion, and reasoning.

What if our first real incident happens during the SOC 2 observation period?

Handle it well. A single, well-handled incident with a complete incident log and post-incident review is evidence that your controls work. Auditors evaluate response quality, not incident absence.

How do we notify customers about a security incident?

Use a pre-prepared notification template that includes: what happened (facts only), what data was affected, what we have done to contain and remediate, and what customers should do. Send from a named executive email address.

Do all employees need to know the incident response process?

All employees need to know how to report a suspected security incident and that they should report suspicious activity without delay. Technical responders need to know the full IRP process.

What is the difference between an incident and a breach?

A security incident is any event that has or may have an adverse impact on security. A breach is specifically an incident that results in confirmed unauthorised access to protected data. Not all incidents are breaches.