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

What it is

Collaborative Continuous Monitoring (CCM) replaces per-agency monitoring packages with shared reporting that all agencies consume at once. Providers report once. Agencies consume collaboratively. Presumption of Adequacy keeps agencies from piling on requirements beyond FedRAMP.

FedRAMP is tired of agencies making the same requests independently. CCM is the fix.

Under the traditional model, providers produced monthly ConMon packages and delivered them to each agency independently. The same data, reformatted for each agency’s preferences, delivered on each agency’s schedule. An agency with specific questions asked the provider directly. Another agency asked the same question separately. The provider answered both, independently. The reporting burden scaled linearly with the number of consuming agencies. A provider with ten consuming agencies produced the same information ten times in slightly different formats.

CCM replaces this with one-to-many reporting. The centerpiece is the Ongoing Certification Report (OCR), which providers MUST supply to all necessary parties every 3 months. If you followed the pilot, this is the artifact you knew as the OAR; the Consolidated Rules for 2026 renamed it along with the program-wide shift from authorization to Certification. All agencies access the OCR at the same time, through the same trust center (as defined by CDS). Questions come through an asynchronous feedback mechanism. Answers are visible to all agencies. The feedback loop is transparent and shared.

Status: CCM is a final rule set in the FedRAMP Consolidated Rules for 2026 (released June 25, 2026, effective July 4, 2026). It applies to both 20x and Rev5 Certifications at Classes B, C, and D. 20x providers follow it now; Rev5 providers must obtain it by January 1, 2027, with a grace period ending October 1, 2027.

One framing correction from the pilot era: CCM does not make everything quarterly. Vulnerability reporting still runs monthly under VER: a human-readable activity report at least monthly (VER-TFR-MHR, MUST) plus a machine-readable historical activity feed on a class-based cadence (VER-TFR-MRH). CCM sits on top of that: the OCR every 3 months and a synchronous Quarterly Review meeting, both shared with all agencies at once rather than delivered per agency. What changed is the audience model, not the operational tempo.

What it requires

CCM has requirements for the OCR itself, the Quarterly Review meeting, and agency behavior. The agency-side requirements are as significant as the provider-side requirements, because CCM changes the rules of engagement for agency oversight.

OCR requirements (CCM-OCR-AVL, MUST, every 3 months)

Providers MUST supply an OCR every 3 months, covering the entire period since the previous summary, in a consistent human-readable format. FedRAMP also publishes an official JSON schema for the report. Eight content areas are required:

• Changes to FedRAMP Certification Data since the last OCR. What changed in the certification package, the boundary, the control implementations? This connects directly to SCN: changes that were notified under SCN are summarized here.
• Planned changes for at least the next 3 months. Not a commitment. A forecast. Agencies should know what is coming so they can plan their own review activities. Transformative changes planned for the next quarter should appear here.
• Accepted vulnerabilities. This connects directly to VER-TFR-MAV. Findings that crossed the 192-day threshold and were categorized as accepted vulnerabilities appear in the OCR with the required documentation.
• Transformative changes. Changes categorized as transformative under SCN are called out in the OCR. This gives agencies visibility into architectural changes without requiring them to monitor SCN notifications in real time.
• Updated recommendations or best practices for security, configuration, or usage of the offering. Security improvements the provider is recommending or implementing, lessons learned, and operational maturity updates.
• A list of all agencies directly using the product. Every agency can see who else is consuming the service.
• FedRAMP Reportable Incidents, or an attestation that no such incidents occurred.
• Lessons learned and changes planned or made as a result of any FedRAMP Reportable Incidents.

The OCR is not a from-scratch document. It is an aggregation of data from VER (accepted vulnerabilities and vulnerability reporting), SCN (changes and transformative changes), inventory (component changes), incident records (Reportable Incidents and after-action lessons), and the issue tracker (recommendations and security improvements). If those data sources are structured and current, the OCR assembles from them.

Additional OCR requirements

CCM-OCR-NRD (MUST): Supply the target date for the next OCR with other public FedRAMP Certification Data. Agencies should know when to expect the next report. This is a publicly visible date, not an internal scheduling note. When the OCR is published, the next publication date is already visible.

CCM-OCR-FBM (MUST): Establish an asynchronous feedback mechanism. Agencies submit questions and comments through a defined channel. You respond. FedRAMP notes email is acceptable by default but encourages something more interactive. This replaces the ad-hoc email Q&A model: questions are structured, tracked, and answered in a way that is visible to all parties.

CCM-OCR-AFS (MUST): Supply an anonymized and desensitized summary of the feedback, questions, and answers, either as an addendum to the OCR or in the next OCR. Agency questions and the provider’s responses, with agency identity removed, become part of the record. This is an efficiency mechanism: if Agency A asks a question in Q1 and Agency B has the same question in Q2, the answer is already in the anonymized summary. FedRAMP notes it is generally in the provider’s interest to update this addendum throughout the quarter.

CCM-OCR-LSI (MUST NOT): Do not irresponsibly disclose sensitive information in the OCR. The report shares posture data, not exploitation details. The same CDS-CSO-RIS principle applies: share enough for agencies to assess risk, do not share information that enables exploitation.

CCM-OCR-SOR (SHOULD): Establish a regular 3-month cycle spread out from the beginning, middle, or end of each quarter, so agencies are not flooded with every provider’s report in the same week.

Quarterly Review meeting

CCM-QTR-MTG: Host a synchronous Quarterly Review every 3 months, open to all necessary parties, covering the parts of the most recent OCR most relevant to agencies. The force scales with Certification Class: MAY for Class A, SHOULD for Class B, MUST for Classes C and D.

CCM-QTR-SAR (SHOULD): Schedule the review at least 3 business days after releasing the OCR and within 10 business days of release. The timing matters. Agencies should have time to read the OCR before the meeting, but the meeting should happen soon enough that the content is still current.

CCM-QTR-REG (MUST): Supply a registration link or a downloadable calendar file with meeting information. This is both a planning mechanism and an access control. The provider knows who is attending and can prepare accordingly.

CCM-QTR-NRD (MUST): Publicly supply the target date for the next Quarterly Review, alongside the next OCR date.

CCM-QTR-RTR (SHOULD): Record or transcribe the review and supply it to all necessary parties. Agencies that could not attend can review the recording. The transcript is searchable. Over time, the Quarterly Review recordings become a knowledge base of the provider’s security posture evolution.

CCM-QTR-RTP (SHOULD NOT): Do not invite third parties without specific relevance; agencies participate less freely with outsiders in the room. Your independent assessor is considered relevant by default.

The Quarterly Review is a live walkthrough of the OCR, followed by discussion. Not a per-agency briefing. One meeting, all agencies, open Q&A. Under the traditional model, each agency had its own relationship with the provider and its own briefing cadence.

Agency requirements

The agency-side requirements are as important as the provider-side requirements.

CCM-AGM-ROR (MUST): Agencies must review each OCR to understand how changes to the offering may impact the risk tolerance documented in their own Authorization to Operate of the federal information system that includes the offering. This is not optional. The review is part of the agency’s own continuous monitoring obligations.

CCM-AGM-NAR (MUST NOT): Agencies must not place additional security requirements on providers beyond those required by FedRAMP. This is the Presumption of Adequacy provision, a statutory requirement in 44 USC § 3613(e). The only exception: the head of the agency or an authorized delegate determines there is a demonstrable need. Seeking clarification or asking general questions about FedRAMP Certification Data is fine. No custom ConMon formats. No additional reporting cadences. No ad-hoc security briefings beyond the Quarterly Review. This protects providers from the cumulative burden of per-agency demands.

CCM-AGM-NFA (MUST): Agencies must notify FedRAMP after requesting any additional information or materials from a provider beyond what FedRAMP requires. This is required by OMB M-24-15. Every extra ask is visible to FedRAMP, which makes the Presumption of Adequacy enforceable rather than aspirational.

The combination of CCM-AGM-NAR and CCM-AGM-NFA changes the oversight model. Under the old model, each agency could add its own requirements, and the provider had to comply with all of them. Under CCM, FedRAMP sets the standard. Agencies consume what FedRAMP requires, and any request beyond that is reported to FedRAMP. The provider deals with one set of requirements, not N sets.

graph LR
    DATA[Vulnerability, change, incident, and inventory data] --> OCR[Ongoing Certification Report]
    OCR --> TC[Trust Center Publication]
    TC --> QR[Quarterly Review]
    QR -->|agency feedback| OCR

    style DATA fill:#2b5797,stroke:#5b9bd5,color:#fff
    style OCR fill:#1a5c3d,stroke:#51cf66,color:#fff
    style TC fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style QR fill:#5c1a3d,stroke:#ff6b9d,color:#fff

Why it matters

CCM addresses two problems at once: the provider reporting burden and the agency visibility gap.

For providers: The shift from per-agency delivery to publish-once reporting cuts effort. The monthly activity report and the machine-readable feed publish to the trust center once, for everyone. The OCR is more thorough than a typical monthly ConMon package (it includes accepted vulnerabilities, planned changes, incidents, and recommendations), but you produce it once every 3 months and every consuming agency reads the same document. For a provider with multiple consuming agencies, the savings compound. No more per-agency formatting. No more per-agency distribution. No more per-agency Q&A sessions covering the same ground.

For agencies: Agencies get better data, more consistently, with less effort. The OCR is standardized. The trust center provides access on demand. The feedback mechanism gives agencies a channel to ask questions, and the anonymized summary means every agency benefits from every question asked. The Quarterly Review provides a live discussion forum where agencies hear each other’s questions and the provider’s answers. An agency that is new to consuming a provider’s service can review the last several OCRs and the associated feedback summaries to get up to speed.

Presumption of Adequacy changes the dynamic. Under the old model, agencies could layer on additional monitoring requirements. One agency wanted weekly vulnerability reports. Another wanted custom POA&M formats. A third wanted ad-hoc security briefings. A fourth wanted monthly calls. Each agency’s demands were reasonable in isolation, but the aggregate burden on the provider was not. The provider spent more time on reporting variations than on security improvements. CCM-AGM-NAR (MUST NOT) prevents this. FedRAMP sets the monitoring standard. Agencies consume what FedRAMP requires, and any request beyond it triggers a notification to FedRAMP under CCM-AGM-NFA.

The OCR as the capstone. The OCR assembles data from the other capability standards in the Consolidated Rules. Accepted vulnerabilities come from VER. Transformative changes come from SCN. Inventory data comes from the boundary defined under MAS. The report itself is FedRAMP Certification Data, served through the trust center under CDS. CCM is the reporting capstone: it turns the output of the other standards into one quarterly deliverable. If your VDR/VER, SCN, and inventory data is structured, the OCR is an assembly job, not an authoring job.

The pain we lived

Monthly ConMon delivery was one of our heaviest operational burdens. The pain was not in the data. The data existed. The pain was in the assembly, formatting, distribution, and repetition.

Every month, for every client, for every consuming agency, we assembled a ConMon package. POA&M, deviation report, asset inventory, scan summaries, change log. The data came from multiple sources. Each piece had to be extracted, reconciled, cross-checked, and formatted. The POA&M had to match the deviation report. The deviation report had to match the scan results. The asset inventory had to match the boundary. Finding inconsistencies was a monthly exercise.

The formatting varied by agency. One agency wanted the POA&M in their template. Another wanted a specific report format for vulnerabilities with additional columns. A third wanted the data in a specific order that no other agency used. We maintained multiple templates per client and mapped the same data into each one. The data was identical. The presentation was different.

Delivering took time. Upload to USDA Connect. Email the agency POC. Confirm receipt. Follow up if they did not acknowledge. For clients with multiple consuming agencies, the delivery process alone took hours each month. Some agencies wanted packages by email. Some checked USDA Connect on their own. Some only looked at it when they had a specific question. The distribution mechanism was inconsistent.

Agency questions came in independently. “What is the status of POA&M item 47?” from Agency A on Tuesday. The same question from Agency B on Thursday. We answered both. Separately. The answers were identical, but the effort was doubled. Sometimes tripled. Each agency had its own communication channel with us, and none of them saw each other’s questions or our answers.

When an agency wanted something beyond the standard ConMon package, we did it. There was no mechanism to push back. If an agency wanted weekly vulnerability snapshots, we provided them. If they wanted a custom report format, we built it. If they wanted monthly calls to walk through the POA&M, we scheduled them. The aggregate burden of custom requirements across multiple agencies consumed time that could have gone toward actual security improvements. We were spending more effort on reporting variations than on remediating findings.

The annual assessment added another layer. The assessment package overlapped with ConMon data but was formatted differently. Assembling the assessment evidence package involved pulling much of the same data we delivered monthly, repackaging it for the assessor’s needs, and cross-referencing to make sure the assessment package was consistent with the last 12 months of ConMon deliverables.

The same data, produced and delivered multiple times in multiple formats to multiple consumers. The reporting burden scaled with the number of agencies, not the complexity of the security posture. CCM addresses this directly.

How we automate it

CCM reduces the reporting burden while raising the bar on quality. The OCR needs to be thorough enough that agencies do not need to ask follow-up questions. The automation problem is assembling the OCR from live operational data, not re-writing it every quarter. Here is how we built it in Stratus GRC-ITSM.

1. Continuous-monitoring reports generated from live operational data. The report families that feed the OCR (issues and remediation status, alerts and incidents, access requests, change requests) are queries against operational data, not documents. Each family exists in an admin variant and a customer-scoped variant built from the same tested query, so a customer or agency sees exactly their own system’s data. Nothing is assembled by hand at month-end or quarter-end; the reports reflect the current state whenever they run.
2. A trust center report group for agency self-service. The customer- and agency-facing reports are consolidated into a trust center report group. Agencies pull current posture data on demand instead of waiting for a package. Publishing once through the trust center replaces per-agency uploads and email distribution, with access scoped so each consumer sees exactly their own system’s data. Access logging (CDS-TRC-ACL) is part of what makes a trust center FedRAMP-compatible, so pick a delivery layer that records who read what.
3. OCR content as queries, not authoring. Each of the eight CCM-OCR-AVL content areas maps to structured data the platform already holds: accepted vulnerabilities from the vulnerability and deviation workflow (per VER-TFR-MAV), transformative and planned changes from the change workflow, incident summaries and lessons learned from incident tickets and after-action reports, recommendations from security-improvement items. Quarterly reporting becomes a query over data that already exists, not a quarter-end scramble to reconstruct what happened.
4. Validation evidence accumulates from operations. KSI tracking runs as a ticket tree, one ticket per KSI per validation check, and the evidence rows are generated automatically from operations: access requests, change requests, deviations, remediation SLA outcomes, incident after-actions. By the time an OCR is due, the dated evidence for the covered period already exists. Closing tickets correctly is what produces the proof.
5. Machine-readable reporting from the same data. The machine-readable submission artifacts FedRAMP wants (the System Data Report, significant-change notifications, vulnerability and accepted-vulnerability reports, incident reports) are generated from the same operational data that runs the help desk. The human-readable OCR and the machine-readable feeds draw from one source, so they cannot drift apart. Consistency between formats is a CDS requirement (CDS-CSO-CBF); one source of truth is how you meet it without a reconciliation exercise.
6. Feedback as structured records. Agency questions under CCM-OCR-FBM are tracked as tickets like everything else: a submission date, a response, a link to the report they reference. The anonymized feedback summary (CCM-OCR-AFS) is assembled from that structured record, not reconstructed from an inbox at the end of the quarter.

The principle: CCM is the reporting capstone. If vulnerability, change, inventory, incident, and access data are already structured in one platform, the OCR assembles itself, the trust center distributes it, and the machine-readable feeds stay consistent with the human-readable report because both are views of the same data.

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.]