Updated July 2026 to reflect the FedRAMP Consolidated Rules for 2026, released June 25, 2026.

The core concept

Continuous monitoring is how you verify that security controls still work, on a defined cadence, with evidence. The activities vary: log reviews, scans, control testing, POA&M updates, access reviews, configuration checks, policy reviews. But the pattern is always the same. Scheduled task. Defined owner. Captured evidence. Completed on time.

This is the discipline that ties all the others together. Vulnerability management produces findings that feed into continuous monitoring. Change management produces change records that feed into continuous monitoring. Access reviews, configuration baselines, incident responses, and compliance checks all generate data that rolls up into the continuous monitoring program.

graph LR
    VM[Vulnerability Scans] --> CM[Continuous Monitoring]
    ChM[Change Records] --> CM
    UAM[Access Reviews] --> CM
    IR[Incident Response] --> CM
    CM --> RPT[Monthly Activity Report / OCR]

    style VM fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style ChM fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style UAM fill:#5c4a1a,stroke:#ffc857,color:#fff
    style IR fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style CM fill:#1a5c3d,stroke:#51cf66,color:#fff
    style RPT fill:#1a3d1a,stroke:#a9dc76,color:#fff

The failure mode is predictable. You deploy security tools. You write a monitoring plan. You run the activities for a few months. Then someone misses a weekly log review. Then a monthly scan slips by a week. Then quarterly access reviews are two weeks late. None of these feel like a crisis in the moment. But they compound. By the time an assessor looks at the evidence, the gaps paint a picture of a program that does not actually run on cadence.

What CMMC requires

CMMC does not give you the prescriptive cadence that FedRAMP does. It does expect you to prove that ongoing monitoring actually runs, that the results feed into your security program, and that you act on what you find.

The relevant practices:

• CA.L2-3.12.3 (Level 2): Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls. 5-point, not POA&M-eligible. This is the core continuous monitoring practice. “Ongoing basis” means you define the cadence, document it, and stick to it. Assessors will look at whether the cadence is reasonable for each activity and whether you met it.

Supporting practices:

• CA.L2-3.12.1: Periodically assess the security controls in organizational systems to determine if the controls are effective in their application. This is periodic control testing, not just monitoring.
• CA.L2-3.12.2: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities. The POA&M practice. ConMon activities generate findings. Findings become POA&M items. POA&M items need to be tracked and worked.
• SI.L2-3.14.6: Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. Active monitoring for threats, not just compliance checking.
• AU.L2-3.3.1: Create and retain system audit logs and records. The logging infrastructure.
• AU.L2-3.3.5: Correlate audit record review, analysis, and reporting processes for investigation and response. Correlation across sources, beyond collection.

What a C3PAO assessor looks for:

• Monitoring tools actually deployed and producing output: SIEM, EDR, IDS/IPS, vulnerability scanners
• A defined monitoring strategy that describes what is monitored, how often, and by whom
• Active POA&M tracking with items being worked, not just documented
• Alert triage with evidence of execution, beyond raw alert volume
• Log retention that matches the stated policy
• Periodic control effectiveness testing with documented results

The common gap: ad-hoc monitoring with no repeatable process. Tools are deployed but alerts are never triaged. POA&Ms exist on paper but nobody is working them. There is no single view of what monitoring activities are due, overdue, or complete. Evidence of monitoring execution does not exist in a structured, retrievable format.

CMMC does not prescribe the cadence. Assessors still expect to see the pattern. If you say you do weekly log reviews, they will ask to see 12 months of weekly log review evidence. If the evidence is sporadic, the practice does not score.

What FedRAMP Rev5 requires

FedRAMP calls this Ongoing Certification now. The Consolidated Rules for 2026 renamed continuous monitoring and replaced the reporting model, and the new VDR, VER, and CCM rules apply to Rev5 as well as 20x. But the underlying discipline is still a calendar: dozens of activities, each on a defined cadence, each with specific evidence requirements. Miss a recurring task and you pick up findings that compound over time.

The relevant controls:

• CA-7 (Continuous Monitoring): the full ConMon control. Defines the continuous monitoring strategy, metrics, monitoring frequencies, and reporting cadences.
• AU-6 (Audit Record Review, Analysis, and Reporting): review and analyze audit records for indications of inappropriate or unusual activity. This is the log review requirement.
• AU-2 (Event Logging): determine the events that organizational systems are capable of logging and must log. This defines what gets captured.

The cadences (these are the ones that drive most ConMon findings):

Weekly:

• Audit log review and analysis

Monthly:

• OS, database, web application, container, and service configuration scans (machine-based verification at least monthly under VDR-TFR-MVF)
• Privileged account compliance checks
• Vulnerability status updates feeding the accepted-vulnerabilities list
• A human-readable report of vulnerability detection and response activity to all necessary parties (VER-TFR-MHR, MUST)

Quarterly:

• Public content reviews
• Developer privilege reviews
• Access recertifications
• Ongoing Certification Reports (CCM-OCR-AVL, MUST every 3 months) and Quarterly Review meetings (CCM-QTR-MTG) under CCM

Annually:

• Non-privileged account compliance reviews
• Policy reviews across 17+ control families
• Contingency plan testing
• Incident response testing
• Security awareness training
• Role-based security training
• FedRAMP independent assessment
• Penetration testing
• Baseline configuration review

The monthly ConMon package is gone. Under the Consolidated Rules, the monthly deliverable is the human-readable activity report (VER-TFR-MHR), backed by machine-readable vulnerability reporting for automated retrieval (VER-TFR-MRH). The POA&M is gone with it: vulnerabilities not fully mitigated or remediated within 192 days of evaluation MUST be categorized as accepted vulnerabilities (VER-TFR-MAV), and the accepted-vulnerabilities list is what agencies see.

Multi-tenant environments have additional complexity. Consumer-specific review, analysis, and reporting is required. Each tenant’s data has to be accounted for in the ConMon program.

What independent assessors look for: evidence that every cadenced activity actually ran on schedule. Not the plan to do it, the evidence that it was done. Monthly activity reports and Ongoing Certification Reports delivered on cadence. Consistency between what the monitoring plan says and what the evidence shows.

The common gap: activities tracked in spreadsheets with no enforcement. Cadences missed because nobody realized a task was due. No single view of what is due, overdue, or complete. Monthly activity reports assembled by hand from five different tools. The monitoring plan describes a full program, but the execution evidence tells a different story.

Dozens of recurring activities across four cadences cannot be run from a spreadsheet. Missed tasks become findings. Findings compound.

What FedRAMP 20x requires

Rev5 treats ConMon as a calendar. 20x treats it as a live data pipeline.

The shift is structural. The rules do not even say “continuous” anymore: the Consolidated Rules use the defined term “persistently,” and what used to be called continuous monitoring is now Ongoing Certification. Under 20x, monitoring means automated validation running persistently, an Ongoing Certification Report every 3 months that summarizes what the automated checks have already been doing, and an annual FedRAMP independent assessment covering every KSI.

The relevant KSIs, all in the Monitoring, Logging, and Auditing family:

• KSI-MLA-OSM (Operating SIEM Capability): a Security Information and Event Management or similar system is used and persistently reviewed for centralized, tamper-resistant logging of events, activities, and changes.
• KSI-MLA-RVL (Reviewing Logs): logs are persistently reviewed and audited. Not collected. Reviewed.
• KSI-MLA-EVC (Evaluating Configurations): the configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested.
• KSI-MLA-LET (Logging Event Types): a list of information resources and event types that will be logged, monitored, and audited is maintained and persistently reviewed to ensure these activities occur.
• KSI-MLA-ALA (Authorizing Log Access): a least-privileged, role and attribute-based, and just-in-time access authorization model for log data. Optional at Class B, required from Class C up.

How the KSIs get validated is now explicit. Every 20x Class B, C, and D provider MUST include all Key Security Indicators in a FedRAMP independent assessment at least once per year (IVV-CSX-AIA). On top of that, automated validation scales by Certification Class (FRC-CSX-VVK): Class B SHOULD implement at least 1 automated method per KSI, Class C MUST implement at least 2, and Class D MUST implement at least 4.

Under CCM, which now applies to both 20x and Rev5:

• Ongoing Certification Reports (CCM-OCR-AVL, MUST): one human-readable report every 3 months, shared with all agencies at once. It covers accepted vulnerabilities, transformative changes, planned changes, the list of agencies using the service, and FedRAMP Reportable Incidents or an attestation of none. One report. One cadence. All stakeholders.
• Quarterly Review meetings (CCM-QTR-MTG): a synchronous review every 3 months. MAY for Class A, SHOULD for Class B, MUST for Classes C and D.
• Presumption of Adequacy (CCM-AGM-NAR, MUST NOT): agencies MUST NOT place additional security requirements on providers beyond what FedRAMP specifies. This is statutory (44 USC 3613(e)), and it prevents the pattern of each agency adding their own monitoring requirements on top of FedRAMP.

The common gap on the path to 20x: no single OCR generation process (the report is assembled from scratch each quarter), no automated KSI validation engine (validations are done manually when someone remembers), and no trust center for report distribution (reports are emailed to individual agencies, when trust centers are now mandatory under CDS-CSO-UTC).

In practice, this plays out in our own validation runs. Every KSI is a tracked ticket, every validation check is a child ticket, and every automated run appends dated machine-validation evidence. When an automated compliance check fails, it does not sit in a dashboard. It creates a tracked finding with an owner and an SLA. That is the bridge between “monitoring” and “management.” Detecting a problem and tracking the fix are the same workflow.

The word “persistently” matters. If your ConMon has a seasonal assembly cycle, where someone spends the last week of every month compiling a package, that is periodic monitoring with monthly reporting, not persistent monitoring. 20x expects the monitoring to run persistently and the reporting to summarize what already happened, not to trigger a data collection project.

The pain we lived

Continuous monitoring was a monthly assembly project. For every client. Every month.

The cycle started the same way. Log into the scanner portals, export the results, normalize them, reconcile against last month. Pull the POA&M, update each item’s status. Pull the asset inventory, check for drift. Pull the change log. Pull the access review evidence. Format everything into the ConMon package template. Cross-check for consistency. Make sure the POA&M counts match the scan summary counts. Make sure the asset inventory matches the scan coverage. Find the discrepancies. Fix them. Submit.

We have delivered over 500 ConMon packages this way.

The problem was not any single step. Each step was straightforward. The problem was the volume and the fragility. Across 15+ environments, with different scanners, different ticketing systems, and different reporting templates, the manual assembly process consumed weeks every month. And it was error-prone. Inconsistencies between artifacts, where the POA&M said one thing and the scan report said another, were a constant.

Activities that ran on cadence were tracked in spreadsheets. Weekly log reviews, monthly scans, quarterly access reviews, annual policy reviews. Each environment had its own spreadsheet. There was no single view across environments of what was due, overdue, or complete. When we missed a cadence, we often did not discover it until the next month’s assembly revealed a gap.

The missed cadences compounded. A missed weekly log review is a small gap. Twelve missed weekly log reviews is a pattern. When an assessor asked for evidence of weekly log reviews for the past year, the gaps were visible. Each one was a finding. Findings from missed monitoring activities are the preventable kind. The monitoring tools were deployed. The alerts were being generated. The reviews just did not happen on schedule because nobody was tracking whether they did.

Evidence was another pain point. When a review was completed, the evidence lived in different places: a screenshot in a shared drive, a note in the ticketing system, a comment in a chat channel. Reassembling the evidence for a specific control at assessment time was a scavenger hunt. “Show me evidence for AU-6 for the past 12 months.” That meant finding 52 weekly log review records across multiple tools and formats.

How we automate it

We built the continuous monitoring engine in Stratus GRC-ITSM to turn ConMon from a monthly assembly project into a system that runs itself and produces reports from the work it tracks.

1. Pre-mapped task templates. Every recurring activity is a template: cadence, governing controls or practices, responsible role, required evidence, and SLA. The template library covers the full FedRAMP ConMon cadence across all four frequencies (weekly, monthly, quarterly, annual) plus CMMC-specific activities. Each template maps to the controls or practices it satisfies: AU-6 for log reviews, CA-7 for the ConMon program, CA.L2-3.12.3 for CMMC ongoing monitoring.
2. Automated scheduling. Weekly tasks appear Monday. Monthly vulnerability reporting tasks appear on the 1st. Quarterly access reviews appear at the start of the quarter. Annual policy reviews appear 30 days before the due date. Nobody has to remember what is due. The platform knows.
3. Role-based assignment with coverage. Tasks are assigned to roles, not individuals. When someone is out, coverage applies automatically. Overdue tasks escalate. No task sits in a queue unnoticed.
4. Evidence capture on completion. When a review is completed, the reviewer attaches the evidence directly to the task: review notes, screenshots, attestations, query results. All captured on the ticket. No separate evidence folder that goes stale. No scavenger hunt at assessment time.
5. Control and practice linkage. Each task maps to the controls or practices it satisfies. When an assessor asks “show me evidence for AU-6” or “show me CA.L2-3.12.3,” you hand over completed tasks for the past 12 months, each with the evidence attached and timestamped.
6. Reporting from operational data. Monthly activity reports pull from completed-task and Issue Ticket data. Issue Tickets track every finding internally the way a POA&M did, and the reporting layer renders them as whatever the framework wants: a CMMC POA&M, a FedRAMP accepted-vulnerabilities list, a machine-readable vulnerability report. The change log pulls from change tickets. The access review summary pulls from review tasks. One reporting engine, one data model.
7. 20x KSI validations on the same engine. Each KSI is a ticket. Each validation check is a child ticket. Every automated run appends dated machine-validation evidence to the tree. Most of that evidence is self-generated from operations: access requests, change requests, deviations, remediation SLAs, and incident after-actions all write validation runs as a byproduct of being worked correctly. A scheduled coverage sweep checks the tenant against the FedRAMP vulnerability-evaluation rules, and rollups derive parent statuses from their children so the compliance graph stays consistent. When a check fails, it creates an Issue Ticket automatically: a tracked finding with an owner and a deadline, not a dashboard alert.

graph LR
    SCHED[Scheduling Engine] --> TASKS[Weekly / Monthly / Quarterly / Annual Tasks]
    TASKS --> EV[Evidence Captured]
    EV --> RPT[Monthly Activity Report]
    EV --> OCR[Ongoing Certification Report]
    EV --> ASSESS[Assessment Evidence]

    style SCHED fill:#2b5797,stroke:#5b9bd5,color:#fff
    style TASKS fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style EV fill:#1a5c3d,stroke:#51cf66,color:#fff
    style RPT fill:#5c4a1a,stroke:#ffc857,color:#fff
    style OCR fill:#4a1a5c,stroke:#c77dff,color:#fff
    style ASSESS fill:#1a3d1a,stroke:#a9dc76,color:#fff

The idea: define the task once. The platform handles scheduling, assignment, tracking, evidence, and reporting. One engine produces CMMC ongoing monitoring evidence, Rev5 monthly activity reports, Ongoing Certification Reports under CCM, and 20x KSI validations.

When a CMMC assessor asks for evidence of CA.L2-3.12.3 for the past year, the data is there. When an independent assessor asks for 12 months of monitoring evidence, the data is there. When the annual FedRAMP independent assessment asks about KSI-MLA-RVL and KSI-MLA-EVC, the automated validation runs and their dated evidence are all in the same system.

The monthly report is not a project anymore. It generates from the work that was already done.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]