CC7 is the SOC 2 Security criteria group for system operations. Its five criteria, CC7.1 to CC7.5, ask you to detect vulnerabilities and misconfigurations, monitor for anomalies, evaluate events, respond to incidents and recover. Auditors test whether your own controls for these run as described, so pick controls you can actually operate.
What does CC7 cover, criterion by criterion?
The AICPA Trust Services Criteria define the five. Paraphrased:
- CC7.1 Detect configuration changes that introduce vulnerabilities, and detect exposure to newly discovered vulnerabilities.
- CC7.2 Monitor system components for anomalies that suggest malicious acts, disasters or errors, and analyse them to decide whether they are security events.
- CC7.3 Evaluate security events to decide whether they are incidents, and act to prevent or address failures.
- CC7.4 Respond to incidents using a defined program to understand, contain, remediate and communicate.
- CC7.5 Recover from incidents.
The criteria are the same whether you pursue a Type 1 or a Type 2 report. A Type 1 report describes whether controls are designed suitably at a point in time. A Type 2 report covers a period and adds an opinion on operating effectiveness, so your evidence must show the controls ran the whole time.
Which controls satisfy CC7.1?
The points of focus for CC7.1 mention defined configuration standards, monitoring for noncompliance with them, change detection such as file integrity monitoring, detecting unknown components, and vulnerability scans run periodically and after significant changes, with timely remediation.
Control ideas:
- A hardening baseline per system type, stored in code, with drift alerts.
- Dependency and container scanning on every merge, plus a scheduled rescan of what is already deployed, because new advisories arrive after release.
- An infrastructure scan on a fixed cadence and after major changes.
- A remediation policy with target times by severity, and tickets that show the clock.
Evidence: baseline repository, scan outputs by date, tickets with open and close dates, exceptions with an approver.
Which controls satisfy CC7.2?
The points of focus ask for detection tools and procedures, measures designed for scenarios such as use of compromised credentials or unauthorised outside access, filtering and analysis of anomalies, and monitoring that detection tools themselves work.
Control ideas:
- Centralised logs from identity provider, cloud control plane, production and CI.
- A small set of alerts you will actually answer: impossible travel, new admin grants, disabled logging, spikes in failed logins, public exposure of storage.
- A weekly alert review with a named reviewer.
- A check that log sources are still sending. Silent log loss is a classic audit finding.
Evidence: alert rules export, weekly review notes, a log source health report.
Which controls satisfy CC7.3 and CC7.4?
Treat these together. CC7.3 is the triage decision, CC7.4 is what you do after deciding.
Control ideas:
- A written definition of "security event" versus "incident", with severity levels.
- An incident ticket template with fields for timeline, scope, containment, root cause, customer communication and follow ups.
- Named roles: incident lead, communications, scribe.
- A rule for when customer or regulator notification is considered, with legal input.
- Post incident reviews that produce tracked actions.
Evidence: the policy, closed incident tickets (or, if you had none, tabletop records), review notes with action items. If you had no real incidents during the period, say so and show exercises instead of inventing events.
Which controls satisfy CC7.5?
Points of focus include restoring the affected environment, communicating about the incident, determining root cause, changes to prevent recurrence, improving procedures and testing the recovery plan.
Control ideas:
- Backup and restore tests on a schedule, with measured restore times.
- A recovery runbook per critical service, including who decides to fail over.
- A lessons learned step that feeds back into CC7.1 and CC7.2 controls.
Evidence: restore test records, runbooks with review dates, recovery exercise notes.
What mistakes do teams make with CC7?
- Alerts nobody reads. Auditors often sample alerts and ask what happened next.
- Scanning once. The criterion mentions newly discovered vulnerabilities, which means rescanning, not just scanning at build time.
- A policy with no cadence. "We review logs" without a date trail is an untestable statement.
- Tabletops with no output. Capture decisions and actions or the exercise leaves no evidence.
- Scope drift. New systems missing from monitoring because nobody updated the inventory.
What to do
- List the systems in scope and confirm each feeds logs and scanning.
- Write the event versus incident definition and severity table.
- Pick the alerts and the weekly reviewer, then run the first review this week.
- Set remediation targets by severity and measure against them monthly.
- Run a tabletop and a restore test, and file the records.
- Map each control to CC7.1 to CC7.5 in a one page matrix so the auditor sees coverage.
- Keep a dated evidence folder per quarter.
Quick check
Does CC7 apply to every SOC 2 report?
CC7 is part of the Common Criteria, which form the Security category. Security is required in every SOC 2 report, so CC7 is in scope. You may add Availability, Confidentiality, Processing Integrity or Privacy on top.
What if we had no security incidents during the period?
Say so. Auditors can still test that the response program exists and is ready, so show the policy, roles, tabletop exercises and restore tests. Do not manufacture incidents.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. For CC7 that means evidence is collected from connected systems and code instead of by screenshot, and monitoring keeps running between audits. The technical evidence comes from your real code and dependencies: scans, SBOMs and reachability show which vulnerabilities are present and which are actually exploitable in your code. For remediation, Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare and keep evidence ready. The report itself comes from an independent auditor. Book a call.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022), criteria CC7.1 to CC7.5. Paraphrased, copyright AICPA.
- The AICPA text describes Type 1 and Type 2 engagements in its introduction.
Last reviewed: 18 October 2026.
