SOC 2 CC4.1: Ongoing and Separate Evaluations

SOC 2 CC4.1 requires an organization to select, develop, and run a mix of ongoing and separate evaluations to confirm its internal controls are present and working. It opens the CC4 series (Monitoring Activities), and a frequent finding under it is a company that treats a green GRC dashboard as proof of monitoring when nobody has checked whether the underlying controls actually operate.

What does SOC 2 CC4.1 require?

In plain terms, CC4.1 asks how the organization checks that its controls are still working, not just that they exist on paper. It draws a line between two kinds of checking. Ongoing evaluations are built into day-to-day operations, such as automated configuration checks, access review workflows, and vulnerability scans that run on a cadence. Separate evaluations stand outside the process and look back at it: internal audits, control self-assessments, penetration tests, and third-party assessments.

CC4.1 maps to COSO Principle 16, one of the two monitoring principles COSO defines. The criterion expects a deliberate balance of the two evaluation types, chosen for the environment rather than adopted wholesale from a template. A fast-changing cloud estate leans harder on continuous, automated evaluation; a stable on-prem system can rely more on periodic separate reviews.

The verb that carries the weight is ascertain. Running a scan or standing up a dashboard is not the control; the control is using what the evaluation produces to judge whether each part of the internal control system is present and functioning. An evaluation that nobody reads, or a dashboard nobody validates, does not meet CC4.1 no matter how much data it collects.

What are the CC4.1 points of focus?

The AICPA defines 8 points of focus for CC4.1, seven drawn from the COSO framework and one additional point for the trust services criteria. 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.

• A balance of ongoing and separate evaluations. Management combines evaluations that run continuously inside business processes with periodic evaluations performed from outside them, rather than relying on either alone.
• Calibrated to risk and rate of change. The choice, scope, and frequency of evaluations reflect how quickly the business and its systems change and how much risk a given area carries, so higher-risk and faster-moving areas are evaluated more often.
• Anchored to a known baseline. The design and current state of the control system provide a baseline, so an evaluation can tell whether something has drifted from how it was meant to operate.
• Performed by knowledgeable and objective evaluators. The people running evaluations understand what they are assessing, and separate evaluations are performed periodically by parties objective enough to give reliable feedback.
• Built into operations. Ongoing evaluations are integrated into business processes and adjust as conditions change, so monitoring is part of how the system runs rather than a once-a-year event.
• A variety of evaluation types. The trust services point adds that management uses a range of evaluations, which may include first- and second-line control testing, internal audit and compliance assessments, resilience assessments, vulnerability scans, security assessments, penetration testing, and third-party assessments.

How do you meet CC4.1 in cloud environments?

Cloud environments meet CC4.1 by combining always-on automated evaluation with periodic independent review:

• Continuous configuration and compliance checks. AWS Config and Security Hub, Azure Policy and Defender for Cloud, or Security Command Center evaluate resources against a defined baseline and flag drift, which is the ongoing-evaluation half of the criterion.
• Recurring vulnerability scanning. Authenticated scans of cloud workloads and container images run on a schedule, producing evidence that the environment is evaluated between audits rather than only at a point in time.
• A validated GRC or control-monitoring platform. Continuous control monitoring is useful only after someone maps which systems are in scope and what evidence each control genuinely requires, so the compliance percentage reflects control operation rather than upload activity.
• Periodic penetration testing. An annual, human-led penetration test against in-scope applications is the separate evaluation auditors most often expect, and its report distinguishes validated, exploitable risks from raw scanner output.
• Internal control self-assessments. A scheduled walkthrough of key controls, documented with results and follow-ups, covers the separate-evaluation point of focus without requiring a formal internal audit function.

How do you meet CC4.1 on-prem?

On-prem environments run the same mix of ongoing and separate evaluations against owned hardware and, often, longer-lived systems where automated coverage is thinner:

• Scheduled internal vulnerability scanning. Internal scans across servers, network devices, and workstations run on a defined cadence, with results tracked to closure as ongoing evidence of evaluation.
• Configuration baseline checks. Tooling such as CIS-CAT or scripted checks against a hardened baseline confirms that systems still match their intended configuration, which is the on-prem equivalent of cloud drift detection.
• Penetration testing scoped to the architecture. Legacy and on-prem applications need testing scoped in phases, separating authentication testing from authorization and business-logic testing, so known framework issues do not dominate the report.
• Internal audit or independent review. A periodic review of controls against the security program, performed by someone outside the team that operates them, is the separate evaluation that ISO 27001 A 5.35 also expects.
• Documented management review. Results of ongoing and separate evaluations are brought to a scheduled management review so the organization can judge whether controls remain present and functioning.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC4.1?

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

The overlap is partial because ISO 27001 splits monitoring across its management system: A 5.35 covers the independent, separate review, while the ongoing-evaluation half is carried by Clause 9.1 (monitoring, measurement, analysis and evaluation) and Clause 9.2 (internal audit) in the main body of the standard. Evidence of penetration tests and internal reviews reuses cleanly in both directions. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC4.1 opens the CC4 Monitoring Activities series and pairs with CC4.2, which covers what happens after an evaluation finds a problem: evaluating and communicating deficiencies to the people who can fix them. The ongoing evaluations CC4.1 calls for overlap with the day-to-day security monitoring under CC7.2, and the vulnerability scanning it references as an evaluation type is the subject of CC7.1. CC4.1 sits above these operational criteria: it is the requirement to evaluate whether the whole control system, including monitoring itself, is present and functioning.

Frequently Asked Questions

What does SOC 2 CC4.1 mean?

SOC 2 CC4.1 requires an organization to select, develop, and perform a mix of ongoing and separate evaluations to determine whether its internal controls are present and functioning. Ongoing evaluations run inside daily operations, such as configuration checks and vulnerability scans, while separate evaluations stand outside them, such as internal audits and penetration tests. It is the first criterion in the CC4 Monitoring Activities series and maps to COSO Principle 16.

What evidence satisfies CC4.1?

The core evidence is continuous configuration and compliance monitoring reports, vulnerability scan results with remediation tracking, a penetration test report from a qualified provider, internal audit or control self-assessment records, and management review minutes that reference evaluation results. Together these show both ongoing and separate evaluations ran and that their output was used to judge whether controls work.

What is the difference between ongoing and separate evaluations?

Ongoing evaluations are built into business processes and run continuously or on a frequent cadence, such as automated drift detection and scheduled scans. Separate evaluations are performed periodically from outside the process, such as internal audits, control self-assessments, and penetration tests. CC4.1 expects a balance of both, weighted toward continuous evaluation where the environment changes quickly.

Does a GRC platform satisfy CC4.1?

Not on its own. A GRC platform helps run ongoing evaluations, but it marks controls satisfied based on uploaded evidence and has no context about the specific environment. CC4.1 is met only when the platform is configured to reflect the real systems in scope and someone reviews its output to confirm controls are operating, supplemented by separate evaluations such as penetration testing.

How often does SOC 2 require a penetration test?

SOC 2 does not name a fixed frequency, but an annual, human-led penetration test against in-scope applications is the separate evaluation auditors most commonly expect under CC4.1, with additional testing after significant changes. The report should show validated, exploitable findings rather than raw vulnerability scanner output, which auditors treat as a scan and not a penetration test.