CC7.1 covers how an organization identifies and manages vulnerabilities that could affect its ability to meet its security commitments — and it's one of the criteria where auditors most consistently push back on evidence that looks complete but isn't actually demonstrating a functioning process.
What CC7.1 Actually Requires
The control language centers on the organization's process for identifying vulnerabilities in the systems supporting the service. In practice, auditors want to see: what's being scanned (and confirmation nothing in scope is missed), how findings get triaged and prioritized, remediation timelines tied to severity, and a record of what actually happened when a critical or high finding was identified — not just that a scanner ran.
Where Evidence Commonly Falls Short
Scan coverage gaps. A vulnerability scanning report showing clean results for the systems it covered means nothing if a production system was never in the scan's scope in the first place. Auditors increasingly ask for scan configuration evidence, not just scan output, to confirm coverage matches the actual production environment.
No remediation SLA tracking. Running SAST/DAST scans regularly is table stakes; what differentiates a mature program is evidence that findings above a defined severity get fixed within a committed timeframe, with a record of when each finding was opened and closed.
Exceptions with no documented rationale. Every vulnerability management program accumulates known findings that are accepted rather than fixed (a false positive, a mitigating control elsewhere, a vendor dependency awaiting a patch). Undocumented exceptions look like the process is being bypassed rather than managed.
Building the Evidence Pipeline
Scan coverage as evidence. Pull the actual scan target configuration from your scanning tool's API and reconcile it against your infrastructure inventory (all production accounts, all deployed services) to produce a coverage report showing exactly what's scanned and what isn't — closing gaps before the auditor finds them.
def reconcile_scan_coverage(scanner_targets: list[str], infra_inventory: list[str]) -> CoverageReport:
scanned = set(scanner_targets)
actual = set(infra_inventory)
return CoverageReport(
covered=list(scanned & actual),
gaps=list(actual - scanned),
coverage_pct=len(scanned & actual) / len(actual) * 100 if actual else 0,
)
Findings lifecycle tracking with SLA evidence. Rather than relying on a scanner's dashboard alone (which often doesn't retain full historical remediation timing in an audit-friendly export), pipe findings into a tracked issue system with severity-based SLA fields and closure timestamps:
def check_sla_compliance(finding: Finding) -> bool:
sla_hours = {"critical": 24, "high": 168, "medium": 720, "low": 2160}
if finding.status == "open":
elapsed = (datetime.utcnow() - finding.opened_at).total_seconds() / 3600
return elapsed <= sla_hours[finding.severity]
resolution_hours = (finding.closed_at - finding.opened_at).total_seconds() / 3600
return resolution_hours <= sla_hours[finding.severity]
Exception documentation as first-class evidence. Every accepted-risk finding should have a documented owner, rationale, and review date — treated as its own evidence artifact rather than a gap in the remediation report.
Connecting SAST/DAST to Runtime Evidence
Static and dynamic scanning cover the code and running application layer; a complete CC7.1 evidence story also typically includes infrastructure-level vulnerability scanning (container images, host-level CVEs) and dependency scanning for third-party libraries. Tools like Trivy cover container and dependency scanning; combining their output with application-layer SAST/DAST findings into one unified findings pipeline — rather than three disconnected reports — gives auditors (and your own team) a single coherent view of vulnerability posture.
Frequently Asked Questions
What SLA timelines do auditors typically expect for critical findings?
There's no universal mandated number in the SOC 2 framework itself — auditors evaluate whether your documented SLA is reasonable and, more importantly, whether you actually meet the SLA you set for yourself. A committed but consistently-missed 24-hour critical SLA looks worse than a documented, consistently-met 5-day SLA.
Do we need separate evidence for SAST, DAST, and dependency scanning, or can it be unified?
Unified is generally better — a single findings pipeline that ingests from all three sources with consistent severity, ownership, and SLA tracking gives auditors (and your own security team) a clearer picture than three separate, disconnected evidence sets covering overlapping but distinct parts of the same application.
How should we handle a finding that's a false positive?
Document it as an exception with a clear rationale explaining why it's a false positive, tag it in your findings tracker rather than simply dismissing it silently, and periodically re-verify false-positive determinations remain accurate as the underlying code or scanner rules change.
Does CC7.1 require penetration testing, or is scanning sufficient?
CC7.1 itself doesn't mandate a specific testing methodology — scanning-based vulnerability management is generally sufficient for the control, though some clients or contracts may separately require periodic penetration testing as an additional commitment beyond the SOC 2 baseline.
How do we handle vulnerability management evidence for third-party/vendor-managed infrastructure?
For infrastructure your vendor manages (a managed database service, for example), evidence typically shifts to demonstrating the vendor's own security posture (their SOC 2 report, security whitepapers) rather than running your own scans against systems you don't directly control.
Ask us what your GRC platform isn't covering → rutagon.com/contact or call 907-841-8407.