SOC 2 CC7 System Operations: Criteria and Evidence

CC7 is the part of a SOC 2 examination that asks whether security operations actually ran during the period, and it is where a well-written policy meets a monitoring queue nobody worked. The five CC7 criteria cover vulnerability and configuration detection, anomaly monitoring, evaluation of security events, incident response and recovery. This guide takes each criterion in turn: what it asks, the controls service organisations usually describe, the evidence an auditor samples in a Type 2 period and the exceptions that recur. It is for security operations leads, control owners and compliance managers preparing for a first or repeat SOC 2 report. The wider picture of report types and scoping is in the SOC 2 Guide, and access controls are covered in the SOC 2 CC6 Logical Access Guide.

A note on sources: the criteria come from the AICPA's 2017 Trust Services Criteria (With Revised Points of Focus, 2022), which the AICPA distributes as a download behind a free account. The summaries below are paraphrased by NHI Mgmt Group and were cross-checked against a published secondary copy of the CC7 criteria and points of focus, not the AICPA download itself. Confirm exact wording against the AICPA text before quoting it in a system description. Confirm against the official text before relying on it.

Key takeaways

CC7 has five criteria that follow the life of a security event: detect weaknesses (CC7.1), monitor for anomalies (CC7.2), evaluate events (CC7.3), respond (CC7.4) and recover (CC7.5).
Auditors test operation, not design: in a Type 2 period they sample alerts, scans, tickets and incidents and follow each one to closure, so an untriaged alert queue is direct evidence of an exception.
Defined thresholds are your commitment: whatever remediation window or triage time you write in the system description becomes the test, so write windows you meet every time.
"No incidents" still needs evidence: if nothing met your incident definition, the auditor will look at how events were evaluated and closed, and at the tabletop or recovery test that proves the plan works.
Identity events are security events: compromised credentials and misuse by authorised users are named anomaly sources, so monitoring must cover sign-ins, privileged activity and machine credentials, not only network and endpoint alerts.

The five criteria at a glance

The table paraphrases each criterion and the main themes in its points of focus. Points of focus are considerations for designing controls, not a checklist the auditor ticks: the service organisation decides which apply to its system.

Criterion	What it asks (paraphrased)	Main themes in the points of focus
CC7.1	Detection and monitoring procedures identify configuration changes that introduce vulnerabilities, and susceptibility to newly discovered vulnerabilities	Defined configuration standards; monitoring for drift; change detection such as file integrity monitoring; detecting unknown or unauthorised components; periodic vulnerability scans, also after significant change, with timely remediation
CC7.2	System components and their operation are monitored for anomalies indicating malicious acts, natural disasters and errors, and anomalies are analysed to decide whether they are security events	Detection policies, procedures and tools; detection measures for six anomaly sources (physical barriers, misuse by authorised users, compromised credentials, unauthorised external access, compromised third parties, unauthorised hardware or software); filtering and analysis; checking detection tools work
CC7.3	Security events are evaluated to decide whether they could cause, or have caused, a failure to meet objectives (security incidents), and action is taken	Incident response procedures; communicating detected events to those running the programme; evaluating incidents and impact; assessing impact on personal information and identifying what was used or disclosed
CC7.4	Identified incidents are handled through a defined incident response programme to understand, contain, remediate and communicate them	Roles and responsibilities, including external parties; containment strategy; ending threats and removing unauthorised access; restoring operations to an interim state; communication protocols; fixing vulnerabilities; evaluating response effectiveness and incident patterns; notifying affected parties; sanctions where personal information was misused
CC7.5	Activities to recover from identified incidents are identified, developed and implemented	Restoring the affected environment; communicating about the event; root cause; changes to prevent and detect recurrence; improving response and recovery procedures; testing the recovery plan with realistic scenarios

CC7 overlaps with neighbouring criteria. Change approval sits in CC8.1 (see the SOC 2 CC8 Change Management Guide), malicious software prevention in CC6.8, and recovery of infrastructure from disruption in the Availability criteria (A1). A single control can support more than one criterion, but the system description should say which.

How auditors test CC7

In a Type 1 report the auditor confirms that controls are designed and in place at a point in time. In a Type 2 report they test that the controls operated across the period, usually six to twelve months. For CC7 the methods are the familiar four: inquiry (interviews with the SOC lead), inspection (tickets, reports, configurations), observation (watching a triage or a scan run) and reperformance (repeating a step such as recalculating whether a critical vulnerability was fixed inside the stated window).

Population first: the auditor asks for the full list of items the control acts on: all scans run, all critical and high findings, all alerts above a severity, all incidents. Missing items in the population are an exception in themselves.
Sample and trace: a sample is drawn and each item followed from detection to closure, checking timestamps against your stated thresholds.
Completeness of monitoring: expect a request to show that in-scope systems actually send logs and are actually scanned. A reconciliation from the asset inventory to the SIEM and the scanner is the strongest answer.
Tool health: the auditor may ask how you know a log source stopped sending. A data-source health alert with tickets is better evidence than an assertion.

CC7.1: configuration and vulnerability detection

CC7.1 has two halves. The first is configuration: a defined baseline (for example CIS Benchmarks or an internal hardening standard), monitoring for drift against it and change detection that alerts on unauthorised changes. The second is vulnerability susceptibility: scanning on a schedule and after significant change, with findings remediated in a defined time.

Control described	Typical evidence in a Type 2 sample	Common exception
Authenticated vulnerability scans of in-scope hosts, containers and images, at least monthly and after major releases	Scan schedule, scan reports per month, scanner asset list reconciled to inventory	Hosts in the inventory never scanned; scans run unauthenticated so findings are incomplete
Remediation windows by severity (for example critical in 15 days, high in 30)	Ticket per finding with created and closed dates, or approved exception	Findings closed late with no exception record; window counted from triage instead of detection
Cloud configuration monitoring against a baseline	Posture tool reports, drift alerts and their tickets	Alerts suppressed in bulk with no rationale
File integrity or change detection on critical systems	Alert samples matched to approved changes	Alerts never reconciled to change records, so unauthorised changes would go unnoticed
Detection of unknown components	Discovery scan or agent coverage report with follow-up tickets	Unmanaged cloud accounts or subscriptions outside discovery
Penetration test, annually or after major change	Report, findings tracker, retest evidence	Findings with no retest before period end

Deeper guidance on prioritisation is in the Risk-Based Vulnerability Management Guide and the CIS Control 7 Continuous Vulnerability Management Guide, and change detection in the File Integrity Monitoring Guide.

CC7.2: monitoring for anomalies

CC7.2 asks for monitoring of system components and their operation, and for analysis that separates noise from security events. The six anomaly sources in the points of focus are a useful coverage test: for each, name the log source, the detection and the owner.

Anomaly source (paraphrased)	Example log sources	Example detections
Breach of physical barriers	Data centre provider reports, badge system logs	Out-of-hours access to restricted areas (often inherited from a subservice organisation)
Unauthorised actions by authorised users	Cloud control plane logs, database audit logs, admin consoles	Bulk export, privilege self-assignment, logging changes by an administrator
Use of compromised credentials	Identity provider sign-in logs, VPN, SaaS audit logs	Impossible travel, MFA fatigue patterns, sign-ins from new countries, token reuse
Unauthorised access from outside the boundary	WAF, load balancer, firewall and API gateway logs	Scanning, credential stuffing, exploitation attempts against internet-facing services
Compromise of authorised third parties	Vendor access logs, OAuth app activity, support tool logs	Third-party account active outside agreed windows, new OAuth grants with broad scopes
Unauthorised hardware or software	EDR, MDM, container registry and admission logs	Unapproved software installs, unsigned images, unknown devices on the network

Triage evidence: every alert above a stated severity should end in a ticket or case with a disposition (false positive, benign, event, incident) and a timestamp. Auditors sample these.
Tuning record: suppressions and rule changes need an owner and a reason. Silent suppression looks like a control gap.
Retention: logs must exist for the whole period to be sampled. State retention in the system description and make sure it is met. See the Log Management and Retention Guide.
Outsourced monitoring: if a managed detection provider runs the queue, it is usually a subservice organisation. You still own the evidence that you reviewed its escalations and its SOC 2 report.

Where identity fits: credentials and non-human accounts in CC7

Two of the six anomaly sources are identity problems, and the points of focus under CC7.4 include removing unauthorised access as part of ending a threat. In practice that means CC7 controls must reach sign-in and audit logs from the identity provider, cloud IAM and SaaS admin consoles, and must include service accounts, API keys, OAuth applications and AI agents, whose misuse rarely triggers an endpoint alert.

Detections to evidence: new credentials added to an application or service principal, use of a machine credential from an unexpected network, dormant service accounts suddenly active, and privileged role assignment outside change windows. See How to detect new credentials added to an app registration.
Containment runbook steps: credential rotation and token revocation for non-human identities should be written into incident procedures with owners, because they are the slowest step when nobody knows who owns a key.
Evidence: the Audit Readiness for AI Agents and NHIs guide sets out what to collect for machine identities.

CC7.3 and CC7.4: evaluating events and responding

CC7.3 is the decision point: is this event an incident? CC7.4 is what happens next. Auditors look for a written incident definition, severity levels, a decision record and a response that follows the plan.

Define the terms: event, security event and security incident, with severity criteria that include personal information impact, because CC7.3 points of focus ask you to assess it.
Record the decision: each escalated event needs a recorded evaluation and outcome, even when the outcome is "not an incident".
Run the plan: named roles (incident lead, communications, legal, technical leads), containment strategy by incident type, and escalation contacts for subservice organisations.
Communicate: internal updates, customer notifications under contract, and regulator notification where law requires it. Record who decided and when.
Close with remediation: vulnerabilities fixed, access removed, and a post-incident review feeding CC7.5.

The plan itself can follow NIST SP 800-61; Revision 3, final since April 2025, recasts incident response as a CSF 2.0 community profile. A starting document is the Incident Response Plan Template.

If there were no incidents in the period, the auditor cannot sample one. Expect them to test the event evaluation population instead, and to inspect an annual tabletop or simulation with actions tracked to closure. See Identity Attack Tabletop Exercise Scenarios.

CC7.5: recovery and lessons learned

CC7.5 asks for recovery activities after an incident: restoring the environment (rebuild, patch, reconfigure), communicating what happened, finding the root cause, changing controls to prevent and detect recurrence, improving the plan, and testing recovery with realistic scenarios.

Post-incident review: a dated review per incident with root cause, actions, owners and due dates. The Post-Incident Review and Root Cause Analysis Template fits this.
Action tracking: auditors check that actions were completed or carried forward with a reason. Open actions from last year's report are a recurring finding.
Recovery testing: restore tests and failover tests, with results and fixes. CC7.5 and Availability criterion A1.3 can share evidence. See the Backup and Recovery Testing Checklist.

Preparing CC7 for a first Type 2

Inventory and coverage (months before the period): reconcile the asset inventory to scanner targets and SIEM log sources. Fix gaps before the period starts, because gaps found during it become exceptions.
Write measurable control descriptions: state scan frequency, remediation windows, triage expectations and log retention you can meet every time. Avoid precision you cannot sustain.
Make evidence system-generated: tickets linked to alerts and findings, scan exports with dates, and case records. Screenshots taken the week before fieldwork do not show operation across the period.
Run a mock test: pull a population, draw a sample of ten and trace each to closure. Fix the process, not just the sample.
Exercise the plan: hold a tabletop early in the period and track actions to closure before it ends.
Log self-identified exceptions: late remediation or a missed review found by you, with root cause and fix, reads better than the same item found by the auditor.

Decision guidance: small and large organisations

Question	Small organisation (one platform team)	Large organisation (dedicated SOC)
Who runs monitoring?	Often a managed detection provider; you review escalations and its SOC 2 report	In-house SOC with documented runbooks and shift handover
How to evidence triage?	Alerts routed into the same ticketing tool as engineering work	SOAR or case management with disposition fields and SLA reports
Remediation windows	Fewer severities, longer but reliable windows	Risk-based windows with an exception process and KEV-driven fast track
Recovery testing	Annual restore test of the main data stores	Scenario-based tests per critical service, rotated through the year

Detection and measurement

Log source coverage: percentage of in-scope assets sending logs to the SIEM, from inventory reconciliation.
Scan coverage: percentage of in-scope assets scanned (authenticated) in each period.
Remediation within window: percentage of critical and high findings closed within the stated window, or covered by an approved exception.
Triage time: median time from high-severity alert to recorded disposition.
Silent source alerts: number of log sources that stopped sending, and time to restore.
Post-incident actions closed: percentage closed by due date.

Framework mapping

The mapping is indicative, prepared by NHI Mgmt Group to help reuse evidence; it is not an official crosswalk.

Criterion	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1 (control level)
CC7.1	ID.RA-01	RA-5, CM-6, CM-8	4 Secure Configuration; 7 Continuous Vulnerability Management
CC7.2	DE.CM-01, DE.CM-09, DE.AE-02	SI-4, AU-6	8 Audit Log Management; 13 Network Monitoring and Defense
CC7.3	DE.AE-02, RS.AN-03	IR-4, IR-5	17 Incident Response Management
CC7.4	RS.MA-01, RS.AN-03	IR-4, IR-6, IR-8	17 Incident Response Management
CC7.5	RC.RP-01	CP-10, IR-4	11 Data Recovery; 17 Incident Response Management

The SOC 2 to ISO 27001 Mapping Guide covers reuse with an ISO/IEC 27001 programme.

Common failure patterns

Alerts without dispositions: the SIEM fires, but nothing records what was decided, so the sample cannot be traced.
Scanner blind spots: new cloud accounts, container images or short-lived hosts never added to scanning, found when the auditor reconciles to the inventory.
Windows written too tight: a seven-day critical window in the description, met most of the time, produces a list of exceptions.
Identity logs left out: network and endpoint monitoring in place, but no detection on identity provider, cloud IAM or OAuth application events, so credential misuse goes unseen.
Tabletop with no follow-through: the exercise is held, actions are listed and none are closed by period end.
Relying on a provider without review: a managed detection service is used, but there is no evidence its escalations or its own report were reviewed.

Practitioner checklist

Map CC7.1 to CC7.5 to named controls, owners, tools and evidence sources.
Reconcile the asset inventory to scanner targets and SIEM sources before the period starts.
State scan frequency, remediation windows and log retention you can meet every time.
Link every alert above a set severity to a ticket with a disposition and timestamp.
Cover all six anomaly sources, including identity provider, cloud IAM and machine credential activity.
Write incident definitions and severity criteria that include personal information impact.
Run a tabletop and a restore test in the period and close their actions.
Run a mock population and sample test and log self-identified exceptions.

SOC 2 CC7 System Operations Guide: Monitoring, Incidents and Evidence