SOC 2 CC7: detection, incidents and recovery
CC7 is five criteria that add up to one question: would you notice, and would you know what to do.
CC7 has five criteria. CC7.1 covers detecting configuration changes and vulnerabilities, CC7.2 covers monitoring for anomalies, CC7.3 covers evaluating security events to decide whether they are incidents, CC7.4 covers responding to the ones that are, and CC7.5 covers recovering from them. The evidence that satisfies the family is a scan schedule with tracked remediation, alert rules that route to a person, an incident log that exists before you need it, and one exercise inside the observation window.
1 exercise The minimum CC7.4 evidence if you had no real incidents
That is the criterion most first-time teams get wrong. They read CC7.4, notice they had no incidents during the window, and submit nothing. An auditor cannot test a response process that never ran. A tabletop exercise with a date, an attendee list and written notes is the standard answer, and it takes ninety minutes.
What does CC7.1 and CC7.2 monitoring actually mean?
- CC7.1, detection of changes and vulnerabilities
- Two halves. Configuration drift: you can tell when infrastructure changed outside the pipeline. And vulnerabilities: you scan on a stated cadence and track findings to closure. Evidence is the scan reports plus the remediation tickets, not the scanner licence.
- CC7.2, monitoring for anomalies
- Alerting on defined security events, routed somewhere a human sees it. Failed authentication spikes, privilege escalation, changes to security groups, disabled logging. Evidence is the alert rules plus a sample of alerts that actually fired and what happened next.
The gap between these two is where small teams lose marks. CC7.1 is usually covered by an existing scanner. CC7.2 requires a defined list of what counts as a security event, which almost nobody has written down, and an auditor will ask for the list before they ask for the alerts. Write it: eight to twelve event types is plenty, and it belongs in the same document as your incident response plan.
How does a security event become an incident?
CC7.3 is the triage criterion, and it is satisfied by showing that events get evaluated rather than ignored. This is why the incident log has to include the things you decided were not incidents. A log with three entries, all of them genuine incidents, tells the auditor nothing about your triage. A log with twenty-two entries, nineteen of which are recorded as evaluated and closed as non-incidents, is CC7.3 evidence on its own.
| Criterion | Artifact | How it is tested |
|---|---|---|
| CC7.1 | Scan schedule, scan reports, remediation tickets | Sampled across the window against your stated cadence and SLA |
| CC7.2 | Defined security event list, alert rules, fired alerts | Configuration inspected once, alerts sampled |
| CC7.3 | Event and incident log including non-incidents | Whole log reviewed, entries sampled for evaluation evidence |
| CC7.4 | Incident records, or a tabletop with attendees and notes | Every real incident reviewed end to end; the exercise inspected |
| CC7.5 | Recovery record: what was restored, when, verified by whom | Sampled from incidents, or from the restore test if there were none |
The one thing you cannot fix later
Log retention. CC7 assumes you can look back across the observation window, and retention cannot be applied to logs that were already deleted. If your default retention is 30 days and your window is six months, you will reach fieldwork with five months of nothing. Extend retention before the window opens, budget for the storage, and check the retention on every source: application logs, cloud audit logs, identity provider logs and the alerting system's own history.
This is the single most common reason a window has to be restarted. It sits with the other irreversible items on the remediation plan page, and if your window is already running, running a window while you ship covers what can be salvaged.
PIPEDA turns incident logging into a legal obligation
If an incident involves personal information, PIPEDA requires you to report breaches that create a real risk of significant harm to the Privacy Commissioner and to affected individuals, and to keep a record of every breach for 24 months whether or not it met that threshold. That record obligation is broader than anything SOC 2 asks for, so build the log to the PIPEDA standard and CC7.3 comes free.
What satisfies CC7.5 if nothing broke?
Your restore test. CC7.5 is about recovering from incidents, and where there were none, auditors generally accept the documented restore test that business continuity requires anyway, plus the recovery section of the tabletop. Cite the same artifact against both criteria rather than manufacturing a second exercise.
0 of 7 done ·
Get detection and incident evidence ready
CC7 wants alerts that someone acted on, with a record. Tell us your scope and compare Canadian firms that will set it up and run the tabletop.
Get matchedCommon questions
What if we had no security incidents during the window?
Run a tabletop exercise and submit that. Auditors expect it, and a company with no incidents and no exercise gives them nothing to test against CC7.4. Record the date, who attended, the scenario, the decisions made and anything the exercise showed you needed to fix.
How long do logs need to be retained for SOC 2?
Long enough to cover the observation window plus the fieldwork that follows it, so a six month window generally means at least nine months of retention, and twelve is safer. SOC 2 does not name a number; your policy does, and the auditor tests you against your own number.
Does a managed detection service satisfy CC7.2?
It helps, and it does not remove the obligation. You still need to show what you asked the service to alert on, that the alerts reach someone at your company, and what happened when one fired. The provider's own report is a vendor artifact under CC9.2, not a substitute for your monitoring evidence.
How many criteria are in CC7?
Five: CC7.1 detection, CC7.2 monitoring for anomalies, CC7.3 evaluating events, CC7.4 responding to incidents and CC7.5 recovering from them.
Is a vulnerability scan the same as a penetration test for CC7.1?
No. CC7.1 is satisfied by recurring scanning with tracked remediation. A penetration test is a separate, deeper exercise that most auditors and most enterprise customers expect on top, and it also serves as a CC4 separate evaluation.