SOC 2 CC7.1: Detecting Configuration Changes and New Vulnerabilities

SOC 2 CC7.1 is where the vulnerability management program lives inside the Trust Services Criteria: it requires an organization to detect configuration changes that introduce new vulnerabilities and to identify susceptibility to newly discovered ones. It opens the CC7 series (System Operations) and is where auditors evaluate configuration baselines, drift detection, vulnerability scanning, and remediation timelines as one connected program.

What does SOC 2 CC7.1 require?

The criterion has two halves. The first covers vulnerabilities the organization creates for itself: a configuration change that opens a port, weakens a permission, or disables a control. Meeting it means having defined configuration standards and a way to notice when systems drift from them. The second covers vulnerabilities the world discovers: a CVE published against software already in the environment. Meeting it means scanning on a defined cadence, monitoring vendor advisories, and acting on the results.

CC7.1 is technology-neutral. It does not name a scanner or prescribe a scan frequency. It requires detection that is deliberate, documented, and demonstrable across the in-scope environment, including devices that cannot run a scanning agent. An open-source scanner wired into a CI pipeline can satisfy CC7.1; an enterprise platform whose agents cover half the asset inventory cannot.

Cadence can vary by asset class, provided the tiers, reasoning, and remediation timelines are written into policy; auditors check whether the program the policy describes is the program the evidence shows.

What are the CC7.1 points of focus?

The AICPA defines 5 points of focus for CC7.1. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Configuration standards and compliance monitoring. Defined configuration standards exist for infrastructure and software, and both are monitored for noncompliance with those standards.
• Change detection on critical files. Mechanisms such as file integrity monitoring alert personnel when critical system files are modified without authorization.
• Detection of unknown or unauthorized components. Procedures identify hardware and software that appears in the environment without being registered or approved.
• Vulnerability scanning and remediation. Scans run periodically and after significant changes, and critical findings are remediated.

How do you meet CC7.1 in cloud environments?

Cloud environments satisfy CC7.1 through native scanner and configuration services, plus scanning built into the deployment pipeline:

• Native vulnerability scanning. Amazon Inspector, Microsoft Defender for Cloud, and Google Security Command Center scan instances, container registries, and workloads continuously and export findings with severity ratings. Auditors check coverage first: the service has to be enabled across every in-scope account or project.
• Config rules for drift. AWS Config, Azure Policy, and Google Cloud organization policies evaluate resources continuously against defined rules and record every noncompliance event. Mapped to a CIS-aligned rule set, this covers the configuration-standards half of the criterion as a managed service.
• Container scanning in the pipeline. A scanner wired to three triggers (a schedule, every merge to main, and a manual run) with a notification on failure turns image scanning into a continuous evidence stream. One small team stood this up with an open-source scanner and no dedicated security engineer, giving the auditor a timeline of scan results instead of a single screenshot.
• Dependency scanning with documented outcomes. Package manager warnings on unmaintained dependencies do not fail an audit; unexamined warnings do. A periodic review that records each outcome (updated, risk accepted, or planned for the next cycle) converts warning icons into evidence of a working process.
• Static analysis where it fits the stack. Teams running framework versions that commercial SAST tools no longer support can meet the requirement with an open-source scanner carrying rules for their specific version.

Whatever the scanning stack, findings need remediation timelines the team can meet, documented in the vulnerability management policy, with a ticket for every critical and high finding showing who fixed it and when.

How do you meet CC7.1 on-prem?

On-prem environments have no native scanner service to switch on, and the asset mix is harder: servers accept agents; firewall appliances, managed switches, and storage controllers do not. One company that had run entirely on-premises for over 15 years had never performed a vulnerability scan; the lead developer's process was checking each system by hand for available updates. A tiered program resolved it, and the on-prem vulnerability scanning guide covers the full implementation:

• Tier assets by exposure. Tier 1 (internet-facing production, VPN gateways, bastion hosts) gets weekly agent-based scans and a 48-hour critical SLA. Tier 2 (hypervisors, internal servers, build infrastructure) gets quarterly scans and a 7-day critical SLA. Tier 3 (managed switches, storage controllers, UPS interfaces) gets quarterly-to-annual firmware verification against vendor advisories.
• Match the scanning method to the device. Agents on servers; authenticated scans over SSH, SNMP, or HTTPS for appliances with management interfaces; network-based scans or manual firmware checks for devices that support neither, with the reasoning for each method documented.
• Run patches as tracked changes. Patches are tested in non-prod, applied inside maintenance windows, and recorded in tickets that double as change records. The on-prem patch management guide covers the workflow, including network isolation on a restricted VLAN as the compensating control for systems that cannot be patched.
• Baseline against CIS with documented exceptions. A custom baseline records a decision per benchmark item: pass, remediate, not applicable, or disabled with justification and compensating controls. Recurring benchmark scans then double as drift detection, and syslog alerting catches configuration changes on appliances that cannot run agents. The configuration baselines guide covers the tooling.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC7.1?

A second recurring gap is the aspirational SLA. One team drafted a 24-hour critical remediation commitment modeled on enterprise standards; testing windows made it unreachable, and every missed cycle generated evidence of a policy violation. Adjusting to 48 hours produced a commitment the team met consistently.

How does CC7.1 map to ISO 27001:2022?

Organizations pursuing both frameworks can reuse the CC7.1 evidence package almost wholesale for these Annex A controls. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC7.1 detects the problem; the adjacent criteria handle what happens next. CC7.2 covers monitoring system components for anomalies, CC7.3 covers evaluating security events, and remediation itself flows through change management under CC8.1. CC6.8 (malware prevention) shares much of the same scanning and baseline tooling. The hardening baselines that CC7.1 monitors for drift are established under CC6.1, and the Trust Services Criteria guide summarizes every series.

Frequently Asked Questions

What does SOC 2 CC7.1 mean?

SOC 2 CC7.1 requires an organization to use detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibility to newly discovered ones. In practice it covers configuration baselines, drift and change detection, detection of unauthorized components, and vulnerability scanning with remediation of critical findings.

What evidence satisfies CC7.1?

Typical CC7.1 evidence includes the scanner configuration and schedule, scan execution history, remediation tickets for critical and high findings, written risk acceptances for unremediated items, a configuration baseline with per-item decisions, drift and file integrity alerts with investigation notes, and firmware inventories for network appliances.

Does SOC 2 require vulnerability scanning, and how often?

CC7.1's points of focus call for scans conducted periodically and after significant changes, without prescribing a cadence. A tiered schedule (weekly for internet-facing production, quarterly for internal infrastructure, annual verification for isolated low-risk appliances) is defensible when the tiers and their reasoning are documented in policy.

Does SOC 2 CC7.1 require penetration testing?

No criterion names penetration testing. CC7.1 calls for detection and monitoring procedures, and vulnerability scanning with remediation typically satisfies it. Many organizations run an annual penetration test anyway, because auditors frequently request one under the monitoring-activities criteria and the results reuse directly for ISO 27001 A 8.8.

What remediation SLAs do auditors expect under CC7.1?

SOC 2 sets no prescriptive timelines. In practice, 48 hours for critical and high findings on internet-facing systems, 7 days for medium, and 30 days for low is well received. An SLA the team consistently meets is a stronger audit position than an aggressive one that produces a record of documented misses.