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

We lived the pain first

Stratus Cyber manages 15+ compliant environments. We have delivered over 500 Continuous Monitoring packages. Here is what that work actually looks like when your tools are disconnected, because it is the reason we built what we built.

Every month, for every client, the cycle starts the same way. Export scan results from multiple scanners. We run different combinations depending on the environment: infrastructure scanners, web application scanners, container scanners, database scanners. Each tool has its own format, its own severity scale, its own way of identifying a finding. Step one is normalizing all of that into a single view. We could not afford a six-figure enterprise vulnerability platform for each client, so we did this by hand.

Then the reconciliation. Compare this month’s results against last month. Which findings are new? Which ones were remediated? Which ones were closed last month but reappeared? Paste the new ones into the POA&M. Update the status on the ones that moved. Cross-reference the deviation tracker to make sure the operational requirements, false positives, and risk adjustments still line up. Find the inconsistencies. Fix them. This takes hours.

Pull the asset inventory from the cloud provider. Compare it against the inventory spreadsheet. Find the resources that were stood up since last month and never added. Find the ones that were decommissioned but still listed. Identify assets that were never scanned. Flag the gaps.

Open change tickets for the remediation work. The tickets exist, but they have no linkage to the POA&M items they are remediating. When a patch window closes out six vulnerabilities, someone has to manually list those six POA&M entries in the change ticket. Approvals happen over email. Three weeks later, nobody can find the approval. It is buried in someone’s inbox.

Now assemble the ConMon package. POA&M, Vulnerability Deviation Report, asset inventory, scan summaries, change log. Format everything. Cross-check for consistency. Submit. Move to the next client. Do it again.

Then the audit happens. An assessor asks you to trace a change back to the POA&M item it remediated. You dig through the ticketing system, the scanner exports, and the email thread where the approval lived. You cannot connect the thread cleanly. That is a finding.

We did this for years. Across 15+ environments. Every month.

And that is just the operational side. We have also built many of these environments from the ground up in AWS, Azure, and M365. We know what it takes to not only run a compliant environment, but to build one and take it through an audit. We know the pain of being the auditee: generating all the evidence, doing the patching, hardening the environment, dealing with configuration drift, patches that break systems, and stitching it all into something an assessor can validate. That full picture is what drove us to build something different.

Three approaches to compliance

That experience forced us to look at how organizations handle compliance alongside security operations. There are three common approaches. Two of them reproduce the pain. The third eliminates it.

graph LR
    A[Bolt-on GRC: 6 disconnected tools] --> AX[No linkage, manual reconciliation]
    B[ITSM plus GRC glue: 2 platforms] --> BX[Sync breaks, data drifts]
    C[GRC-ITSM: one platform] --> CX[One data model, evidence built in]

    style A fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style AX fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style B fill:#5c4a1a,stroke:#ffc857,color:#fff
    style BX fill:#5c4a1a,stroke:#ffc857,color:#fff
    style C fill:#1a3d1a,stroke:#51cf66,color:#fff
    style CX fill:#1a3d1a,stroke:#51cf66,color:#fff

Approach 1: Bolt-on compliance. Start with policies and documentation. Buy a GRC platform that gives you a control catalog, gap assessment, POA&M tracker, and reporting engine. The GRC platform helps you document your compliance posture. It does not help you run the operations. The scans are still in a different tool. The changes are still in a ticketing system. The approvals are still in email. The asset inventory is still a spreadsheet. Now you have six tools instead of five, and one more tab to keep in sync.

Approach 2: ITSM plus GRC glue. Run your operations in Jira or ServiceNow. Track compliance in a separate GRC tool. Build integrations and manual processes to move data between them. This works until it does not. The integration breaks. The data drifts. Someone changes a field name in Jira and the GRC sync stops updating. You spend more time maintaining the glue than doing the work.

Approach 3: GRC-ITSM. A GRC-ITSM does not sit on top of your operations. It is the operations. The ticket is the audit trail. The approval is the evidence. The scan result is the POA&M entry. Relationships between assets, vulnerabilities, tickets, changes, and approvals are built into the data model. Reports generate from the data you produced while doing the actual work. Assignment and notification rules route work to the right people. Single-click approvals are tracked on the ticket. You do not assemble the ConMon package. It generates.

This is the approach we took with Stratus GRC-ITSM. Not because we wanted to build a product. Because we were drowning in the manual work and needed to fix it.

Quick framework orientation

Three frameworks. Same operational expectations. Different wording.

CMMC (Cybersecurity Maturity Model Certification) protects Controlled Unclassified Information in the defense supply chain. Level 2 maps to 110 practices from NIST SP 800-171 Rev 2. Level 2 uses self-assessment or C3PAO certification depending on the contract. Each practice is scored MET or NOT MET with point values of 1, 3, or 5. Some practices are not POA&M-eligible, meaning you cannot defer them. CMMC does not prescribe operational cadences the way FedRAMP does, but assessors expect to see evidence that processes actually run.

FedRAMP Rev5 is the legacy path that certifies cloud services for federal agency use. It is prescriptive: NIST 800-53 control baselines per Certification Class (B, C, and D, the successors to Low, Moderate, and High), defined detection cadences, defined reporting. The old 30/90/180-day SLAs and monthly ConMon packages are being replaced: remediation timeframes now scale by class and potential agency impact, and reporting shifts to a monthly vulnerability activity report plus an Ongoing Certification Report every 3 months. Rev5 is also closing: no new Rev5 Certification applications after June 11, 2027, with existing certifications active until at least December 31, 2028.

FedRAMP 20x is outcome-based and generally available. Instead of prescriptive controls, it defines 46 Key Security Indicators (KSIs) across 10 families. KSIs describe what good looks like and validate it with machine-based and non-machine-based checks. 20x assumes automated pipelines, immutable infrastructure, and continuous validation. It is no longer where FedRAMP is heading. It is where FedRAMP is.

Both FedRAMP types now run under one rulebook: the FedRAMP Consolidated Rules for 2026, announced June 25, 2026 and effective July 4, 2026. “Authorization” is now “Certification” (agency ATOs survive only on the Rev5 Agency path). Low/Moderate/High are gone, replaced by Certification Classes A through D, which measure the assurance supplied to agencies, not the security level: 20x offers Classes A, B, and C today (D comes in 2027); Rev5 offers B, C, and D. Two paths lead to Certification: Program (directly from FedRAMP, the 20x path) and Agency (agency-sponsored, Rev5 only). Adoption is mandatory for all stakeholders on January 1, 2027.

The convergence matters. All three frameworks test the same operations. If you build those operations well, you can demonstrate compliance to any of them from the same data.

The 9 disciplines

Every compliance framework tests the same set of operational capabilities. We call them the 9 disciplines. They are not an exhaustive list of everything you need to do. They are the heavy hitters: the capabilities that consume most of your day-to-day operations and where the pain concentrates when tools are disconnected. The framework determines the wording, the cadence, and the evidence format. The work is the same.

Here is how they map across CMMC, FedRAMP Rev5, and FedRAMP 20x.

Master comparison table

graph TD
    AI[Asset Inventory] --> VM[Vulnerability<br/>Management]
    AI --> UAM[User Access<br/>Management]
    AI --> ChM[Change<br/>Management]
    VM --> DM[Deviation<br/>Management]
    VM --> CM[Continuous<br/>Monitoring]
    UAM --> CM
    ChM --> CM
    IR[Incident<br/>Response] --> CM
    DM --> CR[Compliance<br/>Reporting]
    CM --> CR
    OD[OSCAL-Based<br/>Documentation] --> CR

    style AI fill:#2b5797,stroke:#5b9bd5,color:#fff
    style VM fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style UAM fill:#5c4a1a,stroke:#ffc857,color:#fff
    style ChM fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style DM fill:#4a1a5c,stroke:#c77dff,color:#fff
    style CM fill:#1a5c3d,stroke:#51cf66,color:#fff
    style CR fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style OD fill:#5c4a1a,stroke:#ffd43b,color:#fff
    style IR fill:#5c1a3d,stroke:#ff6b9d,color:#fff

KSIs are the 20x control set; rule IDs like VDR-CSO-DET are FedRAMP Rules and apply to both 20x and Rev5.

Asset inventory feeds everything. Vulnerabilities feed deviations. Changes, access reviews, vulnerability scans, and incident responses all feed continuous monitoring. Continuous monitoring and deviations feed compliance reporting. The disciplines are not independent checkboxes. They are a connected system.

1. Change Management

Change management is how you evaluate, approve, implement, and log every change to production.

The pain we lived: Change tickets existed, but they had no linkage to the POA&M items they were remediating. When a patch window addressed six vulnerabilities, someone manually listed those six entries in the change ticket after the fact. Emergency changes bypassed every control. Approval responses lived in email threads that nobody could find three weeks later.

What we changed: Every change request links to the issues it addresses. Approvals are captured on the ticket with timestamps and the approver’s identity. Security impact analysis is a required field before the change routes for approval. The change record, the approval, and the linked findings are one connected dataset, and every ticket is stamped automatically with the FedRAMP controls, KSIs, FedRAMP Rules, and CMMC practices it touches, scoped to the system’s baselines.

Read the full breakdown on change management

2. User Access Management

User access management is the full lifecycle of an account or permission: request, approval, provisioning, periodic review, and revocation.

The pain we lived: Granting access was easy. Proving the lifecycle was not. Quarterly privileged access reviews were tracked in spreadsheets. When someone left the organization, deprovisioning happened eventually, but the timestamp evidence was scattered across three systems. Approval for access grants lived in email.

What we changed: Access requests are tickets with required justification fields. Reviews are recurring tasks on a cadence that cannot be closed without an explicit confirm or revoke action. Deprovisioning creates a tracked ticket with timestamps. Single-click approvals on the ticket replace email chains.

Read the full breakdown on user access management

3. Vulnerability Management

Vulnerability management is a pipeline: scan, enrich, evaluate, prioritize, remediate, verify, report. Every finding moves through it with an owner and a deadline.

The pain we lived: We ran multiple scanners across environments. Each one produced results in its own format with its own severity ratings. Normalizing findings into a single schema, determining which were new vs remediated vs reopened, and mapping them into POA&M entries consumed days every month.

What we changed: Scan results import into a single schema regardless of source scanner. Each finding becomes an issue with an owner, severity, SLA per framework, and linked assets. New vs remediated vs reopened is determined automatically by comparing against prior scan cycles. The issue is the source record: the same data renders as the CMMC POA&M and as the accepted-vulnerability reporting FedRAMP now requires. No separate mapping step.

Read the full breakdown on vulnerability management

4. Continuous Monitoring

Continuous monitoring is how you verify that security controls still work, on a defined cadence, with evidence.

The pain we lived: ConMon was a monthly assembly project. Pull data from five or six sources. Reconcile it. Format it. Deliver it. For each client. Every month. Activities tracked in spreadsheets with no single view of what was due, overdue, or complete. Missed cadences turned into findings that compounded over time.

What we changed: Every recurring ConMon activity is a scheduled task with a defined cadence, owner, and evidence requirement. Weekly, monthly, quarterly, annual. Tasks auto-generate on cadence. Evidence is captured on completion. For 20x, each KSI is its own ticket, one child per validation check, accumulating dated machine-validation evidence. The reporting package generates from the data produced during the work, not from a manual assembly process.

Read the full breakdown on continuous monitoring

5. OSCAL-Based Documentation

System documentation answers one question: does what you wrote down match what you are actually running? Under the Consolidated Rules the SSP itself is retired, replaced by a Certification Package Overview plus a Security Decision Record, delivered as JSON against FedRAMP’s schemas.

The pain we lived: SSPs were Word documents that went stale the day they were published. When an assessor compared the SSP to the live environment, inconsistencies became findings. Implementation descriptions were copy-pasted from guidance instead of describing what we actually do. Updating the SSP meant searching a 300-page document for every section that referenced a component that changed.

What we changed: Capabilities, components, control implementations, and implementation statements are stored as structured, queryable data, with content sourced library-first from the FedRAMP Marketplace. The SSP is a generated report, not a maintained document. Update a component once and it reflects everywhere it is referenced. The same data generates the human-readable document and the machine-readable JSON the rules now mandate (FRC-CSO-JSN); OSCAL is optional.

Read the full breakdown on OSCAL-based documentation

6. Asset Inventory

Asset inventory answers one question: what is running in our environment, and who owns it?

The pain we lived: Inventory lived in spreadsheets. Cloud resources were stood up and never added. Decommissioned resources stayed listed for months. Vulnerability scanners reported on assets that were not in the inventory. The inventory listed assets the scanners never touched. Every month we reconciled by hand. A stale inventory breaks everything downstream: scan coverage, boundary definition, change tracking, compliance reporting.

What we changed: Assets are the core data object. Everything links to them: issues, changes, scan results, configurations. Discovery from cloud provider APIs feeds inventory directly. Scan coverage is cross-referenced against inventory, and gaps are flagged. An asset record is not a row in a spreadsheet. It is a node that connects to everything else.

Read the full breakdown on asset inventory

7. Deviation Management

Deviation management is how you formally document findings that cannot or will not be remediated on the standard timeline: operational requirements, false positives, and risk adjustments. One update: FedRAMP no longer adjudicates deviation requests. Anything not fully mitigated or remediated within 192 days of evaluation MUST be categorized as an accepted vulnerability (VER-TFR-MAV), rationale reported (VER-RPT-AVI). The internal discipline survives; that rationale has to come from somewhere.

The pain we lived: Deviations were tracked in a spreadsheet separate from the POA&M. Every month, someone reconciled the deviation tracker against the POA&M entries manually. Authorizing official sign-off lived in email. Compensating controls were described in free-text notes with no structured review process. Overdue POA&Ms piled up with repeated extensions.

What we changed: Deviations are attached to the parent finding as structured data, not in a separate tracker. Each deviation type has required fields: justification, compensating controls, evidence. Approval is captured on the deviation record with a single-click approval and a timestamp, and it is always a human decision. Periodic review is enforced by recurring tasks. The deviation and its parent finding are one connected record, which feeds the accepted-vulnerability rationale FedRAMP wants and the POA&M justification CMMC still wants.

Read the full breakdown on deviation management

8. Compliance Reporting

Compliance reporting is how you turn operational data into evidence for a specific audience and cadence.

The pain we lived: Monthly ConMon packages assembled by hand. Evidence scattered across five tools. Assessment prep was a weeks-long data aggregation project. The SSP described what we wished we were doing. Errors and inconsistencies between artifacts: the SSP says one thing, the POA&M says another, the scan report says a third. Every report was a from-scratch assembly, not a generated output.

What we changed: One data model for vulnerabilities, POA&Ms, deviations, changes, access reviews, and assets. Reports are live views of that data. Human-readable and machine-readable versions generate from the same source. Monthly vulnerability activity reports, Ongoing Certification Reports, and assessment evidence pull from live data instead of stitched-together exports, and the same views back the customer- and agency-facing trust center reporting.

Read the full breakdown on compliance reporting

9. Incident Response

Incident response is what happens when something goes wrong: detect, contain, recover, learn.

The pain we lived: The IR plan existed as a PDF. Nobody had tested it recently. The notification chain referenced people who had changed roles. When something happened, the first 30 minutes were spent figuring out who to call and what to do. After-action reviews happened informally and the lessons did not feed back into the program. The FedRAMP Security Inbox did not exist as a monitored, tracked process.

What we changed: Incidents from SIEM, EDR, ITDR, and other detection tools all flow into one system as actionable tickets with required fields: type, severity, affected systems, initial assessment. We also track monitoring alerts (uptime, disk space, etc.) so no matter what monitoring tools you run, the alerts land where they can be actioned. Notification chains are defined in the system and triggered automatically on ticket creation. We defined the full incident lifecycle, initial incident report (IIR), ongoing incident report (OIR), final incident report (FIR), and after-action report (AAR), directly into Incident tickets: the platform tracks the due dates of each step automatically and self-generates validation evidence of the process. Annual tabletop exercises are recurring tasks with attendance and findings captured. The FedRAMP Security Inbox routes to tracked tickets with SLA-based response timeframes.

Read the full breakdown on incident response

The capability standards

What FedRAMP piloted as “Rev5 Balance” is final rule now, folded into the Consolidated Rules for 2026 and applying to both 20x and Rev5. These five standards are not stepping stones anymore. They are the rules.

Minimum Assessment Scope (MAS) narrows the assessment boundary to information resources that are likely to handle federal customer data or affect its confidentiality, integrity, or availability (MAS-CSO-IIR). Tighter scope, less noise, faster assessments.

Significant Change Notification (SCN) replaces advance government approval of changes with a notification model. Three categories with hard windows: routine recurring changes are exempt, adaptive changes require notification within 10 business days after finishing, and transformative changes require initial plans at least 30 business days before starting, final plans at least 10 business days before, and notices within 5 business days after finishing and after verification. Emergency changes may proceed with retroactive materials; advance approval survives only as a corrective-action condition.

Certification Data Sharing (CDS), formerly Authorization Data Sharing (ADS), replaces static PDF packages with live, programmatically accessible data served through a FedRAMP-compatible trust center (CDS-CSO-UTC, a MUST). Human-readable and machine-readable, kept in sync automatically.

Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER), the pilot VDR standard split in two, replace CVSS-only severity with contextual evaluation: exploitability, internet reachability, and Potential Agency Impact N-rating (PAIN, N1 through N5) drive mitigation and remediation timeframes that scale by Certification Class. Any vulnerability not fully mitigated or remediated within 192 days of evaluation MUST be categorized as an accepted vulnerability (VER-TFR-MAV). Both standards are mandated by CISA BOD 26-04, with a December 7, 2026 deadline.

Collaborative Continuous Monitoring (CCM) replaces per-agency monthly ConMon packages with an Ongoing Certification Report every 3 months (CCM-OCR-AVL) shared with all agencies at once, plus Quarterly Review meetings. One report, one cadence, all stakeholders.

Each standard has its own deep-dive article:

• Minimum Assessment Scope: what MAS requires and how to automate it
• Significant Change Notifications: what SCN requires and how to automate it
• Certification Data Sharing: what CDS requires and how to automate it (formerly ADS)
• Vulnerability Detection and Response: what VDR requires and how to automate it
• Collaborative Continuous Monitoring: what CCM requires and how to automate it

The automation thesis

Here is the core idea behind everything we have built.

One platform. One data model. Three frameworks.

Assets, issues, changes, approvals, deviations, scans, and reports all live in the same system. The relationships between them are not maintained manually. They are the data model.

One detail that makes this work: we treat all vulnerabilities, misconfigurations, and assessment findings as Issue Tickets. An Issue Ticket is the source of truth. It becomes a POA&M entry when it meets the criteria for being one (it came from an assessment, it is overdue, etc.), but the POA&M is still the same Issue Ticket with the field “IS POA&M” set to Yes. There is no separate POA&M object. FedRAMP now wants accepted-vulnerability reporting instead of a POA&M; the same Issue data produces that too. The data model stays unified. When you close a change ticket that remediated a vulnerability, the linked Issue updates. When you approve a user access review, the approval is timestamped on the ticket. When a compliance check fails, an Issue Ticket is created automatically.

graph LR
    A[Asset] --> S[Scan Result] --> I[Issue / Finding]
    I --> D[Deviation] --> P[POA&M Entry]
    I --> P
    P --> CT[Change Ticket] --> AP[Approval] --> CR[Compliance Report]

    style A fill:#2b5797,stroke:#5b9bd5,color:#fff
    style S fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style I fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style D fill:#4a1a5c,stroke:#c77dff,color:#fff
    style P fill:#5c4a1a,stroke:#ffc857,color:#fff
    style CT fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style AP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style CR fill:#1a3d1a,stroke:#a9dc76,color:#fff

A scan produces a finding. The finding links to a POA&M entry. The POA&M links to a change ticket. The change ticket carries an approval. The approval feeds the compliance report. If the finding cannot be remediated, a deviation attaches to it and the reporting reflects that status automatically. Every node in this graph is a record in the same system.

The workflow is the evidence. You do not produce evidence separately from doing the work. The work produces the evidence. Reporting packages, assessment artifacts, and Ongoing Certification Reports generate from the data created during operations, not from a separate reporting project.

The AI-assisted side of the platform runs the same process we train humans on: know your system, document your system, operate your system. Same steps, faster. The approval gates stay human by design: access requests, deviations, changes, and after-action reports are never auto-approved; a person makes each call, and the decision is captured on the ticket.

The payoff is validation evidence you never have to collect. Access requests, change requests, deviations, remediation SLAs, and incident after-actions each self-generate dated validation evidence for the KSIs they support. Remediating an Issue on time is not just hygiene; it is the machine-readable proof the frameworks want. The same live data generates the FedRAMP 20x submission artifacts, the System Data Report, significant-change, vulnerability, and incident reports, in the JSON formats FedRAMP requires.

CMMC, FedRAMP Rev5, and FedRAMP 20x test the same 9 disciplines. The differences are in wording, cadence, and evidence format. If your operations run on structured data with relationships built in, you can demonstrate compliance to any of them.

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

Where to go next

Each discipline and each capability standard has a dedicated deep-dive article. The series covers CMMC, FedRAMP Rev5, and FedRAMP 20x requirements side by side, with implementation detail from our experience.

The 9 disciplines:

1. Change Management across CMMC, Rev5, and 20x
2. User Access Management across CMMC, Rev5, and 20x
3. Vulnerability Management across CMMC, Rev5, and 20x
4. Continuous Monitoring across CMMC, Rev5, and 20x
5. OSCAL-Based Documentation across CMMC, Rev5, and 20x
6. Asset Inventory across CMMC, Rev5, and 20x
7. Deviation Management across CMMC, Rev5, and 20x
8. Compliance Reporting across CMMC, Rev5, and 20x
9. Incident Response across CMMC, Rev5, and 20x

The capability standards:

10. Minimum Assessment Scope (MAS)
11. Significant Change Notifications (SCN)
12. Certification Data Sharing (CDS, formerly ADS)
13. Vulnerability Detection and Response (VDR)
14. Collaborative Continuous Monitoring (CCM)

FAQ

Have questions about any of this? Reach out.