Collaborative Continuous Monitoring: What CCM Requires and How to Automate It

What it is

Collaborative Continuous Monitoring (CCM) replaces per-agency monthly ConMon packages with quarterly Ongoing Authorization Reports shared with all agencies 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 quarterly reporting. The provider produces an Ongoing Authorization Report (OAR) every quarter. All agencies access it at the same time, through the same trust center (as defined by ADS). Questions come through an asynchronous feedback mechanism. Answers are visible to all agencies. The feedback loop is transparent and shared.

Status: optional open beta since February 2, 2026 (beta ends May 22, 2026). FedRAMP recommends adopting VDR and SCN alongside CCM, as the OAR content draws from both.

The relevant KSI: KSI-AFR-CCM.

Connection to 20x: CCM is the default continuous monitoring process for 20x. Organizations on Rev5 that adopt CCM now reduce their 20x migration scope and get the reporting burden reduction immediately.

What it requires

CCM has requirements for the OAR 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.

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

The OAR must include:

• Changes to authorization data since the last OAR. What was updated in the SSP, the POA&M, the boundary, the control implementations? This connects directly to SCN: changes that were notified under SCN are summarized here.
• Planned changes for 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 VDR-TFR-MAV. Findings that crossed the 192-day threshold and were classified as accepted vulnerabilities appear in the OAR with the required documentation.
• Transformative changes. Changes categorized as transformative under SCN are called out in the OAR. This gives agencies visibility into architectural changes without requiring them to monitor SCN notifications in real time.
• Updated recommendations or best practices. Security improvements the provider is recommending or implementing, lessons learned, and operational maturity updates.

The OAR is not a from-scratch document. It is an aggregation of data from VDR (vulnerabilities and accepted vulnerabilities), SCN (changes and transformative changes), inventory (component changes), and the issue tracker (recommendations and security improvements). If those data sources are structured and current, the OAR assembles from them.

Additional OAR MUST requirements

CCM-OAR-NRD: Publicly share the target date for the next OAR. Agencies should know when to expect the next report. This is a publicly visible date on the trust center, not an internal scheduling note. When the OAR is published, the next publication date is already visible.

CCM-OAR-FBM: Establish an asynchronous feedback mechanism. Agencies submit questions and comments through a defined channel. You respond. The mechanism is documented and accessible through the trust center. 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-OAR-AFS: Keep an anonymized feedback summary as an addendum to the OAR. Agency questions and the provider’s responses, with agency identity removed, become part of the OAR record. Other agencies benefit from seeing the Q&A without knowing which agency asked. 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.

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

Quarterly Review meeting

CCM-QTR-MTG: MUST for Moderate and High impact systems, SHOULD for Low. Recommended 3-10 business days after OAR release. The timing matters. Agencies should have time to read the OAR before the meeting, but the meeting should happen soon enough that the OAR content is still current.

CCM-QTR-REG: Registration link required. Agencies sign up to attend. This is both a planning mechanism and an access control. The provider knows who is attending and can prepare accordingly.

CCM-QTR-RTR: Should be recorded and transcribed. The recording and transcript become part of the record. 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.

The quarterly review is open to all necessary parties. It is a live walkthrough of the OAR, 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 OAR. This is not optional. If an agency is consuming a provider’s service, it is responsible for reviewing the quarterly OAR. The review is part of the agency’s own continuous monitoring obligations.

CCM-AGM-NAR (MUST NOT): Agencies must not add requirements beyond FedRAMP. This is the Presumption of Adequacy provision, grounded in 44 USC SS 3613(e). If FedRAMP says the provider’s monitoring is adequate, agencies cannot pile on additional requirements unless the agency head determines there is a demonstrable need. 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-NFR (MUST): Agencies must notify FedRAMP of significant concerns. If an agency has a concern about a provider’s security posture, the path is through FedRAMP, not directly to the provider as an ad-hoc demand. FedRAMP evaluates the concern and takes action if warranted. This channels agency oversight through a single authority rather than allowing N agencies to independently impose requirements.

The combination of CCM-AGM-NAR and CCM-AGM-NFR 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. Concerns go through FedRAMP. The provider deals with one set of requirements, not N sets.

graph LR
    VDR[VDR Data] --> OAR[OAR Assembly]
    SCN[SCN Logs] --> OAR
    INV[Inventory Changes] --> OAR
    REC[Recommendations] --> OAR
    OAR --> VAL[Completeness Validation]
    VAL --> TC[Trust Center Publication]
    TC --> QR[Quarterly Review Meeting]
    QR --> FB[Agency Feedback]
    FB --> ANON[Anonymized Summary]
    ANON --> OAR
 
    style VDR fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style SCN fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style INV fill:#2b5797,stroke:#5b9bd5,color:#fff
    style REC fill:#5c4a1a,stroke:#ffc857,color:#fff
    style OAR fill:#1a5c3d,stroke:#51cf66,color:#fff
    style VAL fill:#4a1a5c,stroke:#c77dff,color:#fff
    style TC fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style QR fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style FB fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style ANON fill:#5c4a1a,stroke:#ffc857,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 monthly per-agency ConMon to quarterly one-to-many OARs cuts reporting effort. Instead of producing the same data twelve times a year and distributing it to each agency independently, you produce one OAR every quarter and publish it to the trust center. The OAR is more thorough than a typical monthly ConMon package (it includes accepted vulnerabilities, planned changes, and recommendations), but you produce it once. 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 OAR 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 OARs 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. Significant concerns go through FedRAMP (CCM-AGM-NFR), not directly to the provider as ad-hoc demands.

The OAR as the capstone. The OAR feeds the broader Rev5 Balance ecosystem. Accepted vulnerabilities come from VDR. Transformative changes come from SCN. Inventory data comes from MAS. Authorization data is served through ADS. CCM is the reporting capstone. It assembles data from the other four improvements into one quarterly deliverable. This is why FedRAMP recommends adopting VDR and SCN alongside CCM: the OAR content depends on structured data from both.

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, Vulnerability 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 VDR. The VDR 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 OAR needs to be thorough enough that agencies do not need to ask follow-up questions. The automation problem is assembling the OAR from live operational data, not re-writing it every quarter. Here is how we built it in Stratus GRC-ITSM.

1. OAR auto-assembly from operational data. The Ongoing Authorization Report is generated from live sources: the VDR pipeline (accepted vulnerabilities, remediation status, vulnerability trends), the SCN workflow (changes completed and planned, transformative changes), the inventory (component changes, boundary updates), and the issue tracker (security recommendations, improvement items). Not drafted from scratch. The OAR is a report assembled from the data produced by other operational workflows. If the source data is structured, the OAR sections populate automatically.
2. Content completeness validation. A checklist auto-validates that every CCM-OAR-AVL required section is populated before publication. Missing data is flagged before the OAR goes out, not discovered by an agency reviewer. If the accepted vulnerabilities section is empty because the VDR data did not sync, the validation catches it. If the planned changes section is blank because nobody entered the next quarter’s roadmap, the validation flags it. The OAR does not publish with incomplete sections.
3. Next OAR date publication. CCM-OAR-NRD is met automatically by publishing the next target date to the trust center based on the ConMon cadence. When the current OAR is published, the next publication date is visible immediately. No manual updates to a “next report” field.
4. Trust center delivery. OARs are published through the same trust center agencies already use for ADS. All agencies access at once, with access logging per ADS-TRC-ACL. No per-agency uploads. No email distribution. Publish once. The trust center handles access control, logging, and distribution.
5. Asynchronous feedback mechanism. CCM-OAR-FBM is integrated into the trust center portal. Agency questions become tracked tickets. Responses are captured and linked to the OAR. The feedback loop is structured, not email-based. Questions have a submission date, a response date, and a linkage to the OAR section they reference. All agencies can see the questions and responses (anonymized).
6. Anonymized feedback summary. CCM-OAR-AFS is auto-generated from the feedback tickets as an addendum to the OAR. Agency identity is stripped. The questions, context, and responses are preserved. No manual anonymization pass. The summary is generated automatically from the structured feedback data. Future OARs include the cumulative feedback history so new agencies can see the full Q&A context.
7. Quarterly review scheduling. Meeting dates are published in the trust center. Registration links (CCM-QTR-REG) are auto-generated. Calendar invites go out to registered attendees. Recording and transcription (CCM-QTR-RTR) are integrated with the meeting platform. Post-meeting, the recording and transcript are linked to the OAR in the trust center.
8. OAR release cadence management. CCM-OAR-SOR recommends spreading OAR releases across the quarter, not clustering them in the first or last week. When managing multiple environments, the scheduling engine staggers OAR publication dates so agencies and FedRAMP do not receive a flood of OARs in the same week. Each environment’s OAR publishes on its scheduled date, spread across the quarter.

The principle: CCM is the reporting capstone. If VDR, SCN, inventory, and issue data are already structured in one platform, the OAR assembles itself. The assembly is automated. The completeness is validated. The distribution goes through the trust center. The feedback is tracked and anonymized. The quarterly review is scheduled and recorded. The OAR is a report generated from operational data, not a document authored from scratch.

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