CC7.1 — Vulnerability and configuration monitoring

Detection and monitoring procedures are used to identify configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities.

Also written as CC 7.1, TSC CC7.1, SOC2 CC7.1, SOC 2 Type 2 CC7.1.

Written by Jett N. · Last reviewed 22 July 2026

What SOC 2 CC7.1 requires

Vulnerability and configuration monitoring is one of 5 criteria in the System Operations (CC7) series of the Security (Common Criteria) category. Detection and monitoring procedures are used to identify configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities. CC7 covers detection and response, so the evidence is operational: monitoring configuration, alert samples, incident tickets with timestamps, and proof that identified issues were actually closed out.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC7.1, gather artefacts such as:

Points of focus for CC7.1

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC7.1. They are not themselves requirements, but they shape the testing:

• Configuration standards are defined for system components.
• Changes that could introduce vulnerabilities are detected.
• The organisation monitors for newly discovered vulnerabilities affecting its components.
• Detected issues are evaluated and addressed.

How to implement CC7.1

1. Define baselines you can actually measure againstCIS Benchmarks or a cloud provider security baseline give you a published standard and a tool ecosystem that reports against it. A bespoke hardening document with no automated check produces no evidence between audits.
2. Detect drift continuously rather than at review timeCloud security posture management, configuration management tooling or infrastructure-as-code with drift detection all produce a continuous record. This is the difference between demonstrating the control operated all period and demonstrating it operated in the week you prepared.
3. Separate vulnerability detection from configuration detectionCC7.1 covers both, and auditors test both. Vulnerability scanning does not evidence configuration drift, and posture management does not evidence patch currency. You need each.
4. Tie severity to a remediation SLA and report against itThe evaluation and remediation half of the criterion is evidenced by an SLA compliance report, not by the scan output alone.
5. Reconcile scan coverage to the asset inventoryThe most consequential finding in this area is not an unpatched host but an unscanned one. Perform and keep the reconciliation.

Common audit findings for CC7.1

What actually gets raised against CC7.1, in rough order of how often it comes up:

• Vulnerability scanning in place with no configuration drift detection, or the reverse.
• Scan coverage materially short of the asset inventory with no reconciliation performed.
• Critical findings older than the stated SLA with no risk acceptance record.
• Baselines defined but never measured against after initial build.

Scoping CC7.1

CC7.1 is Common Criteria. It maps almost directly onto ISO 27001 A.8.8 and A.8.9 and onto NIST CSF ID.RA and DE.CM, making it one of the highest-reuse evidence sets in a multi-framework programme.

ISO 27001 mapping

CC7.1 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.7, A.8.8, A.8.9. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC7.1 rather than duplicating work.

Other System Operations criteria

All CC7 System Operations criteria →