SOC 2 CC7.1 requires that "the entity responds to identified vulnerabilities to meet the entity's objectives." In plain language: you need to find vulnerabilities, fix them in a reasonable timeframe, and prove that you did both. The third requirement — proof — is where most security teams struggle. Showing that you have a vulnerability scanner isn't the same as showing that you remediated findings. Showing that you ran patches last Tuesday isn't the same as showing that the specific vulnerabilities in scope were closed within your stated SLA.
A SOC 2 Type II audit covers a period of 6-12 months. Auditors will sample specific vulnerabilities from that period and ask you to demonstrate, for each selected finding: when you detected it, what severity you assigned it, what your policy required for that severity, when you actually remediated it, and how you confirmed it was closed. If any of those answers require reconstructing history from informal Slack messages and individual engineer recall, your audit is going to be uncomfortable.
What CC7.1 Actually Asks For
The AICPA's Criteria for CC7.1 includes three specific points of focus relevant to vulnerability management: "Identifies and Evaluates Security Events," "Responds to Security Incidents," and "Communicates and Reviews Detected Security Events." The last point — communication and review — is often underweighted in vulnerability programs. It's not enough to fix the vulnerability; you need to document that the right people were notified, that the remediation was tracked, and that completion was confirmed by a second party.
In practice, evidence for CC7.1 vulnerability management typically comes in three forms: scanner output showing the finding and its open/closed status, ticket or change management records showing the remediation action and closure date, and network or host scan records showing the vulnerability is absent after remediation. The strongest evidence packages have all three, with timestamps that tell a clear chronological story.
The Minimum Evidence Set Per Vulnerability Finding
For each vulnerability sampled during audit, you should be able to produce:
Discovery evidence: A timestamped scanner report showing the CVE ID, affected asset, severity score, and detection date. This should come from your vulnerability scanner's native report export, not from a manually edited spreadsheet. Auditors check whether the scan dates are consistent with your stated scanning frequency policy. If your policy says "weekly scans on all production infrastructure" and the scan report shows the last scan was 47 days before disclosure, that's a finding.
Risk classification evidence: Documentation showing how you classified the severity of this specific finding and what SLA that triggered. If you use a tiered SLA policy — Critical: 72 hours, High: 7 days, Medium: 30 days — the evidence should show how you classified this CVE and which tier's SLA applied. This is where CVSS-based classification makes auditing simpler: you can point to a policy document that says "CVSS 9.0+ = Critical tier, 72-hour SLA" and then show the CVE's CVSS score. No judgment calls to defend.
Remediation action evidence: A ticket, change request, or patch action record showing when remediation work was initiated, who owned it, and what was done. JIRA, ServiceNow, and most change management tools export this natively. The timestamp on ticket creation should be close to (or before) the SLA deadline for the discovered vulnerability's severity tier.
Closure evidence: A follow-up scan report or authenticated scan result showing the CVE is no longer detected on the affected asset after the remediation date. This is the most commonly missing piece. Teams patch the system but don't document a re-scan confirming the patch applied correctly. Some auditors will accept a change log showing the patched package version was installed on a specific date; others require an actual scan showing the finding is closed. Know your auditor's expectations before the audit, not during it.
Structuring Your Evidence Around Audit Sampling Logic
SOC 2 auditors typically sample between 10 and 25 vulnerability findings from the audit period, weighted toward Critical and High severity findings discovered early in the period (giving the auditor maximum visibility into whether your SLA was met). They also look for the full lifecycle — findings that were open at the start of the period and closed during it, not just findings opened and closed in the final week before the audit period ended.
This means your evidence package needs to be consistent throughout the period, not assembled retroactively. Teams that build evidence documentation only in the month before their audit will have gaps for findings from months 1-8 of the audit period. The scan reports may exist in the scanner tool, but the classification rationale, ticket linkage, and closure scans may not be reconstructable for older findings.
PatchGuard stores a full audit trail per patch action: the CVE ID and scanner finding that triggered the action, the risk score and tier assignment, the timestamp when the action was created, who approved it (if approval was required by the policy), the deployment timestamp, and the post-patch scan results confirming closure. This data is retained for 24 months and exportable as a structured JSON report, organized by CVE ID, asset, or date range — matching the three common ways auditors frame their sample requests.
Handling SLA Exceptions
Not every vulnerability will be remediated within its defined SLA. Vendor patches take time to release. Dependencies create scheduling conflicts. Some vulnerabilities require extensive testing before deployment. Auditors know this, and a documented exception is not an automatic finding — but an undocumented SLA miss is. The evidence requirement for exceptions is: a written rationale for the delay, compensating controls implemented in the interim (e.g., WAF rule blocking the attack vector, network isolation of the affected asset), and a documented target remediation date with an owner responsible for hitting it.
Maintain a living exception register as part of your vulnerability management process, updated as new exceptions are created and closed as patches are deployed. The exception register is itself an audit document — auditors may request the full register for the period to verify that exception counts are reasonable and that exceptions don't systematically cluster around specific asset types or teams. A pattern like "all database server patches are consistently late by 30-60 days" is a finding even if each individual exception has documentation.
Aligning with NIST SP 800-40
NIST SP 800-40 Rev. 4 (Guide to Enterprise Patch Management Planning) is the federal standard for patch management programs. Many SOC 2 auditors reference it as a baseline for evaluating patch program maturity, even though SOC 2 doesn't formally require NIST alignment. The guide defines three patch management tiers based on an organization's risk tolerance: Tier 1 (emergency patching within 2 weeks for critical CVEs), Tier 2 (patch in 1 month), and Tier 3 (patch in 3 months for lower-risk findings).
Organizations whose patch SLA policies align with or exceed these tiers have a stronger answer to the auditor question "how did you determine your remediation timelines?" than organizations that chose their SLAs arbitrarily. Having a written rationale that references NIST 800-40 Tier 1 as the basis for your 72-hour critical CVE SLA is a substantive answer. "We picked 72 hours because it seemed reasonable" is not.
Building the Evidence Package in PatchGuard
When an audit is approaching, PatchGuard's compliance report generation covers the standard CC7.1 evidence set in a single export. The report can be scoped by date range (covering the audit period), filtered by severity tier, and organized by asset or finding. It includes scan dates, finding open/close timestamps, patch action records, approver identities, deployment logs, and post-patch verification results — everything needed for a complete per-finding evidence chain.
The practical recommendation is to generate a quarterly compliance report throughout the year, not just at audit time. Quarterly reviews let you catch documentation gaps while the period is still recent enough to fill — you can re-scan a system to produce closure evidence for a finding that was patched in the prior quarter but not verified with a follow-up scan. Discovering that gap at the start of a 6-month audit period is manageable. Discovering it the week before the audit is not.
One Final Point on Evidence Quality
The most effective evidence packages tell a story that a non-expert auditor can follow without explanation. Every timestamp is consistent. Every CVE has a ticket. Every ticket has a closure date. Every closure date is before the SLA deadline (or has an exception record). When an auditor can trace the full lifecycle of any sampled finding from scanner detection to verified closure in under five minutes, you've built the right evidence system. That's not the same as having the strongest security program — but it is the same as getting an unqualified opinion on CC7.1.