Continuous Controls Monitoring
Continuous controls monitoring is the practice of evaluating security and compliance controls against live system evidence on an ongoing basis, instead of sampling them once per audit cycle. Kyūdō implements it by converting Microsoft security telemetry into evidence artifacts and rescoring every affected control each time a signal fires.
The result is a compliance picture that stays synchronized with the estate it describes, across 1,400+ controls and 80+ frameworks. This page explains the model, the signal pipeline behind it, and what it changes for audit preparation.
Point-in-time audits vs continuous monitoring
Evidence has a half-life. A screenshot taken for the auditor is true the moment it is captured and decays from that point: the policy it documents can change the next day, and nothing in the screenshot will say so. The two models differ in how they treat that decay.
Point-in-time evidence
- A screenshot or export captured for the auditor
- True at capture, stale immediately after
- Collected by hand, once per framework, once per cycle
- Posture between audits is assumed, not observed
Continuous evidence
- Evidence that recalculates on every relevant signal
- Freshness is a measured property, not an assumption
- Collected once, mapped to every framework requiring it
- Drift is visible when it happens, not at the next audit
How security telemetry drives continuous evidence
Continuous monitoring only works if evidence arrives without human effort. Kyūdō sources it from the Microsoft Security estate the organization already runs, described in detail on the Microsoft-native GRC page, plus signals from AWS, Google Cloud, and Oracle Cloud.
A signal fires
A conditional access policy changes in Entra ID, an endpoint reports to Defender, a policy evaluation completes in Azure Policy. The event is the trigger; no export step exists.
Affected controls rescore
The Continuous Multi-Framework Control Assessment Engine (CMCAE) rescores each affected control: completeness on a 0 to 100 scale and capability maturity on a 1 to 5 scale.
Every mapped framework updates
Because controls map to frameworks through the Secure Controls Framework crosswalk with STRM semantic mapping (NIST IR 8477), one rescored control updates every framework that references it.
How controls connect to evidence
In Kyūdō, the link between a control and its evidence is an edge in the Compliance Graph, not a folder convention. Each evidence artifact is a node connected to the controls it supports, and each artifact carries three properties an assessor can verify: a hash proving the artifact has not changed, lineage recording where the signal came from and when, and a confidence score stating how much weight the evidence can bear.
Because the connection is structural, the question "which evidence supports this control, and how fresh is it" is a graph query rather than a document hunt. The Controls Hub exposes this view per control, and the AI-native platform page explains how the same graph grounds AI answers.
Concrete examples of continuous evidence
Each example below is a live system state that becomes a hashed, lineaged, confidence-scored artifact the moment it changes.
Conditional access policy state as access control evidence
Endpoint coverage as endpoint protection evidence
Analytics rule coverage as detection capability evidence
Classification results as data protection evidence
Policy compliance state as configuration baseline evidence
Audit week becomes retrieval, not reconstruction
When evidence is collected continuously and mapped as it arrives, audit preparation stops being an archaeology project. The evidence the assessor asks for already exists, already carries verifiable provenance, and is already linked to the control and framework requirement it satisfies.
The same evidence base serves every framework in scope. Adding a framework means reviewing a mapping, not restarting collection: see the frameworks page for how the crosswalk covers SOC 2, ISO 27001, CMMC, and others.
Questions, answered
Continuous controls monitoring is the practice of evaluating security and compliance controls against live system evidence on an ongoing basis, instead of sampling them once per audit cycle. Kyūdō implements it by converting Microsoft security telemetry into evidence artifacts and rescoring every affected control each time a signal fires.
An annual audit samples control evidence at a point in time: a screenshot or export is true the moment it is captured and decays from that moment on. Continuous monitoring recalculates control status on every relevant signal, so the compliance picture reflects the estate as it is now. The audit itself still happens; what changes is that evidence is retrieved rather than reconstructed.
Examples from the Microsoft estate include Microsoft Entra ID conditional access policy state, Microsoft Defender endpoint coverage, Microsoft Sentinel analytics rule coverage, Microsoft Purview classification results, and Azure Policy compliance state. Kyūdō also ingests signals from AWS, Google Cloud, and Oracle Cloud, and every artifact carries a hash, lineage, and confidence score.
On every signal. When a connected service emits a relevant event, Kyūdō's assessment engine (CMCAE) rescores the affected controls for completeness on a 0 to 100 scale and capability maturity on a 1 to 5 scale, and every framework mapped to those controls through the Secure Controls Framework crosswalk updates at the same time.
No. Independent assessors still perform audits and issue certifications; Kyūdō supports readiness rather than certifying anything itself. What continuous monitoring changes is the preparation: evidence with verifiable provenance is already collected and mapped when the assessor asks for it, so audit week becomes retrieval instead of reconstruction.
Looking for more? See all frequently asked questions.
Watch controls rescore from your own signals
Deploy inside your Azure tenant and see evidence freshness become a measured property of your program.