SOC 2 continuous monitoring between audits: what it takes

How do you keep SOC 2 controls working between audits?

A customer or contract that asks for a SOC 2 usually expects it to stay current, which means the controls have to run every day, not only during the Type 2 observation window. Continuous monitoring is the practice of running ongoing evaluations of each control, confirming that it still operates as designed, and tracking every deficiency to closure, with the evidence produced as the work happens. Under CC4.1, the organization must select and perform ongoing evaluations, separate evaluations, or a mix of both, to confirm that the components of internal control are present and functioning. The organization owns its controls and their results. An implementation partner such as DeployOpen can plan, build and configure the monitoring and evidence pipeline inside your own infrastructure, but only the independent CPA firm issues the report.

Start by deciding which controls need ongoing evaluation and which need periodic separate reviews. Access reviews, configuration checks and log alerting usually suit ongoing evaluation, while policy reviews and a formal assessment of the monitoring program itself suit separate evaluations. Record the frequency and owner for each one. Then set up a deficiency register that logs each failed check, the person responsible, the corrective action, the due date and the date the fix was verified. CC4.2 expects you to communicate deficiencies and monitor corrective action, so an open item with no owner is a finding waiting to happen. Ask any partner or tool vendor to show how a failed check becomes a tracked ticket and how closure is recorded.

Pricing for this work depends on the number of systems in scope, the tooling you choose, and how much staff time it takes to triage results, so no price is given here. Ask for a written scope that names the monitored systems, the evaluation frequency for each control, the tools that generate evidence, the people who review results, and who keeps the deficiency register after handover. A dashboard can show the state of your environment, but the CPA firm will still test whether evaluations were performed, reviewed and acted on, so keep the records behind every screen. Confirm with your auditor early which monitoring evidence they will accept.

What CC4.1 expects you to evaluate between audits

CC4.1 restates COSO Principle 16: the organization selects, develops and performs ongoing and/or separate evaluations to confirm that the components of internal control are present and functioning. The points of focus below help you design and judge those evaluations, but they are characteristics to consider, not separate requirements, and not every one must be addressed. CC4.2 then covers assessing results, communicating deficiencies and monitoring corrective action.

Mix of ongoing and separate evaluations

Ongoing evaluations are built into daily operations, such as automated checks and routine reviews. Separate evaluations are periodic, independent looks at the controls, such as internal audits or targeted reviews. The point of focus asks you to choose a deliberate mix rather than relying on one type. For each key control, record which kind of evaluation confirms it is operating and how often it runs. Check that the mix covers the controls an auditor will sample during the observation period.

Rate of change in the environment

Evaluation frequency should follow how quickly your systems, staff, vendors and products change. A platform that deploys several times a week needs evaluations that keep pace, while a stable internal system may need less frequent checks. Review recent changes to infrastructure, access and third-party services, then ask whether your last evaluation would have caught a control drift introduced since then. Document the reasoning behind your chosen frequency so the auditor can follow it.

Baseline understanding of controls

An evaluation is only meaningful against a known starting point. Before you can tell that a control has changed or failed, you need a written description of how it should work, its owner, and its expected output. Build this baseline from your control matrix and system description, and confirm that the people evaluating understand it. Gaps here often show up as evaluations that check the wrong thing, or that pass because no one defined what failure looks like.

Knowledgeable personnel performing evaluations

The people who run evaluations need enough knowledge of the system and the control objective to recognize a real problem. This may be a security engineer reviewing configuration scan output, or an internal auditor testing access reviews. Confirm who performs each evaluation, that they have the skills for it, and that they are independent of the work they review where separation matters. Keep a record of training or assignment so the auditor can see competence, not just a schedule.

Integration with business processes

Evaluations work best when they are part of how the business already operates, such as change approvals, onboarding and offboarding, or vendor reviews, rather than a separate project that runs alongside them. Map each evaluation to the process it checks and to the meeting or ticket where its results are discussed. This reduces the risk that a failing result is noticed in a spreadsheet but never acted on, which is the gap CC4.2 is designed to close.

Adjusting scope and frequency over time

The scope and frequency of evaluations should be reviewed as the system, risks and control environment change. An evaluation that was sufficient in the first observation period may be too narrow after an acquisition, a new product or an infrastructure move. Schedule a regular review of the evaluation plan, record each adjustment and the reason for it, and confirm that changes are approved. Changes made silently mid-period are harder to explain to an auditor than changes made deliberately and documented.

How a monitoring cycle moves from baseline to closed deficiency

This sequence turns control monitoring into a traceable record: each control starts from a documented baseline, every check produces a result, and every failed result is owned, corrected, retested and filed so an auditor can follow it from start to finish.

Document the control baseline
Before any check runs, the control owner records what the control is, which system it covers, and the configuration standard it must meet. For infrastructure, that usually means a named hardening baseline, such as a CIS-based policy or an internal standard, along with the approved list of production components. The output the auditor will look for is a dated baseline tied to the control matrix, approved by someone other than the person who maintains the system. Confirm with your auditor how they expect baselines to be versioned when standards change mid-period.
Run automated checks and recurring reviews
Automated tools compare live systems against the baseline, and people perform the reviews that tools cannot, such as access reviews and assessments of new vendors or changed processes. Configuration scanners such as Wazuh's Security Configuration Assessment check endpoints against YAML policies, and admission and background policy engines such as Kyverno write pass, fail, warn, skip or error results per resource. The output is a timestamped result set for each check, retained in a form that can be re-queried later. Set the cadence of each check in the written scope, based on how often your environment changes.
Triage results into the deficiency register
Someone reviews each failed, warned or errored result and decides whether it is a true deficiency, a false positive, an accepted risk or a known exception already covered by a documented decision. Every confirmed item is logged in a deficiency register with the control it affects, the date identified, its severity as assessed by the organization, and the evidence that supports the decision. Scanner noise should be recorded as triaged rather than deleted, so the register shows how the team reached each conclusion.
Assign an owner and corrective action
Each registered deficiency gets a named owner who is accountable for fixing it and a corrective action described in enough detail that a reviewer could follow it. Under CC4.2, the organization is expected to communicate deficiencies to the people who need to act on them and to monitor corrective action until it is complete. The output is a ticket or change record linked to the register entry, showing who was told, what they agreed to do, and any interim compensating control in place while the fix is pending.
Retest to confirm closure
A deficiency is closed only when the same check that found it passes again on the corrected system, or when a different reviewer confirms the fix by inspecting the changed configuration. Retesting should use the same method and baseline as the original finding so the comparison is like for like. The output is a retest record showing the new result, the date, and the identity of the person who ran or approved the test. Where the fix changed the baseline itself, the baseline update should go through the same approval step as the original.
File the evidence for the auditor
The closed item and its supporting records are filed together: the baseline version, the original result, the triage decision, the owner's corrective action, the change record and the retest result. Auditors testing operating effectiveness across a period will sample these records and check that dates, owners and results agree. The output is a folder or GRC record that can be retrieved by control and by period without manual reconstruction. Ask your auditor which evidence format they accept and how they want population lists generated from scanning tools.

Where continuous monitoring evidence comes from

Cloud accounts and infrastructure as code (IaC) hold much of the configuration that CC7.1 asks you to define and monitor. Storage permissions, network boundaries, logging settings, encryption flags and identity policies can all drift from the approved baseline after a manual console change. Continuous checks compare the live cloud state with the versioned definitions and flag differences, and the reports from those checks become evidence that configuration standards exist and are enforced.

Configuration baselines: Approved templates for storage, networking, logging and identity, stored in version control and tied to a named owner.
Drift and change detection: Scheduled or event-driven comparisons between live resources and the IaC definitions, with each difference recorded as a finding.
Access and privilege changes: Records of who changed IAM roles, keys or group membership, and whether the change matches an approved request.
Output: Plan and drift reports, cloud configuration findings with timestamps, and pull request approvals linked to deployments.
The gap to watch for: Console changes that never reach version control. A clean drift report only proves the resources you scanned, so confirm that every account and region is in scope.

Confirm with your cloud provider and scanning tool which services and resource types their checks actually cover before you rely on them for evidence.

Ongoing or separate evaluation: which fits which control

This table compares four ways to evaluate whether SOC 2 controls are present and functioning between audits, under CC4.1. Read each row for what it covers, the evidence it produces, and the conditions where it fits best, then use the mix to decide what goes into your monitoring plan.

Evaluation type	What it covers	Typical evidence	When it fits
Ongoing automated checks	Configuration, access settings and policy state on systems that change often, checked continuously or on a short schedule	Scan reports, policy compliance results, alert and ticket history showing findings and closure	High rate of change and controls that can be tested by machine without judgment
Recurring manual control reviews	Judgment-based controls such as access reviews, vendor reviews and policy attestations by the control owner or a delegate	Signed review records, reviewer notes, exception lists and follow-up tickets	Controls that need human judgment and run on a fixed cadence, such as quarterly access reviews
Separate internal audits or assessments	Whether controls work as designed, evaluated by a party outside the control owner's line of management	Independent test workpapers, sample selections, findings reports and management responses	Higher-risk controls, areas where owners may be marking their own work, or controls that have failed before
Periodic penetration or vulnerability testing	Exposure of systems and applications to attack, tested at intervals or after significant changes	Test scope, methodology, findings with severity, retest results and remediation records	Internet-facing systems and changes that alter the attack surface, tested at a frequency the monitoring plan justifies

What usually breaks monitoring between audits

Most SOC 2 monitoring gaps are not missing tools. They are dashboards that stand in for evidence, findings that never close, and scope that quietly drifts from the systems the auditor actually tests. Each card below names one failure, the SOC 2 criterion it weakens, and the practical fix to put in place before the next observation period.

Dashboard mistaken for evidence

A live dashboard shows that something was true when someone looked at it. It does not show that a control operated across the period, who reviewed the results, or what was done about them. Keep a dated export or retained record for each review, with the reviewer's name and the decision taken. The AICPA SOC 2 Working Group chair has noted that SOC tools can pull evidence into a real-time dashboard, but only if quality is maintained. Check that each dashboard tile maps to a named control and a retained artifact that an examiner can sample.

Deficiencies logged but never closed

Findings from scans, reviews and internal audits often sit in a ticket queue with no owner, due date or retest. Under CC4.2, the organization should assess results, communicate deficiencies and monitor corrective action. Require every finding to carry a severity, an accountable owner, a target date and a closure note that links to a retest. Review open items at a fixed governance meeting and record that review. An auditor will ask whether a deficiency from month three was actually fixed by month six.

Scanner exceptions with no owner or expiry

Teams suppress failing checks because a fix is inconvenient or a system is legacy. Under CC7.1, configuration and vulnerability monitoring should detect unauthorized or noncompliant components, so an accepted exception still needs a visible record. Keep an exception register that states the rule, the affected asset, the business reason, the compensating measure, the approver and an expiry date. Review it on a schedule and reopen any exception that passes its expiry. Policy engines such as Wazuh SCA and Kyverno report failures per resource, so exceptions should be reconciled against those reports rather than hidden in them.

Silent failure of agents and connectors

Monitoring that stops reporting looks the same as monitoring that finds nothing. A Wazuh agent that loses its connection, a Kyverno background scan that stops running, or a log forwarder that fails after a certificate change can leave gaps that go unnoticed for weeks. Under CC4.1, the evaluations must be present and functioning, so the monitoring itself needs monitoring. Create an alert for each data source when it has gone quiet beyond an agreed threshold, and log that alert and its resolution as evidence. Test the alert once by deliberately disconnecting a test source.

New systems missing from scope

Monitoring covers the assets someone remembered to enroll. A new cloud account, a second Kubernetes cluster, an acquired company's domain or a contractor-built service can run for months outside the policy scan and the access review. Under CC4.1, the scope of ongoing evaluations should be adjusted as the environment changes. Compare the asset inventory against monitoring coverage on a fixed cadence, and require a scope check as part of the change and onboarding process. Record the reconciliation so the auditor can see that completeness was tested, not assumed.

Configuration drift after emergency changes

During an incident, engineers often disable a check, open a port or adjust a policy to restore service, then forget to revert or record it. The system then runs in a state that the change process never approved, which weakens both CC7.1 and the change management evidence in CC8. Require an emergency change record that is raised during the incident and closed afterward, with a compare step between the approved baseline and the running state. Ask the policy scanner to flag any drift from the approved configuration, then document each deviation as either reverted or formally accepted.

What monitoring dashboards cannot replace

A monitoring dashboard is an input to the examination, not the examination. The chair of the AICPA SOC 2 Working Group has said that SOC tools can connect to client systems and pull evidence into a real-time dashboard, provided quality is maintained (Journal of Accountancy, February 2026). That qualification carries the weight. The auditor still decides whether the evidence is complete, whether the population was captured correctly and whether the control it supports is designed suitably for the criteria in scope. A dashboard that shows a green status for an access review does not tell the auditor who approved the access, whether the reviewer understood what they were looking at, or whether the review covered every system in the system description.

Several parts of a control remain human work that no dashboard performs. Someone must evaluate each deficiency, decide its severity and decide whether it is a control deficiency, a significant deficiency or something that affects the opinion. Someone must document management's review of monitoring results and the corrective action that followed, which is the substance behind CC4.2. Someone with the right knowledge must show that they reviewed the results, and the record of that review is evidence in its own right. The auditor also selects samples and performs independent testing across the observation period, and a dashboard that refreshes continuously cannot substitute for that sampling. Confirm with your auditor, before you build the pipeline, which dashboard outputs they will accept as evidence, which need a signed review record attached, and whether they want screenshots, exports or direct system access.

A separate regime also addresses continuous monitoring, and it should not be confused with SOC 2. The FTC Safeguards Rule allows continuous monitoring to take the place of some of the system-wide vulnerability scans that would otherwise be required every six months (FTC guidance). That is a rule for certain financial institutions under the Gramm-Leach-Bliley Act, and it does not change what a SOC 2 auditor will test. Using continuous monitoring to satisfy the FTC rule does not mean the same output automatically satisfies a SOC 2 criterion, so treat each regime's acceptance conditions separately.

Who owns the monitoring work and who tests it

Your organization owns its controls. That includes the monitoring plan under CC4.1, the decision about how often each control is evaluated, and the judgment on whether a deficiency matters. Management also reviews what the monitoring tools report and signs off that the system description and assertions match how the system actually runs. These responsibilities cannot be handed to a tool or a partner, because the auditor will ask named people to explain what they reviewed and what they did about it.

The monitoring plan: Define which controls are evaluated continuously by tooling, which are evaluated separately by people, and how often each separate evaluation happens.
Deficiency decisions: Decide whether a failed check is a control deficiency, assign an owner, set a due date and record the closure, as CC4.2 expects.
Management review: Have a named manager review scanner and policy results on a set schedule and keep a record of the review.
Scope changes: Update the monitoring scope when systems, vendors or products change, and record the reason.
Accountability: Keep a current list of control owners who can speak to their controls during fieldwork.

Check that each control owner can explain, without preparation, what they reviewed last month and what happened to every open item.

Questions buyers ask about monitoring between audits

Is continuous monitoring required for SOC 2, and where does CC4.1 fit?

SOC 2 does not require a specific monitoring product, but it does expect you to evaluate whether your controls are present and functioning. CC4.1 restates COSO Principle 16: you select, develop and perform ongoing evaluations, separate evaluations, or a mix of both to confirm that the components of internal control work. Ongoing evaluations are built into daily operations, such as automated checks and reviews. Separate evaluations are periodic, independent looks, such as internal audits. The AICPA's 2017 Trust Services Criteria place this under the monitoring activities series, so an auditor will ask how you decided which mix fits your rate of change. Confirm with your auditor how they expect that decision to be documented.

How much effort does monitoring take, and what drives it?

Effort depends less on the tool and more on how often your environment changes, how many systems are in scope, and how many people must review results. The main drivers are the number of cloud accounts, endpoints and clusters, the frequency of deployments, and how many findings need triage. Initial setup is typically a one-time cost: defining baselines, writing policies and wiring alerts into a ticketing workflow. Ongoing costs recur: reviewing exceptions, maintaining policies as software changes, and keeping evidence retained for the audit period. When requesting a quote from any partner, ask which of these items are one-time, which recur, and who performs each.

Does a monitoring platform alone make us SOC 2 compliant?

No. A monitoring platform produces evidence and detects drift, but SOC 2 examines whether your controls operate as described, and that includes the people and processes around the tool. An auditor will want to see who owns each alert, how a finding becomes a ticket, how it is resolved, and whether management reviewed the results. A dashboard showing green status does not prove that a deficiency was evaluated or that corrective action happened. The platform supports the control; the organization still owns the control design, the policies, and the decisions recorded in the system description.

What must our internal team provide to make monitoring credible?

Your internal team owns the control, so it must supply the parts that only your organization knows. That usually includes approved configuration baselines, a list of in-scope systems, named owners for each alert category, documented review cadences, and the procedure for escalating deficiencies. Engineers should be able to explain why a baseline was chosen and how exceptions are approved. Auditors test whether the people performing evaluations are knowledgeable and objective, so separate reviewers from the people who build the systems where practical. A partner can help prepare these artifacts, but the team must be able to operate them after the engagement ends.

How are deficiencies handled when they are found during the period?

A deficiency found mid-period should be logged, evaluated for severity, assigned an owner, and tracked until corrective action is verified. CC4.2 covers this: assessing results, communicating deficiencies to the people responsible for corrective action, and monitoring that the fix happens. Keep a register that records the date found, the risk assessment, the decision, the fix, and the verification evidence. Auditors will sample these records during a Type 2 examination, so gaps such as findings closed without evidence can become exceptions. Ask your auditor how they want deficiencies that were corrected within the period described in the report.

Will the auditor accept output from our monitoring tools as evidence?

Often yes, but the auditor decides. Tool output is generally accepted when the auditor can see how it was produced, that its configuration was controlled, that it covers the relevant population, and that results were reviewed. The AICPA SOC 2 Working Group chair has noted that SOC tools can pull evidence into a real-time dashboard, provided quality is maintained. Open-source scanners such as Wazuh's Security Configuration Assessment, which uses policies mostly based on CIS benchmarks, or Kyverno's policy reports, which record pass and fail results from admission events and background scans, can produce this kind of output. Confirm with your auditor which fields, retention and sampling approach they need, and whether they will rely on the tool's output or re-perform checks.

What should we ask a monitoring partner before signing?

Start by asking for the written scope: which systems, controls and evidence types are covered, and which are excluded. Ask who performs each task, what the partner delivers, and which items are one-time versus recurring. Ask how the partner will hand over policies, baselines and runbooks so your team can operate them. Confirm that the partner prepares evidence but does not issue audit reports, and ask the auditor to confirm in writing which evidence they will accept. DeployOpen works from a written scope agreed before work begins and does not publish a price list, so ask for a quote tied to that scope. Also ask how ongoing support is structured if your environment changes after go-live.

How DeployOpen sets up monitoring and evidence for the audit

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the monitoring, configuration checks and evidence trails that support CC4.1 and CC7.1 run between audits. The independent CPA firm tests the controls and issues the report; DeployOpen prepares the systems and evidence for that examination.

How we scope

Engagements are fixed-scope, with the monitored systems, control owners and evidence sources agreed in writing before work starts.
The written scope lists which configuration baselines, scanners and policy engines are in place and who reviews their output.
Scope also records how deficiencies are logged, assigned, tracked to closure and reported to management.

How we build

We deploy self-hosted monitoring and configuration assessment tools inside your cloud accounts, data centers or air-gapped networks.
We configure policy checks against your own documented baselines, then retain their results as dated, reviewable records.
We test that alerts, scan schedules and evidence exports still run after platform upgrades and infrastructure changes.

How we hand over

You receive runbooks describing each recurring evaluation, its owner, its frequency and the evidence it produces.
Documentation maps each monitoring output to the relevant criterion so your CPA firm can trace it without guesswork.
Handover includes a deficiency log template and a walkthrough so your staff can operate the controls after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, aligned to your audit calendar.
Retainers can cover tool upgrades, policy updates after system changes and review of monitoring output before each audit fieldwork.
Ask your CPA firm early which evidence formats and sampling approach it expects, so we can build exports to match.

SOC 2 continuous monitoring between audits