The core concept

Compliance reporting is how you turn operational data into evidence for a specific audience and cadence. Monthly activity reports. Ongoing Certification Reports every 3 months. Annual assessment artifacts. CMMC evidence packages. Machine-readable data feeds.

Every framework wants evidence. The reports differ in format, cadence, and audience. The substance is the same: what is the current state of your vulnerabilities, accepted vulnerabilities, POA&Ms, changes, access reviews, and asset inventory? If your operational data is structured and current, the report is a query. If your data is scattered across five tools, the report is a monthly project.

The quality of every report is capped by the quality of the operational data underneath it. A compliance report cannot be more accurate than the vulnerability management pipeline that feeds it. It cannot cover more assets than the inventory provides. It cannot reflect deviations tracked in a different system. The report is an output. The operations are the input.

This is where the unified data model pays off. In Stratus GRC-ITSM, all findings are Issue Tickets. Deviations are linked to those same Issue Tickets. Changes, access requests, and assets all live in the same system, and every ticket is stamped automatically with the FedRAMP controls, KSIs, FedRAMP Rules, and CMMC mappings scoped to the system’s baselines. When you generate a report, you are querying one data model. You are not aggregating from multiple sources and hoping the data matches.

What CMMC requires

CMMC does not prescribe specific reporting deliverables the way FedRAMP does. There is no monthly activity report requirement. What CMMC wants is organized evidence for every practice, mapped to assessment objectives, that holds up under scrutiny.

Key CMMC deliverables:

• SSP (mandatory for Level 2): describes all 110 practices, boundaries, interconnections, and the operating environment
• POA&M: tracks deficiencies and has to close within 180 days of the assessment finding
• Network diagrams: accurate to the current environment
• Hardware and software inventory: matches what is actually deployed
• Assessment evidence: policies, procedures, screen captures, configuration files, interview notes, test results. Evidence for every practice mapped to the assessment objectives that practice requires.
• Customer Responsibility Matrix: for cloud services, showing the division of responsibility

Scoring: each practice is MET or NOT MET. Point values of 1, 3, or 5. All assessment objectives for a practice have to be MET for the practice to score. A single missing objective sinks the entire practice.

What assessors look for:

• Organized evidence mapped to practices, not a document dump
• Current evidence that reflects the actual state, not screenshots from six months ago
• Consistency between the SSP and actual implementations: the SSP says you do X, the evidence shows you do X
• Coverage across all 110 L2 practices with nothing missing
• People who can speak to the implementations during interviews, because they actually do the work described in the evidence
• POA&M items with real progress, not repeated milestone extensions

The common gap: evidence scattered across five tools. Assessment prep becomes a weeks-long data aggregation project. Someone pulls scan reports from the vulnerability scanner. Someone else pulls change tickets from the ticketing system. Someone else pulls access review logs from the identity provider. The asset inventory comes from a spreadsheet. Then someone stitches it all together into something presentable. The SSP describes what you wish you were doing, not what you are doing.

If your CMMC assessment prep starts 60 days before the audit and eats every senior engineer’s calendar, your operational data is not structured for evidence.

What FedRAMP Rev5 requires

FedRAMP has specific formats, cadences, and audiences. Reporting is prescriptive, and the Consolidated Rules for 2026 (effective July 4, 2026) replaced the reporting stack most Rev5 providers grew up with.

The legacy deliverables were the SSP, SAP, SAR, POA&M, Risk Exposure Table, Customer Responsibility Matrix, monthly vulnerability scan reports, monthly ConMon packages to authorizing officials, and annual assessment artifacts. That model is gone. Rev5 providers now follow the same reporting rules as 20x providers:

• Monthly activity report (VER-TFR-MHR, MUST): human-readable report of vulnerability detection and response activity, at least monthly. This is what replaces the monthly ConMon package.
• Monthly machine verification and validation (VDR-TFR-MVF, Rev5): verify and validate the status of machine-based information resources at least once every month. SHOULD for Class B, MUST for Classes C and D.
• Ongoing Certification Report (CCM-OCR-AVL, MUST): the OCR, every 3 months, in a consistent human-readable format with a published JSON schema. Eight required content areas, including changes to certification data, planned changes for the next 3 months, accepted vulnerabilities, transformative changes, updated recommendations, a list of agencies using the product, FedRAMP Reportable Incidents (or an attestation that none occurred), and lessons learned from those incidents.
• Quarterly Review meeting (CCM-QTR-MTG): a synchronous review of the most recent OCRs, every 3 months. Scales by class: MAY for Class A, SHOULD for Class B, MUST for Classes C and D.
• Certification Data Sharing (CDS, formerly ADS): CDS-CSO-CBF (MUST) requires automation keeping human-readable and machine-readable formats consistent; CDS-CSO-HAD (MUST) requires snapshots of certification data aligned to each OCR, available for the duration of the certification.

The OCR replaces per-agency monthly ConMon packages with a single report shared with all agencies. One report, one cadence, all stakeholders. Instead of twelve monthly packages per year per agency, you produce four OCRs per year shared with everyone, backed by the monthly activity report.

What independent assessors look for:

• Deliverables complete, on time, accurate, and dual-format. Missing a monthly activity report is a finding.
• Consistency across artifacts. The Certification Package Overview says one thing, the Security Decision Record says another, the vulnerability reports say a third. Every inconsistency is a question at best, a finding at worst.
• Evidence that cadenced activities actually ran. If the rules say monthly machine verification and validation, the assessor wants 12 months of monthly evidence.

Common gap: monthly and quarterly deliverables assembled by hand from multiple sources. Five days to assemble the monthly package. Three days to reconcile inconsistencies. Two days for review and formatting. Ten days of work that produces one report that should have been a query. Inconsistencies between artifacts are discovered during assessment, not during assembly. If your monthly reporting takes five days to assemble and three days to reconcile, you are running five tools that should be one.

What FedRAMP 20x requires

20x makes machine-readable the rule, not an emerging trend. The human-readable version is a view of the same data, not a separately written document.

The monthly activity report, the OCR, and the Quarterly Review apply to 20x exactly as they do to Rev5. What 20x adds is speed and structure:

• Faster machine verification and validation (VDR-TFR-MVX, 20x): verify and validate the status of machine-based information resources at least monthly for Class A (SHOULD), every 7 days for Class B (MUST), and every 3 days for Class C (MUST).
• Machine-readable historical activity feed (VER-TFR-MRH): recent vulnerability detection and response activity in JSON, retrievable programmatically, valid against the official FedRAMP schema. MAY for Class A; SHOULD for Classes B, C, and D, updated at least monthly, every 14 days, and every 7 days respectively.
• Certification packages as JSON schemas (FRC-CSO-PKG, MUST): the package is a Certification Package Overview, a Security Decision Record, and a real or example Ongoing Certification Report. Where FedRAMP publishes a JSON schema, the machine-readable version MUST validate against it (FRC-CSO-JSN). OSCAL is optional, not required.
• SCN notifications in human-readable and JSON formats per change type timelines (SCN-CSO-HRM, MUST).

Delivery is through a FedRAMP-compatible trust center (CDS-CSO-UTC, MUST). Reports are published, not emailed. Trust centers MUST provide documented programmatic access to all certification data (CDS-TRC-PAC) and MUST log access (CDS-TRC-ACL).

Presumption of Adequacy (44 USC 3613(e)): agencies MUST NOT place additional security requirements on providers beyond what FedRAMP requires, unless the agency head determines there is a demonstrable need (CCM-AGM-NAR). Under CCM, the reporting set is defined. Agencies receive the same package.

Common gap on the path to 20x: no OCR generation process, no machine-readable reporting capability, no trust center for self-service delivery, and no automated cadence for the required deliverables. In 20x, reports are a product your data emits, not a document you author.

The pain we lived

Compliance reporting was the most time-consuming part of our monthly operations.

Every month, for every client, we assembled a ConMon package by hand. The package: POA&M, Vulnerability Deviation Report, asset inventory, scan summaries, change logs, plus whatever additional evidence the specific authorizing official required. Each component came from a different tool.

Step one: export the vulnerability scan results from the scanner. Format them. Compare against last month’s results to show the delta. Step two: pull the POA&M from whichever spreadsheet or tracker it lived in. Update it with this month’s changes: new findings, closed findings, milestone updates, deviation status. Step three: pull the asset inventory. Verify it matches the scan scope. Step four: pull the change log from the ticketing system. Step five: pull the access review evidence from the identity system. Step six: assemble everything into the ConMon package format.

Then the reconciliation. The POA&M says a finding was remediated. The scan report still shows it open. Is the scan from before or after the remediation? The inventory lists a server the scanner did not cover. Is it a new server or a scan coverage gap? The deviation tracker shows an OR approved. The POA&M still shows the item as overdue. The SSP describes a control one way. The evidence shows a different implementation. Which one is current?

These inconsistencies were not bugs. They were a feature of disconnected tools. When each data source has its own update cadence, its own format, and its own owner, divergence is the default. Reconciliation is the tax you pay every month.

We delivered over 500 ConMon packages this way. The error rate was constant. Not because the team was careless, but because the process made errors inevitable. Copy data between five tools and reconcile by hand, and some reconciliation will be wrong. Some updates will be missed. Some inconsistencies will make it into the final package.

Assessment prep was worse. A ConMon package is one month of data. An assessment package is years of historical evidence: scan results, change records, access review logs, POA&M history, deviation approvals, SSP update evidence, incident response records. Assembling that from disconnected tools was a weeks-long project. Every assessment started with the same question: “where did we put the evidence for Q3 of last year?”

The root cause was the same every time: the data existed but lived in different places. The report was not a query against one data model. It was a monthly integration project across five tools, and the integration was done by humans.

How we automate it

Here is how we built compliance reporting in Stratus GRC-ITSM. The goal: make reports an output of operational data, not a separate production effort.

1. One data model. Vulnerabilities, deviations, changes, access requests, incidents, and assets all live in one platform. All findings are Issue Tickets. Deviations are linked to Issue Tickets. Every ticket carries its FedRAMP control, KSI, FedRAMP Rules, and CMMC attributions automatically, scoped to the system’s baselines. Reports query this data directly. No aggregation from multiple sources. No reconciliation step. The data is already connected.
2. Live reports. Reports are views of current data, not static snapshots assembled from exports. The continuous-monitoring reports are current as of the moment you generate them because they pull from the same tickets and workflows you use daily. No “this report reflects data as of last Tuesday.”
3. Report families per audience. Continuous-monitoring report families cover vulnerabilities, alerts and incidents, access requests, and change requests, each in two variants: an admin view for operators and a customer-scoped portal view, so customers see exactly their own system’s data through the same tested query. Data tables populate automatically from the live data model. Narrative context and analysis are added during the review step, not the assembly step.
4. Human and machine-readable outputs from one source. Human-readable for agency reviewers, independent assessors, and C3PAO assessors. Machine-readable FedRAMP submission artifacts, the System Data Report, significant-change notifications, vulnerability and accepted-vulnerability reports, and incident reports, render from live operational data into the FedRAMP JSON shapes. Both formats come from one data model, which is what CDS-CSO-CBF requires: automation keeping the formats consistent.
5. Trust center delivery. A trust center report group consolidates the customer-facing reports plus dedicated agency-facing FedRAMP report variants, where agencies access certification data on demand. Programmatic access with access logging is what CDS-TRC-PAC and CDS-TRC-ACL require. No email distribution. No per-agency customization.
6. Evidence that generates itself. Operating the system produces the evidence. Closing an access request correctly, remediating an Issue on time, and completing an incident after-action report each generate dated validation evidence automatically. Monthly activity reports and the OCR assemble on schedule from that same data. Nobody has to remember it is reporting week, and nobody collects evidence as a separate task.
7. Assessment evidence packaging for CMMC. Evidence tagged to practices during normal operations assembles into assessment-ready packages. The weeks-long prep cycle collapses to a review cycle. Evidence for CA.L2-3.12.4 (SSP documentation) comes from the same data model that produces the FedRAMP deliverables. Evidence for RA.L2-3.11.2 (vulnerability scanning) comes from the same Issue Tickets that populate the vulnerability reports. When an assessor asks for evidence of a specific practice, the answer is a filtered view of operational data, not a scavenger hunt across five tools. One data model, one set of evidence, multiple output formats.

graph LR
    OPS[Live Operational Data: vulnerabilities, changes, access, inventory] --> RPT[Report Engine]
    RPT --> MHR[Monthly Activity Report]
    RPT --> OCR[Ongoing Certification Report]
    RPT --> MR[Machine-Readable Feeds]

    style OPS fill:#2b5797,stroke:#5b9bd5,color:#fff
    style RPT fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style MHR fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style OCR fill:#5c4a1a,stroke:#ffc857,color:#fff
    style MR fill:#4a1a5c,stroke:#c77dff,color:#fff

If your operational workflows produce structured data, your compliance reports are already written. They are queries with formatting. If your operational data is scattered across tools, your reports are a monthly integration project.

CMMC assessment evidence, FedRAMP monthly and 3-month deliverables, and machine-readable feeds all pull from the same source. The operational data is the evidence. The report is a view of it. No assembly. No reconciliation. No monthly integration project.

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