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

The core concept

System documentation answers one question: does what you wrote down match what you are actually running?

Every framework requires an authoritative statement of your system, controls, and boundaries. CMMC calls it the System Security Plan (SSP). FedRAMP called it that for over a decade. When an assessor compares that statement to the live environment, every inconsistency is a finding. Every generic implementation description that was copy-pasted from guidance instead of describing what you actually do is a gap.

The real question was never whether you have an SSP. Everyone had one. The question is whether your documentation is living data or a Word file that drifts. CMMC prefers structured data. FedRAMP now requires it, for Rev5 and 20x alike: under the Consolidated Rules for 2026, the SSP as a document is gone. The Certification Package replaces it: a Certification Package Overview plus a Security Decision Record (SDR), supplied in mandatory FedRAMP JSON schemas. FedRAMP no longer provides Word or Excel templates at all.

A word about the title of this article. When we published it, OSCAL (Open Security Controls Assessment Language, the NIST standard for structured SSPs, assessment plans, and findings) looked like the format FedRAMP would standardize on, and most of the industry bet accordingly. The final rules went a different way: purpose-built FedRAMP JSON schemas are mandatory, and OSCAL is optional. But the argument this article made is exactly what the final rules landed on: your system definition as components, capabilities, and implemented requirements, in a format machines can validate and humans can read. Structured data over documents. One source rendering every format. Drift prevented by architecture, not discipline.

What CMMC requires

CMMC requires a System Security Plan that describes all 110 Level 2 practices, system boundaries, the operating environment, and relationships with other systems. The SSP has to match the environment.

The relevant practices:

• CA.L2-3.12.4 (Level 2): Develop, document, and periodically update system security plans. POA&M-eligible.
• CA.L2-3.12.1 (Level 2): Periodically assess the effectiveness of security controls. 5-point, not POA&M-eligible. This is the supporting practice. You have to show that you actually review your security posture on a cadence, not just document it once.

Assessment objectives for CA.L2-3.12.4 cover multiple dimensions: the SSP is developed, the boundary is described, the operating environment is documented, non-applicable requirements are identified with justification, implementation methods are described for each practice, interconnections with other systems are documented, update frequency is defined, and updates actually happen on that frequency.

What a C3PAO assessor looks for:

• An SSP that covers all 110 L2 practices with real implementation descriptions
• Accurate boundary and data flow diagrams that match the live environment
• Implementation descriptions that describe what you actually do, not what the control catalog suggests
• Documented interconnections with external systems
• Evidence of regular updates on the defined cadence
• A Customer Responsibility Matrix (CRM) for cloud services

The common gap: SSPs are Word documents that go stale. The SSP gets written during the initial assessment push, maybe updated annually, and drifts in between. When an assessor compares the SSP to the live environment, the inconsistencies become findings. Implementation descriptions read like they came from a template instead of your system. A component was added six months ago, but the boundary diagram still shows the old architecture.

The impact of a stale SSP compounds. The SSP informs the assessment scope. If the SSP does not reflect the current environment, the assessor is working from bad data. Every finding that stems from an inaccurate SSP could have been avoided by keeping the documentation current.

CMMC does not mandate structured formats. But FedRAMP just eliminated document-based packages entirely, and the DoD tends to follow. Building your system definition as structured data now puts you in position for what is coming.

CA.L2-3.12.1 is 5-point and not POA&M-eligible. The control assessment itself, the practice of reviewing whether your controls still work, cannot be deferred. If your last control assessment is more than a year old, that is not a POA&M item. It is a scoring problem.

What FedRAMP Rev5 requires

Rev5 under the Consolidated Rules for 2026 no longer anchors on an SSP document. The Certification Package Overview “replaces the historically required base System Security Plan,” and the Security Decision Record replaces the control implementation body: a persistently maintained, verified, and validated record of the security decisions made by the provider. Both are machine-readable JSON against FedRAMP schemas.

The relevant rules:

• PL-02 (System Security and Privacy Plans): still in every Rev5 class baseline (Classes B, C, and D). The planning control did not go away. The Word document did.
• SDR-CSF-CTF (MUST): for each applicable Rev5 control, the SDR includes short high-level summaries of parameter values, implementation status (Implemented, Partially Implemented, Planned, Alternative Implementation, or Not Applicable), the mechanisms and activities that address the control, verification, and validation.
• CPO-CSF-CPM (MUST): Rev5 Class B and C providers keep the Certification Package up to date at least once every year. Class D, at least once every six months.

Under MAS (Minimum Assessment Scope), which now applies to Rev5 and 20x alike:

• MAS-CSO-IIR (MUST): identify all information resources likely to handle or impact federal customer data
• MAS-CSO-FLO (MUST): document information flows and security objectives for those resources
• MAS-CSO-TPR (MUST): document third-party information resources with usage, justification, and mitigations

These MAS requirements are inventory and documentation requirements. You cannot scope your assessment without first documenting what you are running and how data flows through it. The Certification Package is where that documentation lives.

Under CDS (Certification Data Sharing):

• CDS-CSO-CBF (MUST): use automation to keep human-readable and machine-readable formats consistent
• CDS-CSO-HAD (MUST): supply historical snapshots of Certification Data, aligned to Ongoing Certification Reports, for the duration of certification

CDS-CSO-CBF changes documentation from a document management problem to a data management problem. Maintain your package as prose and also produce the required JSON, and you now have two artifacts to keep in sync by hand. If one source generates both formats, they are consistent by definition, and the rule is satisfied by architecture.

What independent assessors look for: a current Certification Package that matches the live environment, full implementation summaries for every applicable control in the SDR, accurate boundary documentation, and evidence that the package is maintained on its class cadence. They also check that human-readable and machine-readable formats agree.

Common gap: packages that drift quarter by quarter because they are maintained in parallel with the environment, not generated from it. Implementation summaries that read like the control catalog instead of your system. Prose with no machine-readable version behind it. No automation keeping the two formats in sync.

A 300-page SSP was hard to keep current. When a component changed, every section that referenced it had to be updated. In a Word document, that meant searching for every mention and hoping you found them all. In a structured data model, you update the component once and every reference reflects the change. That is the entire reason FedRAMP moved the requirement itself to structured data.

What FedRAMP 20x requires

20x makes machine-readable documentation the primary format, not an optional add-on. The human-readable version is a view of the same data, not a separately written document. The format is not OSCAL. It is FedRAMP’s own JSON schemas.

The relevant rules:

• FRC-CSO-PKG (MUST): the Certification Package includes a Certification Package Overview, a Security Decision Record, and a real or example Ongoing Certification Report.
• FRC-CSO-JSN (MUST): machine-readable information is supplied in JSON documents that are valid against the corresponding FedRAMP JSON schema whenever a rule provides one.
• SDR-CSX-KSI (MUST): the SDR includes short high-level summaries for each applicable Key Security Indicator: the measures in place, their cadence, and verification and validation that they work.
• FRC-CSX-VVK: automated validation of KSIs scales by Certification Class. Class B SHOULD implement at least 1 automated method per KSI. Class C MUST implement at least 2. Class D MUST implement at least 4.

Trust center requirements under CDS:

• CDS-CSO-UTC (MUST): use a FedRAMP-compatible trust center to store and share Certification Data
• CDS-TRC-USH (MUST): uninterrupted sharing
• CDS-TRC-PAC (MUST): documented programmatic access, including to human-readable materials
• CDS-TRC-AAI (MUST): agency access inventory and history
• CDS-TRC-ACL (MUST): access logging, with summaries stored at least six months

Machine-readable is the primary format, and the trust center is the delivery mechanism. Agencies access Certification Data programmatically, with access logging, through a self-service portal. No email distribution. No PDF attachments. FedRAMP no longer acts as an intermediary, and the central repository model is gone by August 2027.

The validation rules are the operational link. Security decisions are not just documented; they are persistently tested by automated methods, and the results feed the SDR. Under VDR-CSO-FAV (MUST), failures in your own detection and response processes are themselves vulnerabilities. Documentation is not a snapshot. It is a living system that tracks its own accuracy.

Common gap on the path to 20x: packages still drafted as prose with no structured data source behind them, no way to emit schema-valid JSON, no trust center, no programmatic access to Certification Data, and no automated validation of security decisions.

If your system definition is a document you update annually, you are not ready for 20x. The destination is a certification that is a live data product.

The pain we lived

SSPs were the artifact everyone dreaded.

We would spend weeks before an assessment updating a Word document that was hundreds of pages long. Every section had to be reviewed against the current environment. Did we add a new component since the last update? Is the boundary diagram still accurate? Did the implementation for this control change when we migrated that service? The answer was usually yes, and finding all the places that needed updating was a manual search-and-replace through a document that nobody wanted to read.

The worst part was the implementation descriptions. In the rush to get through an initial authorization, implementation descriptions got written from guidance templates instead of from the actual system. “The organization employs automated mechanisms to support the management of information system accounts.” That sounds right. It reads well in the SSP. But it does not tell the assessor how you actually manage accounts, what tools you use, what the workflow looks like, or where the evidence lives. When the assessor asks follow-up questions, the people who wrote the description cannot explain it because they copied it from a template.

Interconnections were another persistent issue. Every external system your environment connects to has to be documented: what it is, what data flows between you, what security protections are in place. These change frequently. A new SaaS tool gets added. A vendor API integration is built. An old connection gets decommissioned. The interconnections section of the SSP is the first thing to drift.

Customer Responsibility Matrices were maintained separately from the SSP. The CRM says the customer is responsible for certain controls. The SSP describes how the provider implements its portion. When those two documents are not maintained in sync, the seam between them becomes a finding.

Then the format problem. As the 20x pilots matured, the expectation shifted to machine-readable output alongside human-readable documents. The industry assumed that meant OSCAL. It turned out to mean FedRAMP’s own JSON schemas. Either way, maintaining two versions of the same information by hand guaranteed they would diverge.

Across 15+ environments, this was not a documentation problem. It was a data problem. The information existed in the environment itself: what components were running, how they were configured, what controls they implemented. But that information was disconnected from the document that described it.

How we automate it

Here is how we built structured-data documentation in Stratus GRC-ITSM. The goal: make the system definition the source and every artifact an output.

One design decision matters up front. We studied OSCAL and borrowed its concepts: components, capabilities, implemented requirements, parameters. We did not store OSCAL files. Compliance data is modeled natively as structured, queryable data in the platform, and output formats are renderings. That decision aged well: FedRAMP now mandates its own JSON schemas, OSCAL is optional, and emitting either is a rendering problem instead of a rewrite.

1. System definition as the data model. Capabilities, Components, control implementations, and implementation statements are first-class objects in the platform. Not a bolt-on. Every element of the assessment scope is a Component with its type, description, purpose, provider, and its relationship to federal data or CUI.
2. Library-first content. Components are instantiated from a component library sourced from the FedRAMP Marketplace, so a component’s provider, offering, and FedRAMP ID are truthful and reusable rather than typed from scratch. Implementation statements start from a library of mapped control narratives and get tailored to the system.
3. Component inventory linkage. Every component links to the live asset inventory. The asset record is the operational truth. The component record is the certification truth. They stay linked. When the inventory changes, the component relationship surfaces the change for documentation review.
4. Implementation statements as structured data. Each FedRAMP control, CMMC practice, or KSI maps to the Components and Capabilities that implement it, with a per-component implementation statement and a control-level rollup. This is where the “how we actually do it” lives, tied to specific components, not as a paragraph in a Word document.
5. Idempotent reconciliation. The structure is maintained by reconciliation that diffs the live data model against what should exist and creates only what is missing. Run it any time; it converges the system definition to correct. Nobody hand-assembles 700 control rows, and a half-finished build never stays half-finished.
6. Human-readable rendering per baseline. Documentation renders from the data model, one document per baseline, plus a cross-baseline gap report that works as a QA punch list. Update a component’s implementation statement once, and every document that references it reflects the change. No search-and-replace through a 300-page file.
7. Machine-readable FedRAMP artifacts from the same data. The same live data renders into the FedRAMP JSON report shapes: the System Data Report, significant-change notifications, vulnerability detail and accepted-vulnerability reports, and incident reports. Human-readable and machine-readable formats agree because they are the same rows, which is what CDS-CSO-CBF requires. Trust center report groups serve the customer- and agency-facing views.

graph LR
    CAP[Capabilities] --> SSP[Structured System Definition]
    COMP[Components] --> SSP
    IR[Implemented Requirements] --> SSP
    SSP --> HR[Human-Readable Documentation]
    SSP --> MR[FedRAMP JSON]

    style CAP fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style COMP fill:#2b5797,stroke:#5b9bd5,color:#fff
    style IR fill:#5c4a1a,stroke:#ffc857,color:#fff
    style SSP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style HR fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style MR fill:#5c1a3d,stroke:#ff6b9d,color:#fff

The hardest part is the initial data entry. You have to define your system as structured data: every component, every control mapping, every implementation statement. That is a real upfront investment. There is no shortcut.

The payoff: you never manually assemble a package again. Documentation is always current because it is generated from the same data you use to operate. One data model produces CMMC assessment packages, FedRAMP Rev5 Certification Packages, and the machine-readable JSON artifacts FedRAMP requires.

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