The compliance industry spent the last decade making evidence collection faster. It never made controls more effective.
Screenshots gather themselves. Framework checklists auto-populate. Policy documents flow into audit rooms untouched. And yet 79 percent of organizations still report being surprised by security incidents that bypassed their controls.
Somewhere along the way, the industry started optimizing for proof that controls exist rather than verification that controls work. Those are different problems, and the tooling built for one can't solve the other.
Continuous controls monitoring (CCM) takes a different approach: encode controls as executable tests that run continuously against the live state of the environment.
Where the current model breaks down
Point-in-time audits rest on one assumption: if a control was effective when the auditor checked, it stayed effective until the next review. That held when infrastructure changed slowly and configurations moved through change control boards.
It doesn't hold anymore. A single Terraform apply can reconfigure hundreds of resources. SaaS applications push updates that silently change default sharing settings. Identity permissions accumulate through automated provisioning workflows that nobody reviews quarterly.
What you get is control drift: a gradual divergence between what the audit report says and what the environment actually looks like. A storage bucket encrypted at audit time gets cloned without encryption during a migration. An admin role picks up additional permissions through a group membership change that bypasses review. A logging configuration that satisfied the control gets overwritten by an infrastructure update.
None of these surface until the next audit cycle.
Organizations that shifted to continuous monitoring reduced audit findings by 50 to 70 percent, not because their controls improved on paper, but because they caught drift as it happened and fixed it before the auditor arrived. Audit prep time dropped from over 200 hours to 20–30 hours. The evidence was already there, generated by controls that never stopped running.
That gap between periodic and continuous validation is where most compliance risk lives.
Why automation alone doesn't close the gap
Tools like Drata and Vanta recognized the pain of audit preparation and built effective solutions for it. They automate evidence collection, provide pre-built control libraries mapped to common frameworks, and streamline the workflow between compliance teams and auditors. For organizations getting started with SOC 2 or ISO 27001, the templated approach plug-and-play model removes real friction.
But it assumes your organization fits the template.
Pre-built controls cover the general case: whether MFA is enabled, whether encryption is on, whether a policy document exists. Necessary, but they can't express how your organization actually implements security. A financial services company running multi-cloud with federated identity across three providers doesn't have the same control needs as a SaaS startup on a single AWS account. A healthcare org navigating HIPAA alongside SOC 2 and state-level privacy regulations needs controls that reflect its actual data flows, not a generic config check.
When controls don't match the environment, real risks go unmonitored and teams waste time on findings that don't reflect actual exposure. The template flags something risky in the general case; your architecture already mitigates it differently.
There's a deeper question here about what actually gets measured. "MFA is enabled on these accounts" is not the same thing as "every identity with a path to production data has MFA enforced." One confirms a configuration state. The other validates a security outcome across relationships that define real risk. That distinction matters the moment the auditor leaves.
CCM shifts the unit of work
CCM reframes the question. Instead of "can we prove this control existed at a point in time," you're asking "is this control effective right now, and has it been effective continuously?"
In practice, a control gets defined as an executable query against the live state of the environment. It runs continuously. If the environment matches the expected state, the control passes and evidence gets generated automatically. If something drifts, the control fails, the team gets alerted, and remediation starts immediately instead of waiting for the next audit cycle.
But continuous execution is only part of the shift. What matters more is what you choose to monitor.
I think this is where a lot of CCM conversations go wrong. People focus on the "continuous" part and miss the "controls" part. A well-designed CCM program starts with a control set: a defined collection of controls that reflects your actual risk posture, mapped to the frameworks you need to satisfy. That control set is the strategy. It captures what matters to your organization, what conditions you expect to be true at all times, and which framework requirements those conditions satisfy.
This is also what bridges compliance gaps during framework transitions. When you expand from SOC 2 to ISO 27001, or take on PCI DSS, or need to address DORA for European financial services regulation, a control-first approach makes the transition manageable. You already have controls that reflect your environment. Map them to the new framework, identify the gaps, author the additional controls to close them. Your starting point is never zero.
And here's the most persistent misconception about CCM: that it's hard to get started. People hear "continuous controls monitoring" and assume it means monitoring everything, all the time, from day one. It doesn't. CCM is incremental. Start with the controls that matter most, validate that they work, expand from there. The barrier to entry is authoring your first control, not building a complete program overnight.
How JupiterOne CCM puts this into practice
JupiterOne CCM was built to make this model work in practice.
The platform ships with pre-built control templates and catalogs mapped to established frameworks, including the CIS Critical Security Controls. CIS v8.1 organizes 18 control families into 153 safeguards, prioritized across three Implementation Groups so organizations of any size can figure out where to start. CIS also maintains official crosswalks to NIST CSF, NIST SP 800-53, ISO 27001, SOC 2, HIPAA, and PCI DSS, which means a single CIS-aligned control can satisfy requirements across multiple frameworks at once. On top of that, CIS publishes Benchmarks: prescriptive configuration guides for AWS, Azure, GCP, Kubernetes, and hundreds of other technologies that spell out exactly how to implement each control.
These templates aren't fixed checks you have to accept as-is. They're starting points you can adopt as-is or tailor to your environment. If you want to enforce CIS Safeguard 3.11 (encrypt sensitive data at rest), you can deploy the pre-built control and have it running in minutes. If you need something more specific, like encryption on every data store classified as containing customer PII, you modify the underlying query to express that condition.
The query language is J1QL, and it's what makes that tailoring possible. J1QL runs against JupiterOne's cyber asset graph: a unified model of every entity in your environment and the relationships between them. Users, roles, permissions, data stores, applications, cloud resources, network configurations. The graph connects all of it.
That's what lets you write controls that go beyond isolated configuration checks. A J1QL control can traverse relationships. Find every user with admin access to a production database who hasn't completed security training. Find users running outdated Anti-malware applications. Find every internet-exposed asset with a network path to a restricted data store. Find every S3 bucket that's both unencrypted and accessible from a role assigned to a third-party vendor. Risk propagates through chains of access and trust, and the controls should reflect that.
For teams that aren't ready to write J1QL on day one, the platform includes AI-assisted control authoring. Describe what you want in plain language ("alert me when any cloud storage bucket is publicly accessible and contains files classified as sensitive") and the platform generates the query, fills in a description and remediation steps, and assigns a severity rating. Review it, tune if needed, deploy. Live and running within minutes.
Every control execution generates tamper-proof evidence automatically. When an auditor asks for proof that a control has been operating effectively over time, not just on one date, it's already there: a continuous record of every test, every result, every remediation action. Audit prep becomes exporting what the system already captured instead of assembling it from scratch.
Where to go from here
Most organizations I talk to know they need to mature their compliance programs. The distance just looks enormous. Going from annual audit cycles to continuous assurance feels like tearing everything down and starting over. It doesn't have to be. Start with the controls that matter most, map them across your framework obligations, encode them as continuous tests, and build from there.
The visibility you get from that process, not the audit report or the evidence binder, is what actually tells you whether your compliance program is reducing risk or just documenting activity.
JupiterOne CCM is in production today with pre-built CIS-aligned templates, J1QL-powered control authoring, and continuous validation against the asset graph. If you're already a JupiterOne customer, it's in your environment. If you're evaluating how to move past point-in-time compliance, request a demo to see what it looks like when the controls actually match your environment.
Hunter Allora is a security and compliance researcher at JupiterOne.
.jpg)
