Most defense suppliers prove their security controls work on one day a year: the day of the assessment. The other 364 days, they hope. Continuous compliance monitoring for CMMC replaces that hope with a daily check, so the evidence is already there when an assessor asks for it.
This guide explains what continuous control verification is, why a once-a-year snapshot fails, how the verification loop works from collection to POA&M, and what it takes to run it in your own environment. We built Continu-US to do exactly this, and we draw on it throughout, but the approach applies however you implement it.
What continuous control verification means
Continuous control verification is the practice of checking, on a set cadence, that each security control you claim is actually in place, and keeping the result as evidence. Not a quarterly spreadsheet exercise. A recurring, automated check against the real systems, mapped to the specific requirement it supports.
For CMMC Level 2, that requirement list comes from NIST SP 800-171 Rev 2: 110 requirements, which NIST SP 800-171A breaks into 320 assessment objectives. Assessors evaluate against those objectives, so the objective is the right unit to map evidence to. A result that says “encryption enabled” is a data point. A result mapped to 3.13.11[a], with the device list, the time and a hash, is evidence.
Why a once-a-year snapshot does not hold
Systems change faster than assessments happen. A firewall rule gets edited during an outage. A new laptop joins without the standard build. A cloud admin loosens a sharing setting to unblock a project. Each change is small, each is usually well intentioned, and each can quietly move a control away from what your System Security Plan says.
The assessment is a snapshot, but the obligation is continuous. A Level 2 certification is not a one-time event: you affirm your compliance status annually, and you are expected to be operating the controls the whole time. If your only proof is the one you gathered the month before the assessor arrived, you have no way to know how long a gap has existed or whether it is still open.
The usual workaround is a scramble: weeks of screenshots, exported configs and emailed spreadsheets. It works once. It does not scale, and the evidence goes stale the day after you collect it.
The verification loop, step by step
Continuous verification is a loop with six steps. Each one has to hand off to the next without a person re-keying data.
- Collect. Pull configuration and activity data from the systems you already run on a schedule: endpoints, cloud tenants, network devices, ticketing and your SIEM.
- Map. Tie every result to the objective or requirement it supports, so “firewall baseline matches” lands on the right line of the framework.
- Compare and alert on drift. When a setting moves from its approved value, record the device, the before value and the after value the day it happens. See configuration drift and control 3.4.2.
- Open a finding. Every failing check becomes a finding with its affected devices. Where a failure is a false positive, informational or not applicable, record that decision with a reason, scope and review date. See findings dispositions.
- Track the fix. Turn a real finding into a plan of action and milestones. See POA&M requirements and the 180-day clock.
- Package the evidence. Produce reports and evidence an assessor can verify independently. See evidence a C3PAO will accept.
Continu-US runs this loop from collection through to the POA&M register and evidence package, so a failing check goes from detection to a pre-filled POA&M item in one click.
Where the evidence comes from
The strongest position is to use the systems you already run rather than adopt a new platform. In Continu-US, evidence comes from six places:
- Endpoints (Windows and Linux). A lightweight, signed check script reports hardening, encryption, logging, patching, accounts and services daily over an encrypted channel. The script is tamper-checked.
- Cloud. Identity, email, data protection and configuration across Microsoft 365, Azure, AWS, Google Cloud and Google Workspace, plus email DNS. Data is either uploaded or collected from connected accounts, with no stored keys, and hash-manifested.
- Network devices. Firewall and switch configurations are evaluated against your baseline, with passwords and keys stripped before upload.
- Ticketing. Vulnerability remediation and change records, so process controls are verified from real tickets instead of assertions.
- SIEM. Alert and case handling, so monitoring and incident response are backed by actual activity.
- Your team’s records. Documents, recurring activities and implementation statements, kept beside the technical results.
That last category matters more than most teams expect. Plenty of Level 2 objectives are about people and process: reviews, trainings, tests, policies. A platform that only reads configurations covers part of the framework. Process controls need their own evidence, which is why a document register and recurring-activity tracking belong in the same system.
Why map to 320 objectives instead of 110 requirements
A requirement like 3.1.1 (Limit information system access to authorized users, processes acting on behalf of authorized users, or devices) has multiple parts. Objective-level mapping is how you show each part is covered. It also gives you a precise answer when an assessor asks, “Show me how you meet 3.1.1[f] (the hardest one for most organizations by the way!).”
Objective-level mapping also makes scoping honest. Some objectives are inherited from a provider or not applicable to your boundary. Recording that explicitly, rather than silently skipping them, is what lets results reflect your actual environment. We cover that in scoping and tailoring for CMMC.
What a day in the loop looks like
The following rows are illustrative, not client data. They show what a morning’s verification can look like:
- 3.13.11[a], FIPS-validated cryptography enabled: Verified. 42 of 42 endpoints, checked at 06:04.
- 3.1.3[e], data loss prevention enforced on Drive and Gmail: Verified. Google Workspace connected account, checked at 06:02.
- 3.4.2[b], device security setting rule changed from baseline: Drifted. One workstation, a change ticket linked, POA&M ready.
The third row is where the value sits. The device configuration change did not wait for next year’s assessment to surface. It was flagged the day it happened, tied to a change ticket so you can see whether it was authorized, and set up so that if it is a real gap, a POA&M item is one click away.
What does not automate, and how to handle it
No tool verifies everything, and any vendor claiming otherwise should worry you. Two honest limits:
- Settings no API exposes. Some configuration cannot be read programmatically. Continu-US checks Google Workspace against Google’s own CMMC Level 2 configuration guide and keeps a recorded review for the settings no Google API exposes, so the manual part is documented rather than forgotten. See Google Workspace and their CMMC Level 2 guidance.
- Periodic activities. Reviews, tests and trainings happen on a calendar, not a config. Scheduling them and attaching evidence is how they stop slipping between assessments.
Proving it to an assessor
Evidence is only useful if an assessor can trust it. That means per-device results, timestamps and a way to confirm nothing changed after collection. Hashed evidence packages let an assessor verify the contents independently. Assessment-period reports show the whole window, not one day.
If you also bring your own hardening baseline, results can be grouped by STIG benchmark, CIS benchmark or Group Policy Object with CAT I/II/III severity, and STIG Viewer checklists can be exported per device. See STIG, CIS and GPO baseline compliance.
Where it runs matters
A compliance tool that holds your evidence and cloud credentials is itself in your risk picture. Continu-US is deployed as a managed application inside your own Azure subscription, signs in through your Microsoft Entra tenant, and runs in Azure Commercial or Azure Government. It uses managed identities, keeps keys in your Key Vault and takes nightly immutable backups. AWS and Google are read through short-lived, read-only federated sign-ins your administrators set up, with no keys stored. Nothing is hosted by ATLLC and nothing calls home outside of application updates (unless you opt for no vendor access). More in deploying compliance tooling inside your Azure boundary and read-only cloud monitoring with no stored keys.
One organization, or many
You can monitor your own environment, or many: an MSP across its customers, or a prime watching its suppliers, each with its own scope and framework. See monitoring CMMC across customers and suppliers. Because one evidence set maps to CMMC Level 2, NIST SP 800-53 Rev 5 Moderate and PCI DSS v4.0.1, you can switch views without re-collecting.
Getting started
There are two ways to use it. In the managed service, ATLLC runs it for you and you receive ongoing reports and POA&M tracking. In the licensed platform, it is installed in your Azure subscription and your team runs it day to day, with ATLLC support when you need it. Either way the onboarding has four steps: Discovery (what you run, your scope and your baseline), Mapping (checks and sources aligned to your framework), Pilot (a small set of devices and sources verified with your team) and Production (full rollout, connectors on, reporting cadence agreed). A typical small or mid-size defense supplier is fully onboarded in 4 to 6 weeks.
Frequently asked questions
What is continuous monitoring for CMMC? It is running automated or manual checks against your systems and documentation on a recurring schedule, mapping each result to a NIST SP 800-171 requirement or 800-171A objective, and keeping the evidence so your compliance status is provable on any day, not just assessment day.
Does continuous monitoring replace a CMMC assessment? No. A certification assessment is performed by an authorized assessor. Continuous verification helps you stay ready between assessments and gives the assessor better evidence. It does not guarantee any assessment outcome.
How many assessment objectives are in CMMC Level 2? NIST SP 800-171A defines 320 assessment objectives across the 110 requirements of NIST SP 800-171 Rev 2.
Can I use my existing tools? Yes. The approach is to use the systems you already run (endpoints, cloud tenants, network devices, ticketing and SIEM) rather than adopt a separate platform to replace them.
How long does onboarding take? For a typical small or mid-size defense supplier, 4 to 6 weeks from discovery to full production.
See it live
Want to see how a production platform looks and operates? Request a live demo.
Anthony Timbers LLC (ATLLC) is a cybersecurity and compliance firm in Fredericksburg, Virginia. ATLLC never assesses an organization it provides consulting or managed services to, so Continu-US is offered independently of any assessment engagement. Example results shown are illustrative, not client data.
