CC4.1 ongoing and separate evaluations: SOC 2 evidence

What SOC 2 CC4.1 asks for in ongoing and separate evaluations

CC4.1 asks the organization to show that it selects, develops and performs ongoing and separate evaluations that confirm each component of internal control is present and functioning. In plain terms, a SOC 2 auditor will not accept a written control set on its own. You need evidence that someone checks the controls over time and notices when they stop working. CC4.1 restates COSO Principle 16, and it is the criterion that asks whether your monitoring is real. Ongoing evaluations are built into daily operations, such as automated checks, access reviews run on a schedule and alerts that fire on configuration drift. Separate evaluations are periodic, independent looks at the controls, such as internal audit reviews, penetration tests and independent certifications against an established specification. Most mature programs use both.

The risk CC4.1 targets is drift. A control can pass at the start of an observation period and quietly fail three months later after a new service is deployed, an administrator is granted broad rights or a logging agent is disabled. Without monitoring, nobody sees it until the next audit or, worse, an incident. The hard part is calibration. Scope and frequency must follow your rate of change: a platform that ships weekly needs checks that run far more often than a stable internal system. The people performing evaluations also need enough knowledge of the controls and enough independence from the teams they check to report honestly. Confirm with your auditor how they expect you to document both the frequency and the rationale for it.

The points of focus under CC4.1 help you design this program. They cover the mix of ongoing and separate evaluations, the rate of change in your environment, a baseline understanding of the controls, knowledgeable personnel, integration with business processes, adjusting scope and frequency, and objective evaluation. Points of focus are characteristics to consider, not separate requirements, and not every one must be addressed in the same way. A practical first step is to write down your baseline for each control, name the owner who evaluates it, and set a frequency tied to how fast the underlying system changes. The AICPA 2017 Trust Services Criteria with revised points of focus is the primary text to check your design against.

Which systems, teams and third parties CC4.1 evaluations must cover

CC4.1 evaluations are only as useful as their scope. The decisions below determine which systems, controls, owners and vendors get checked, how often, and what triggers a rescope. Revisit them whenever the system or the organization changes, not only at audit time.

Production and supporting infrastructure

Evaluations should cover every environment that processes or stores in-scope data, including production, the build pipeline, identity systems, logging and backup stores. Supporting infrastructure is often where controls quietly lapse, such as a logging pipeline that stops shipping events or a backup job that fails silently. Build an inventory of accounts, clusters, hosts and regions, and confirm each one is either in scope or documented as excluded with a reason.

Controls named in the system description

The system description defines which controls the auditor will test, so evaluations must cover at least that control set. Map each control to the evaluation that confirms it is present and functioning, whether a continuous check, a periodic review or an independent test. Controls with no evaluation attached tend to surface as findings late in the examination period.

Teams that own controls

Each control needs a named owner who can explain how it works and who is responsible for acting on its results. Evaluations should test whether owners are knowledgeable and have the access and authority to act, not only whether a control exists on paper. Check for gaps where a control depends on a team that has been reorganized, shrunk or outsourced.

Subservice organizations under monitoring

Where a cloud provider, hosting company or other vendor performs part of the service, the organization still needs evidence that those controls are working. Collect each subservice organization's SOC report or equivalent certification, review its exceptions and complementary controls, and record which of them the organization relies on. Evaluations should note where a vendor report is missing, expired or does not cover the period under examination.

Rate of change as a rescope trigger

Scope and frequency should follow how fast the system changes. A new cloud region, an acquisition, a new product line or a major platform migration can add systems and controls that the existing evaluation plan never covered. Define in advance which events force a review of scope, and record each rescope decision with its date and rationale so the auditor can see the plan kept pace with the system.

Continuous versus periodic evaluations

Some controls suit continuous evaluation, such as configuration drift checks, vulnerable software detection and policy admission results, because state changes often. Others suit periodic evaluation, such as access reviews, internal audits and penetration tests, which need human judgment and a fixed scope. Decide per control which type applies, document the reason, and confirm that each evaluation's results reach someone accountable.

How an auditor tests CC4.1 ongoing and separate evaluations

This table compares what the service auditor does, what evidence they request and where evaluations commonly fall short for CC4.1. Read each row as a step in the examination: the plan and its risk basis come first, then performed evaluations across the period, then whether findings reach CC4.2. The main takeaway is that a plan on paper does not satisfy the criterion unless the evaluations were carried out as written.

Test area	Auditor approach and evidence requested	Common findings
Evaluation plan and risk basis	Reads the documented plan, its scope, frequency and the rationale tying them to risk and the rate of change. Requests the risk assessment inputs the plan relies on.	Plan lists activities without explaining why they were chosen or how often they run.
Plan coverage of components	Checks whether the plan reaches each internal control component, including controls over cloud and self-hosted platforms, not only policy reviews.	Evaluations concentrate on documentation while technical controls are never tested.
Performed evaluations (Type 2)	Samples evaluations across the audit period, requesting reports, dated results, tickets and sign-off records for each sampled instance.	Plan is not followed, with scheduled evaluations skipped or completed late without explanation.
Monitoring continuity	Looks for gaps in automated monitoring, scan and report history across the observation period, and asks how gaps were detected and addressed.	Monitoring stopped during the period, for example an agent, scanner or policy engine was disabled and not re-enabled.
Stated scope of each evaluation	Confirms each evaluation records what was assessed, the systems covered and the criteria used.	Evaluations with no stated scope, so the auditor cannot tell what was actually covered.
Evaluator knowledge and independence	Checks evaluator qualifications and role, and whether the person evaluating a control was separate from the person operating it.	Control owners assess their own work, or the evaluator lacks documented knowledge of the system.
Objectivity of separate evaluations	Reviews internal audit or independent assessment reports for their independence from the function assessed and for the basis of conclusions.	Internal audit reports restate management's view without testing evidence.
Link to CC4.2	Traces sampled findings to deficiency evaluation, communication to responsible owners and corrective action tickets through to closure.	Findings recorded but not communicated, or corrective actions left open at period end.

How to implement CC4.1 evaluations step by step

This sequence turns CC4.1 from a statement of intent into a working evaluation program, where each control is understood, each evaluation is planned and assigned, and every result is recorded in a form an auditor can test.

Build a baseline control inventory
The control owner, with the GRC or security lead, lists every control the SOC 2 relies on, states what it is designed to do, names the system or process it covers, and records who performs it and how often. The working inventory should match the control matrix and the system description, so that no evaluation is aimed at a control the organization does not actually run. The step is complete when the inventory is approved by the control owners and the security lead, and each entry shows its design and owner.
Map each control to an evaluation method
For every control, decide whether it is best checked by ongoing monitoring (automated alerts, configuration scans, policy reports), a separate evaluation (internal audit, penetration test, independent certification against a recognized specification), or both. Record the reason for each choice, such as a control that changes often needing continuous checks while a design decision is better reviewed separately. The output is an evaluation plan that links every control in the inventory to at least one method, and any gap is written down with an owner.
Assign knowledgeable evaluators
Name a person for each evaluation who understands the control and the tool or test used to assess it, and confirm that they are independent of the team that operates the control wherever the evaluation is meant to be objective. Internal audit, an external tester or a certification body may be used for separate evaluations, and the reasons for the choice should be recorded. The step closes with a roster that lists each evaluator, their scope and their qualifications, so that an assessor can see who performed each check.
Set scope and frequency by risk and change
Using the risk assessment from CC3, set how often each evaluation runs and how deep it goes. Controls tied to high-risk systems, frequent change or recent incidents usually warrant more frequent or wider evaluation, while stable, low-risk controls can be checked less often. Ask the auditor early whether the proposed frequencies and scope match what they expect to test. The output is an evaluation calendar with a scope statement for each entry, approved by management.
Run the evaluations and capture results
Carry out each ongoing check and separate evaluation as scheduled, using the tools or procedures named in the plan. Capture the raw output, such as vulnerability reports, policy results, audit workpapers or penetration test findings, along with the date, the scope tested and the evaluator's name. Results that show a control is not present or not functioning move into the deficiency process described in CC4.2. The step is complete when each evaluation has a retained record that a third party could follow without asking the evaluator for context.
Sign off each evaluation record
Have the evaluator and an accountable manager review each record and sign it, confirming what was tested, what was found and whether any follow-up is required. Signed records are the evidence that the evaluation was performed, not just planned, so keep them in the same repository as the policies and control evidence. A missing signature or undated record is a common reason an auditor cannot rely on the evaluation, so check completeness before the period closes.
Review the plan at significant change
Revisit the inventory, method mapping, evaluator roster and calendar when a significant change occurs, such as a new system, a new service provider, an acquisition, a material incident or a change in the threat picture. Update the scope and frequency where the change affects risk, and record the reason for each adjustment. The review is complete when the plan is re-approved and the change log shows which evaluations were added, widened, reduced or retired.

Evidence that satisfies SOC 2 CC4.1

CC4.1 is tested by looking at what the organization evaluated, how it evaluated it and what it found. The cards below name the records an auditor typically asks for, and each one needs to be kept current across the whole observation period, not assembled just before fieldwork.

Written evaluation plan

A dated document that lists which controls are evaluated, by whom, how often and by which method, with the risk rationale behind each choice. It shows the evaluations were designed around risk and rate of change rather than run by habit. Check that the plan names the in-scope systems, that it was approved by someone accountable for the control environment, and that it is revised when the architecture, vendors or team change.

Baseline control inventory

A recorded starting point of the controls, configurations and asset inventory against which later evaluations are compared. Without a baseline, an evaluation cannot show that a control is still functioning as designed. Keep the inventory under version control or export it on a schedule, so each comparison can point to the state of the system on a known date.

Continuous monitoring outputs

Scan results, policy reports and alert histories generated automatically as systems run. Kyverno, for example, writes PolicyReport resources with pass, fail, warn, skip or error results for each matching resource, reflecting current cluster state. Retain these outputs with timestamps, because a current dashboard shows only today, while the auditor needs proof of monitoring across the period.

Internal audit reports and working papers

Reports from separate evaluations performed by people independent of the control owner, with the procedures, samples and conclusions recorded in the working papers. Confirm the reviewer has enough knowledge of the controls to judge them and that findings flow into the deficiency process covered under CC4.2. Keep the papers with the reports so an auditor can retrace how each conclusion was reached.

Penetration test reports and remediation tracking

Test reports from a qualified tester covering the in-scope application, API and infrastructure, paired with a record showing how each finding was fixed, accepted or retested. The report alone shows what was found. The tracking record shows the organization evaluated the result and acted on it. Confirm the test scope and date match the period under examination.

Independent certification reports

Certificates and assessment reports for in-scope systems issued by the certifying body, such as an ISO certification, where that standard is relied on as an independent evaluation. The organization cannot produce these itself. Obtain the report or certificate directly from the certifying body, record its scope and validity dates, and confirm the scope covers the systems described in the SOC 2 system description.

What CC4.1 evaluations cost to run

This table compares the main cost components of running ongoing and separate evaluations for CC4.1, who is paid for each, whether it recurs, and what moves it up or down. Use it to structure a quote request, since most cost differences come from scope, evaluation frequency and the number of systems in scope rather than from any single line item.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Monitoring and scanning tooling or licenses	Recurring	Number of endpoints, cloud accounts and clusters monitored; commercial license tiers. Self-hosted open-source tools remove license spend but not operating effort.	Consolidate on tools that cover several evaluation types; confirm each tool's license and hosting terms in writing.
Engineering time to build and maintain monitors	One-time build, recurring upkeep	Number of controls mapped to automated checks; how often platforms and dependencies change.	Automate checks only where the output is reliable; document the rest as manual evaluations with a fixed cadence.
Internal audit staffing	Recurring	Size of the control set; required independence from the teams being evaluated; frequency of separate evaluations.	Scope separate evaluations to high-risk and fast-changing areas; reuse prior-period work papers where the control is unchanged.
Penetration testing and independent certification fees	Recurring, usually per engagement	Number of applications, APIs and environments tested; depth of testing; whether a certification is pursued for a specific specification.	Agree a written test scope tied to risk; confirm which results the auditor will accept as evaluation evidence.
Evidence upkeep	Recurring	Number of evaluations that must be recorded; retention period; how many tools feed the evidence store.	Set a single evidence location and naming convention; collect evidence as a by-product of routine monitoring.
Auditor sampling and fieldwork time	Recurring, per examination period	Number of evaluations the auditor samples; gaps or exceptions that require follow-up; quality of the evidence provided.	Prepare a sample-ready evidence index and confirm the sampling approach with the auditor before fieldwork starts.

Open-source tools that produce CC4.1 evidence

CC4.1 asks for evaluations that show controls are present and functioning, and the evidence for that is usually a stream of scan results, policy outcomes and audit records rather than a single document. The four tools below each produce one kind of that evidence. None of them certifies compliance: the organization owns the control, and the independent auditor decides whether the evidence is sufficient.

Vulnerability detection on endpoints

Wazuh's vulnerability detection correlates the software inventory that each agent collects from an endpoint with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications. For CC4.1, the output is a recurring, dated record of what was found on monitored systems and how it changed over time. Confirm that agents cover every endpoint class in scope, and decide whether the offline copy is needed for networks without outbound access. Wazuh is licensed under GPL-2.0-only, so review what that license requires if you modify and distribute the code.

Software inventory on enrolled hosts

Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its evidence is a per-host view of installed software and the advisories that apply to it, which supports the evaluation of whether patching and configuration controls are working. Check which advisory sources cover your operating systems, since coverage differs by platform, and confirm how results are exported for the auditor. Fleet is released under the MIT license, which permits broad reuse with the license notice retained.

Policy results for Kubernetes workloads

Kyverno writes PolicyReport and ClusterPolicyReport resources that record pass, fail, warn, skip or error results for each matching resource. These results come from admission events and from periodic background scans of existing resources, so the reports reflect current cluster state, not only what was deployed. For CC4.1, that gives a continuing record that configuration policies are enforced, plus a trail of exceptions. Confirm which policies are in scope, how often background scans run in your clusters, and who reviews the fail and error entries. Kyverno is licensed under Apache-2.0.

Assessment tracking across frameworks

CISO Assistant runs audits and compliance assessments across more than 200 frameworks, including SOC 2, and maps controls between frameworks automatically. For CC4.1, it can hold the evaluation schedule, assessment results and findings for each control in one place, which helps show that evaluations are planned and performed on a defined cadence. Check whether the mappings it applies match the frameworks your auditor will use, and treat any mapping as something to verify rather than accept. CISO Assistant is licensed under AGPL-3.0-only, so network-facing modifications may carry source disclosure obligations.

Who does the CC4.1 evaluation work

Your organization owns CC4.1. The COSO principle behind it expects management to select and perform evaluations that confirm internal controls are present and functioning, and that responsibility cannot be handed to a vendor. Your team decides which controls matter most, how often each one is evaluated, and who is qualified to perform each evaluation. It also decides what happens when an evaluation finds a gap.

Owning the evaluation plan: Document which controls are checked continuously, which are checked by separate evaluation, and the frequency for each, tied to your risk assessment under CC3.
Naming accountable owners: Assign a named person for each control area who reviews results and signs off on them.
Protecting evaluator independence: People who operate a control should not be the only people who evaluate it. Separate operators from reviewers where your size allows.
Acting on findings: Keep records showing that results reached the right people and that changes followed.
Keeping the plan current: Revisit scope and frequency when systems, vendors or teams change.

Check that your plan names an owner, a frequency and a reviewer for every monitored control, and that you can show a recent review of each one.

Where CC4.1 evaluations usually fall short

Most CC4.1 findings do not come from missing tools. They come from evaluation plans that stop matching how fast the environment changes, from monitoring that lapses without anyone noticing, and from evidence that cannot be rebuilt for the audit period. The cards below cover six gaps and the concrete step that closes each one.

Evaluation plan lags rate of change

An evaluation schedule written once and left alone often assumes a quarterly release cadence in an environment that now deploys daily. CC4.1 expects scope and frequency to be adjusted to the rate of change, so a plan that does not move with the platform leaves new services and configurations unevaluated. To close the gap, tie each evaluation to a trigger such as a new service, a new cloud account, a major upgrade or a change in data flows, and review the plan whenever the system description changes. Check the plan against the change log for the last audit period.

Monitoring that quietly stopped

A scanner, log forwarder or agent can fail silently after a certificate expires, a credential rotates or an instance is replaced, and the dashboard simply shows fewer results. Nobody sees a finding because nothing is reporting. Close this by monitoring the monitors: alert when an agent stops checking in, when a scheduled scan has not run within its expected window, or when a report has no new data. Keep a dated record of these health checks, since an assessor will ask whether the ongoing evaluation was running during the whole period.

Evaluators who also operate controls

When the engineer who configures a control is also the one who checks it, the evaluation loses objectivity, which CC4.1 treats as a point of focus. This is common in small teams where one administrator both runs patching and reviews patch status. Separate the roles where the team allows it: assign evaluation tasks to someone outside the operating path, or have a second person review the evaluation output and sign off. Where separation is not possible, document the compensating review and state who performed it in the evidence.

Penetration test findings without tracked remediation

A penetration test report that lands in a shared folder with no owner, due date or retest result is an evaluation that produced no action. CC4.1 covers the evaluation itself, while CC4.2 covers evaluating and communicating deficiencies, so the two must connect. Each finding should be logged in a tracker with an owner, severity, target date and a retest reference, and the retest should confirm the fix. Ask your testing provider to state the scope and date of each test so the findings can be matched to the period under review.

No baseline understanding of controls

Evaluators cannot judge whether a control is functioning if nobody has written down what it should do. A missing baseline means a scanner result or audit log has no reference point, and the evaluation becomes a judgment call. Build a control baseline for each in-scope component: the intended configuration, the owner, the expected output and the policy it supports. Store it under version control so changes to the baseline are themselves traceable. Compare evaluation results against this baseline each cycle.

Evidence that cannot be reproduced

Auditors sample evaluation results from across the observation period, and a dashboard that shows only today's state cannot prove what was true in March. Evidence needs to be retained with timestamps and the query or configuration that produced it, so the same result can be regenerated. Confirm the retention period your platform uses, export evaluation outputs on a fixed schedule, and check that the exports can be opened and read months later. Ask the auditor which evidence format and retention they expect before the period starts.

CC4.1 questions buyers ask before hiring help

How much effort does CC4.1 take, and what drives it?

The effort depends mostly on how many systems are in scope, how often they change, and how much of the evaluation work already exists. CC4.1 asks the organization to run ongoing and separate evaluations that confirm each internal control component is present and functioning, so the workload is the recurring evaluation schedule plus the records that prove it ran. Organizations with frequent deployments, many cloud accounts or several subservice organizations usually need a wider and more frequent schedule than a small company with one stable environment. Ask any consultant or implementation partner to show how they would scale the schedule to your rate of change, and ask which parts of the work recur each year and which are one-time setup.

How long does it take to build an evaluation program before a Type 1 or Type 2 window?

The honest answer is that the duration depends on your starting point, and no fixed number applies to every organization. A Type 1 report looks at the design of controls as of a date, so the evaluation program needs to be defined and visibly operating before that date. A Type 2 report tests operating effectiveness across an observation period, so evaluations must run consistently throughout that period, not just be planned. Confirm with your CPA firm which evaluations they expect to see in each window, and ask your partner to map the setup work against those dates. Any timeline you receive should come from a written scope, not a generic estimate.

What does the work need from our team?

CC4.1 needs named people, system access and time. Assign an owner for each evaluation type, such as continuous monitoring, internal audit, penetration testing and any independent certification you rely on, and an owner who can accept or escalate results. Evaluators need read access to the systems they review, including cloud consoles, identity records, vulnerability data and change logs. They also need protected time to perform reviews and document them. Knowledgeable personnel are an explicit point of focus, so the people running evaluations should understand the controls they test. Write these responsibilities into a RACI or similar document before the observation period begins.

Can an in-house team run CC4.1 alone?

Yes, an in-house team can run CC4.1 alone if it has the skills, independence and capacity to do so. The key test is objectivity: the people who operate a control should not be the only people who evaluate it, so many teams separate the operating function from the reviewing function, even within a small group. A consultant or implementation partner can build the schedule, instrument the monitoring tools and prepare evidence, but the organization still owns its controls and its conclusions. An independent auditor then tests whether the evaluations occurred and were objective. Decide early which evaluations your staff can perform credibly and which need an outside party to give them independence.

Do penetration tests count as evaluations under CC4.1?

Penetration tests can count as separate evaluations when they are planned, scoped to the relevant systems and their results are reviewed and acted on. The CC4.1 points of focus name penetration testing as one type of evaluation management can use, alongside internal audit assessments and independent certifications against established specifications. A single test once a year rarely shows that controls are functioning throughout a period, so you should define how tests fit with ongoing monitoring and how findings feed into deficiency handling under CC4.2. Confirm with your auditor how they will treat test scope, timing and retesting before you rely on a test as evidence.

What should we confirm in the auditor's engagement letter?

The engagement letter should confirm the report type, the Trust Services Criteria categories in scope, the period covered and the auditor's responsibilities versus management's. For CC4.1, ask how the auditor will test ongoing and separate evaluations, which evaluation types they consider acceptable, what evidence they will request and how they will sample it. Confirm the timing of fieldwork, how exceptions will be communicated, and what management must provide, including the written representations required for a SOC 2 examination. Ask whether the auditor can also prepare you, and confirm that independence rules will prevent conflicts with any advisory work. Keep the letter alongside your written scope so both parties share one definition of done.

Who issues the SOC 2 report if an implementation partner helps with CC4.1?

Only the independent CPA firm issues a SOC 2 report. An implementation partner, such as DeployOpen, can plan and set up self-hosted platforms, configure monitoring and vulnerability tools, and assemble evidence for your evaluation program, but it does not issue audit reports, attestations or certifications. Your organization remains responsible for its controls and the statements it makes in its system description. Keep these roles clear in your statement of work so no one assumes that setup work equals an opinion on operating effectiveness.

How DeployOpen scopes and prepares CC4.1 evaluation evidence

DeployOpen helps organizations plan, build and document the evaluations that show CC4.1 controls are present and functioning, inside the client's own infrastructure. The organization owns its controls and decides the scope of its evaluations, while DeployOpen prepares systems, monitoring and evidence for the independent CPA firm to test.

How we scope

Written scope lists which systems, controls and monitoring tools are covered for CC4.1 evaluations before work starts.
Scope names which evaluations are ongoing, which are separate, and who performs each one.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

Monitoring and vulnerability detection are configured in the client's environment, with alert and review routes documented.
Evaluation frequency and scope are set against the client's risk assessment and rate of change in systems.
Test plans for penetration tests and internal audit reviews are prepared so results can be traced back to specific controls.

How we hand over

Documentation covers each evaluation's owner, method, frequency, and the records it produces for the auditor.
Evidence packages are organized by control so the CPA firm can sample and trace results without rework.
Runbooks describe how the client's own staff repeat evaluations after handover, without DeployOpen involvement.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Retainers can cover re-running evaluations when systems change, which is often where evidence gaps appear.
Confirm with DeployOpen during scoping which evaluation records must be retained and for how long.