SOC 2 CC7.1: vulnerability monitoring, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC7.1, the usual records are these.

• Vulnerability scan reports
• Patch and remediation tickets with dates
• Configuration monitoring or drift alerts

What Polara asks about it

The free readiness assessment asks 5 questions that bear on CC7.1. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Internal vulnerability scans run monthly? If yes, show it: AWS Inspector findings report, Qualys scan summary, Tenable scan report, or vulnerability remediation tickets. If no, the fix: schedule monthly internal vulnerability scans and retain the scan summary.
• External vulnerability scans run at least quarterly? If yes, show it: external vulnerability scan report, penetration test summary, scanner results export, or remediation ticket list. If no, the fix: schedule quarterly external vulnerability scans and retain the scan summary.
• Penetration test performed annually? If yes, show it: penetration test report from a security vendor, an attestation letter with the scope and date, the executive summary with its findings, or the remediation tracker for those findings. If no, the fix: engage a penetration testing firm annually and retain the report and remediation tracking.
• Critical patches applied within 30 days? If yes, show it: patching policy, AWS Systems Manager patch compliance report, operating system patching dashboard, or change ticket record. If no, the fix: set a 30 day service level for critical patches and export the patch compliance report.
• Do you apply a documented hardening or configuration baseline to production systems? If yes, show it: center for Internet Security (CIS) Benchmark report for the production account, a hardening standard document, the infrastructure as code module that enforces the baseline, or a configuration compliance scan. If no, the fix: document a hardening baseline for production systems and export the configuration that shows it applied.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Operations Security Policy covers CC7.1.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Vulnerability management policy template
• Logging and monitoring policy template
• Asset inventory template
• Vulnerability tracker template

If you also run ISO 27001, the Annex A controls A.5.7, threat intelligence, A.8.8, vulnerability management, A.8.9, configuration management and A.8.29, security testing ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is vulnerability Scanning. The fix: deploy a scanner and configure it to scan production assets. The proof: screenshot or export showing scanner configured with target assets and schedule.

An auditor asks two things about it. Is there a documented process for vulnerability scanning? Is a scanning tool deployed and configured to scan production?

Is it in your scope?

Yes, always. CC7.1 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

System operations: the criteria around it

CC7.1 is one of 5 criteria in system operations, CC7.1 to CC7.5. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• CC7.1, this page
• CC7.2, anomaly monitoring
• CC7.3, incident triage
• CC7.4, incident response
• CC7.5, incident recovery

Before it: CC6.8, malware prevention. After it: CC7.2, anomaly monitoring. All the criteria are on the Trust Services Criteria page, grouped by category.