Walk through any GRC vendor's marketing page and you'll find "continuous monitoring" in the first paragraph. It's become one of those terms that means everything and therefore means nothing. A vendor whose tool polls your Okta tenant once a week calls that continuous. A vendor that generates a PDF report every quarter calls that continuous. Even spreadsheet-based compliance programs have started claiming it.
This piece is an attempt to give the term some precision — not as a marketing exercise, but because the difference between genuine continuous control monitoring and periodic evidence collection has real operational consequences for your SOC 2 program.
What a control actually is
Before "continuous monitoring" can mean anything, you need to be precise about what you're monitoring. In SOC 2 terms, a control is an observable system state or process behavior that satisfies a Trust Service Criterion. CC6.1, for instance, requires that logical access to systems is restricted to authorized individuals. That criterion maps to observable facts: which users exist in your identity provider, which users have admin privileges in your AWS account, which GitHub organization members have commit rights to production repositories.
A control, in other words, is not a policy document. It's not a screenshot of a dashboard. It's the live state of a production system at a point in time. The policy describes what the state should be. The control is the actual state.
This distinction matters because most of what passes for "evidence collection" in a typical SOC 2 program doesn't actually verify control state — it verifies that at one specific moment, someone looked at the system and wrote down what they saw. That's a very different thing.
What "point-in-time" actually means operationally
Consider how a conventional annual SOC 2 Type II audit works. The observation period — typically 12 months — begins when your last audit ended. Throughout that period, your controls are theoretically operating. Then, some weeks before the audit fieldwork begins, your internal team starts collecting evidence: user access lists, configuration exports, change management tickets, incident logs, training completion records.
The auditor evaluates whether the controls were operating effectively throughout that period. But most of the evidence they receive is point-in-time: a user list pulled on October 15th, a configuration snapshot from October 20th, a spreadsheet summarizing vulnerability scans from the prior 12 months. The auditor uses sampling and testing procedures to make inferences about the full period, but the underlying evidence for most controls is a snapshot, not a continuous record.
This creates a structural gap. A user account could have had admin privileges for 60 days mid-year, been removed before the evidence collection window, and never appear in your audit evidence. The control appears to be operating. Technically, it had a 60-day failure. Neither you nor your auditor will know.
What genuine continuous monitoring requires
Genuine continuous control monitoring has two requirements that most "continuous" tools don't satisfy simultaneously.
First, the monitoring must be automated and production-connected. Not someone manually pulling a report each week. Not a scheduled job that exports a CSV to a shared folder. The system must be reading live state from production environments — via API, not manual export — on a cadence short enough that a meaningful control failure cannot persist undetected through a full audit cycle. For most SOC 2 controls, that means polling intervals measured in minutes or hours, not days or weeks.
Second, the monitoring must validate control state against a defined expectation, not just collect data. Collecting a list of users with admin access is not monitoring. Comparing that list against an approved baseline and flagging deviations is monitoring. The difference is the presence of a pass/fail test against a control objective.
This is the definition we work from at Tenurex: a control is being continuously monitored when (a) its current state is being read directly from the production system, (b) that state is being tested against the control objective, and (c) deviations from the expected state are being surfaced in near-real time. Everything short of that is evidence collection — useful, but not monitoring.
The practical difference for your audit program
The operational consequences of this distinction are significant. Take a team running a 50-person SaaS product under SOC 2 Type II scope. Their AWS environment spans three accounts. GitHub has two organizations. Okta manages 90 users across the engineering and operations teams.
Under a conventional program, their evidence collection for an annual audit will consume two to four weeks of engineering time and produce evidence that accurately reflects control state on the specific dates the exports were pulled. If access control drift occurred and was remediated before the audit window, it may not surface. If a configuration change violated a control objective for two months and was fixed, the audit evidence may show a clean state.
Under a genuine continuous monitoring program, every control test generates a timestamped result that becomes part of an immutable evidence record. The observation period is fully covered — not through sampling, but through a continuous log of test results. When access control drift occurs, it's surfaced the same day. The evidence package the auditor receives isn't a collection of point-in-time snapshots — it's a complete record of control state over the entire audit period.
From the auditor's perspective, these two evidence packages are qualitatively different. The continuous evidence record supports a much stronger basis for opinion because it eliminates the sampling uncertainty inherent in point-in-time evidence. This is why some audit firms are beginning to distinguish between clients who present continuous evidence records versus those who present traditional snapshot-based packages.
A clarification about what continuous monitoring doesn't mean
We want to be precise here: continuous monitoring doesn't mean your auditor relationship changes fundamentally, or that SOC 2 Type II is no longer a relevant framework. The AICPA AT-C 205/305 standards that govern SOC 2 still require a management assertion, a service auditor, and a formal opinion. Continuous monitoring changes the quality and completeness of evidence available to support that opinion — it doesn't replace the audit engagement.
We're also not saying that teams running conventional evidence collection programs are doing something wrong. For a small organization with limited technical resources pursuing their first SOC 2 Type I, a well-structured manual process may be entirely appropriate. The continuous monitoring argument applies most forcefully to organizations that already have a functioning SOC 2 program and need to maintain it rigorously at scale — where the cost of manual evidence collection is high, and where the business risk of an undetected control failure is material.
What to ask your compliance tooling vendor
Given how freely the term gets used, there are a few specific questions worth asking any vendor claiming continuous monitoring capability.
Does the system read directly from production APIs, or does it rely on manual exports? Does it test each control state against a defined expectation, or does it just collect and store data? What is the actual polling interval per integration? When a control fails, what is the detection-to-alert latency? Can the system produce a complete evidence record covering an entire SOC 2 observation period, including historical test results?
If the answers are vague — "near real-time," "automated where possible," "configurable" — that's typically a signal that what's being described is sophisticated evidence collection, not continuous monitoring. Both have value. But they solve different problems, and you should know which one you're buying.
The compliance automation market is growing quickly and the marketing vocabulary has not kept pace with the technical reality. "Continuous" has become a feature adjective rather than a meaningful architectural claim. For teams whose compliance programs are material — whose SOC 2 Type II is a condition of enterprise customer contracts, whose audit evidence is reviewed by serious service auditors — the distinction is worth the precision.