What "continuous compliance" has to mean mechanically, or it means nothing at all.

NIST's Information Security Continuous Monitoring guidance, SP 800-137, defines ISCM as maintaining ongoing awareness of security, vulnerabilities, and threats to support risk-management decisions — an awareness process built on defined metrics, data feeds, and analysis, not a claim about how often a tool runs a job. A scanner that runs hourly is not automatically continuous monitoring in that sense; it is continuous monitoring only if its output feeds a defined decision process.

That distinction matters because most vendor use of "continuous compliance" has quietly substituted cadence for the actual mechanism NIST described. Checking a control's underlying system every hour is a data-collection frequency. Whether that frequency produces continuous assurance depends entirely on what happens to the result — which is the part the marketing claim usually skips.

Picture a nightly job that checks whether multi-factor authentication is still enforced across an identity provider and finds it is not. If that failure has nowhere structured to go — no link to the specific control evidence it invalidates, no named control owner, no record of prior state — the organization has generated an alert, not maintained compliance. The gap between "we detected drift" and "we know what evidence this drift invalidates and who is accountable for it" is exactly the gap between telemetry and assurance.

This is also where evidence identity becomes load-bearing again: a drift detection is only actionable if it can name the specific artifact and control record it affects. A scanner that reports findings against a system, with no link to the governed evidence graph recording what was previously accepted for that control, cannot tell anyone what needs to be redone.

A signed access-review attestation reasonably stays current for a defined review period. A firewall rule export is stale the moment the rule set changes. A penetration test result has a shelf life set by scope and severity, not by a calendar quarter. Treating all evidence as equally perishable — or worse, treating a framework's own audit period as the only freshness signal — produces two failure modes: evidence that is technically "within period" but operationally meaningless, and evidence that gets needlessly re-collected on a fixed schedule when nothing about the underlying system changed.

A mechanical definition of continuous compliance has to specify freshness per artifact class, tied to what actually invalidates that class of evidence — a configuration change, a personnel change, an elapsed review interval — rather than inheriting one blanket freshness rule from whichever framework happens to be the current audit.

The obvious objection: isn't a daily automated check strictly better than an annual manual one, even without all this apparatus? Yes — more frequent detection is better than less frequent detection, on its own terms. But calling frequent detection "continuous compliance" without the identity, freshness, and routing pieces oversells what the buyer is getting: a faster alarm, not a governed, current, reviewable record of control state that an assessor can rely on without re-deriving it from scratch.

The honest framing separates the two claims. "We detect configuration drift daily" is true and valuable on its own. "We are continuously compliant" is a much larger claim that requires the drift to resolve into a governed decision — accepted, remediated, or exception-flagged — by a named person, on a record that persists past the moment the alert fired.