Vulnerability management and penetration testing are the two controls under CC7 that require the most sustained operational effort. A one-time vulnerability scan conducted in the week before an audit satisfies nothing — a Type II audit tests whether your vulnerability management program operated continuously over 12 months. Getting these controls right requires building them as operational programs from day one of the observation period, not as audit preparation activities at the end.
Vulnerability Scanning Program
CC7.1 requires an ongoing vulnerability management program. At minimum, this means: automated vulnerability scanning of all in-scope systems at a defined frequency (typically weekly or bi-weekly), review of scan results by someone with authority to prioritize remediation, remediation of identified vulnerabilities within defined SLAs by severity, and documentation of the full cycle from scan to remediation.
| Program Element | Minimum Requirement | Better Practice |
|---|---|---|
| Scan frequency | Monthly automated scans | Weekly automated scans; continuous scanning for cloud environments |
| Scan coverage | All production systems in scope | Production + staging + critical corporate infrastructure |
| Vulnerability classification | CVSS severity ratings (Critical/High/Medium/Low) | CVSS + exploitability context + business impact (asset criticality weighting) |
| Remediation SLAs | Critical: 30 days; High: 90 days; Medium: 180 days | Critical: 24-48 hours; High: 7-14 days; Medium: 30 days; Low: 90 days |
| Risk acceptance | No formal process | Documented risk acceptance with approver, business justification, and review date for vulnerabilities that cannot be remediated within SLA |
| Evidence retention | Scan reports retained; remediation tickets linked | Scan reports in GRC platform; automatic remediation ticket creation; SLA compliance dashboard |
Patch Management
Patch management is a subset of vulnerability management that specifically covers operating system and application patches. SOC 2 auditors will test whether the organization applies security patches within reasonable timeframes, particularly for critical and high-severity patches. The evidence trail includes the patch inventory (what systems need to be patched, what is the current patch level), patch deployment records, and testing evidence for patches applied to production systems.
| IMPORTANT | Cloud-native organizations often assume that managed services (RDS, EKS, Lambda) mean they don’t need to manage patches. This is partially true — cloud providers manage the underlying infrastructure, but application dependencies (libraries, packages, container images) remain the organization’s responsibility. Software composition analysis (SCA) tools that scan application dependencies for known vulnerabilities are essential for demonstrating patch management in cloud-native environments. |
Penetration Testing
Annual penetration testing is expected as a separate evaluation under CC4 and directly supports CC7 vulnerability management. The penetration test is an independent assessment of whether existing security controls can withstand realistic attack techniques — providing assurance that goes beyond automated scanning.
For SOC 2 purposes, the penetration test must be conducted by a qualified external firm (not the internal security team), must cover the in-scope system boundary, must produce a formal report with identified findings and severity ratings, and must be followed by a remediation tracking process that demonstrates high and critical findings are addressed. The test report and remediation records are provided to auditors.
| BITLION INSIGHT | Penetration test reports are a powerful evidence artifact beyond their SOC 2 function. Enterprise clients who receive your SOC 2 report and request a penetration test summary — a common enterprise security requirement — can be provided with a sanitized executive summary showing test scope, critical findings, and remediation status. This accelerates enterprise due diligence beyond what the SOC 2 report alone provides. |
| Penetration Test Element | SOC 2 Requirement | What Auditors Review |
|---|---|---|
| Scope | Covers all in-scope systems and applications in the SOC 2 system boundary | Test scope in the report; comparison to SOC 2 system boundary; gaps in coverage noted |
| Methodology | Recognized methodology (e.g., PTES, OWASP, NIST SP 800-115) | Report references methodology; testing approach matches stated methodology |
| Findings | All identified findings documented with severity ratings | Finding count and severity distribution; comparison to prior year’s findings for trend analysis |
| Remediation | High and critical findings remediated within defined SLA | Remediation tickets linked to findings; retest evidence for critical findings; accepted risk documentation for low findings |
| Frequency | Annual (minimum) | Test date relative to audit period; no material gaps in annual testing cadence |