Auditors do not fail a SOC 2 report because a company has vulnerabilities. They fail it because the control description does not match what the evidence shows, or because the compliance mapping assigned the vulnerability management program to the wrong criterion. CC7.1 is the criterion most teams reach for first, and it is also the one most often mapped loosely enough that the auditor has to ask follow-up questions during fieldwork. This article walks through what CC7.1 actually covers, how it interlocks with the criteria around it, and how to write control language and evidence packages that survive a sampling walkthrough.
What CC7.1 Actually Requires
CC7.1 sits inside the System Operations series of the 2017 Trust Services Criteria. In substance, it asks an entity to run detection and monitoring procedures that catch two distinct things: configuration changes that introduce new vulnerabilities, and newly disclosed vulnerabilities that now apply to systems that were previously considered clean. Those are two different triggers with two different cadences, and a lot of control descriptions collapse them into one sentence that only covers the second case.
The first trigger is change-driven. A firewall rule gets loosened, a container image is rebuilt from a base layer with a new package version, an IAM policy is widened for a one-off migration and never narrowed back. None of those events show up in a CVE feed. They show up in a configuration diff or in a scan run against the changed asset shortly after deployment. If your scanning program only runs on a fixed calendar (say, every Sunday night) and has no trigger tied to change events, you have coverage for the second half of CC7.1 and a gap in the first half.
The second trigger is disclosure-driven. A CVE is published, a vendor advisory goes out, a zero-day gets weaponized in the wild. The control here is about how fast your asset inventory and scan engine catch up to that new information, not about your patch SLA (that lives partly under CC7.1 and partly under CC8.1, more on that below).
Related Criteria: CC7.2, CC7.4 and CC8.1
CC7.1 does not stand alone in a report. Auditors read it alongside three neighboring criteria, and control descriptions that ignore the boundaries between them tend to generate duplicate or contradictory evidence requests.
CC7.2 covers monitoring for security events and anomalies, meaning intrusion detection, log correlation, and behavioral alerting. Vulnerability scanning is not intrusion detection. A common drafting mistake is folding vulnerability scan output into the same control narrative as SIEM alerting, which forces the auditor to test two unrelated processes against one control statement. Keep them as separate controls even if the same platform team owns both.
CC7.4 covers incident response, specifically how the entity responds once a security event has been identified. A critical vulnerability that is actively being exploited against your environment crosses from CC7.1 territory into CC7.4 territory the moment you have evidence of exploitation rather than just exposure. Your control language should state explicitly where that handoff happens, for example: exploitation evidence or active attack against a flagged vulnerability triggers the incident response runbook rather than the standard remediation SLA.
CC8.1 covers change management: authorization, testing, and approval for changes to infrastructure and software. Patch deployment is a change. If your CC7.1 control description says vulnerabilities are remediated by applying patches, but your patch deployment process has no tie-in to the change management control tested under CC8.1, the auditor will ask why emergency patches bypass the approval workflow described elsewhere in the same report. Decide in advance whether critical-severity patches get an expedited change record or a documented emergency-change exception, and write that path into both control descriptions consistently.
Writing Control Descriptions for Scanning, Triage and Remediation
A control description that will hold up under testing needs to specify, in plain operational terms, four things: scope, cadence, criteria, and ownership. Vague verbs like “regularly” or “as needed” are the first thing an experienced auditor will flag, because they cannot be tested against a population.
For scanning, state the asset scope (all production hosts and containers registered in the CMDB, internet-facing assets identified through attack surface discovery, or both), the cadence (authenticated scans weekly, unauthenticated external scans daily, scan-on-deploy for new images pushed to the registry), and the tool or tools in use. If you run more than one scanner because different engines catch different vulnerability classes, name them; auditors increasingly expect to see how findings from multiple sources are deduplicated into one population rather than reported as separate, overlapping lists.
For triage, define the criteria that separates a confirmed finding from a false positive, and who or what performs that triage. If validation is automated, for instance an AI-assisted triage step that checks exploitability against the actual running configuration before a finding is assigned severity, say so and describe what evidence that step leaves behind (a validation record per finding, not just a final severity label). Auditors want to see the decision trail, not just the outcome.
For remediation, tie severity to a numeric SLA and state what happens when the SLA is missed. A workable starting point many programs converge on: critical findings remediated or formally risk-accepted within 15 days, high within 30, medium within 90, low tracked but not gated. Whatever numbers you pick, the control description and the ticketing system need to agree, because the auditor will pull the population of findings opened in the period and check closure dates against exactly those numbers.
Retesting deserves its own sentence in the control description. A patch marked “deployed” is not evidence of remediation; a rescan showing the specific finding is gone is. Platforms that automate this phase, such as SITEY, re-test the specific finding after a patch or configuration change rather than trusting the deployment tool’s exit code, and log the rescan result against the original finding ID. Whether that step is automated or manual in your environment, the control description should say what proof closes a ticket.
Populations and Samples the Auditor Pulls
For a Type II report, the auditor is testing operating effectiveness across the observation period, typically six to twelve months, which means they need a population to sample from at every step, not a single point-in-time screenshot.
- Scan population: every scan job that ran (or should have run) in the period, checked against the stated cadence. Missing runs, not just failed runs, are a gap.
- Finding population: every finding opened above your reporting threshold (commonly CVSS 7.0 or higher for the sample, though some auditors pull medium-severity findings too if the control language covers them), with open and close timestamps.
- Remediation sample: a judgmental or statistical sample of tickets from the finding population, walked from detection through closure, checking SLA adherence and retest evidence.
- Exception sample: every finding that missed its SLA, checked against whatever exception or risk-acceptance process the control description promises exists.
Two things trip up first-time SOC 2 companies here. First, the finding population needs to be pulled from the system of record, not reconstructed from memory after the fact; if your vulnerability lifecycle tracking lives in a spreadsheet that gets manually updated, expect the auditor to ask for the underlying scan exports to reconcile against it. Second, the sample the auditor draws is theirs to draw, not yours to curate. Populations that are missing entries, or that were filtered before being handed over, are themselves a finding.
Exception Handling Language That Does Not Create a Reportable Deviation
Every vulnerability management program misses an SLA occasionally. The mistake is writing a control description that has no room for that, which turns a normal operational event into a deviation from the stated control. The fix is not to weaken the SLA; it is to describe the exception path as part of the control itself.
Effective language names three things: who can approve an exception, what the exception requires (a compensating control, a documented business justification, a re-evaluated risk rating, or a fixed extension date), and how long an exception can stand before it is reviewed again. For example: findings that cannot be remediated within SLA due to vendor dependency or operational constraint may be risk-accepted by a named role for up to 90 days, with the compensating control and next review date recorded against the finding. That single sentence converts a missed SLA from “control failure” into “control operating as designed, with the exception path exercised and evidenced.”
What breaks this is silence. If the control description says findings are remediated within stated SLAs, full stop, then every late ticket in the sample is a deviation regardless of whether a compensating control was actually in place. Write the exception path before the first audit, not after the first exception shows up in a sample.
Frequent CC7.1 Exceptions Seen in First-Year Reports
A handful of gaps recur often enough in first-year Type II reports that they are worth checking against your own program before the auditor finds them.
Scan coverage does not match the asset inventory. New assets spun up between inventory syncs are missed entirely, and the population the auditor pulls from the CMDB does not match the population that was actually scanned. Reconcile asset inventory refresh frequency with scan scheduling, not just at kickoff but as a recurring check.
Authenticated scanning is inconsistent. Unauthenticated scans undercount findings badly on hardened hosts, and an auditor who understands scanning will ask whether credentials were valid for every scan in the sample, not just whether a scan ran.
Severity is taken from the scanner without adjustment. Base CVSS scores do not account for compensating controls like network segmentation or WAF rules already in place. If your triage process re-scores based on actual exploitability, document it; if it does not, expect the auditor to ask why a critical CVSS score sat open for 45 days against a stated 15-day SLA.
Closure evidence is a ticket status, not a rescan. This is the single most common finding auditors report in first-year vulnerability management testing: a ticket marked “resolved” with no artifact showing the vulnerability was actually gone. Retest and closure evidence, kept against the specific finding ID rather than the general patch record, closes this gap.
The exception path exists informally but is not written down. Teams often do risk-accept findings in practice, through a Slack thread or a verbal sign-off, without it appearing in the control description or leaving a record the auditor can sample. If exceptions happen, they need a named approver and a stored record, not just a shared understanding among the security team.
Population reconciliation is missing. The auditor cannot test a sample of ten tickets pulled from a population of forty when there is no way to show that forty is actually complete. Keep a single source of truth that ties scan results, deduplicated findings, and ticket status together so the population itself is defensible.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.