OSCAL-Based Documentation Across CMMC, FedRAMP Rev5, and FedRAMP 20x

The core concept

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

Every framework requires a System Security Plan (SSP) that describes your system, controls, and boundaries. The SSP is the authoritative statement of how your environment works. When an assessor compares the SSP 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 is not whether you have an SSP. Everyone has one. The question is whether your documentation is living data or a Word file that drifts. CMMC prefers structured data. FedRAMP Rev5 accepts it. FedRAMP 20x requires it. The trajectory is clear: machine-readable documentation, generated from structured data, kept in sync automatically with the system it describes.

OSCAL (Open Security Controls Assessment Language) is the NIST standard that makes this possible. It defines a structured data format for SSPs, SAPs, SARs, and POA&Ms. Instead of a 300-page Word document, your system definition lives as components, capabilities, and implemented requirements in a format that machines can validate and humans can read.

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 OSCAL. But the DoD is moving toward machine-readable compliance documentation. Early adoption 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

FedRAMP requires the full artifact set: SSP, policies, procedures, contingency plans, incident response plans, configuration management plans. The SSP is the anchor.

The relevant control:

• PL-2 (System Security and Privacy Plans): updated at least annually.

FedRAMP is moving from Word-based artifacts toward structured data. Rev5 Balance makes this explicit.

Under Rev5 Balance MAS (Minimum Assessment Scope):

• MAS-CSO-IIR (MUST): identify all information resources that handle or impact federal customer data
• MAS-CSO-FLO (MUST): document information flows and security objectives for all 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 SSP is where that documentation lives.

Under Rev5 Balance ADS (Authorization Data Sharing):

• ADS-CSO-CBF (MUST): keep human-readable and machine-readable formats consistent, automatically
• ADS-CSO-HAD (MUST): 3 years of historical authorization data

ADS-CSO-CBF changes documentation from a document management problem to a data management problem. Maintain the SSP as a Word document and also produce an OSCAL version, and you now have two artifacts to keep in sync. If one source generates both formats, they are consistent by definition.

OSCAL SSPs, SAPs, SARs, and POA&Ms give you the structured format that meets ADS machine-readable requirements. Your system definition maps to OSCAL layers: components, capabilities, implemented requirements, and system information.

What 3PAOs look for: a current SSP that matches the live environment, full control implementation descriptions for every applicable control, accurate boundary diagrams, and evidence of annual review and update. Under Balance, they also check for dual-format availability and consistency.

Common gap: SSPs that drift quarter by quarter because they are maintained in parallel with the environment, not generated from it. Implementation descriptions that read like the control catalog instead of your system. No machine-readable version. No process for keeping human-readable and machine-readable formats in sync.

A 300-page SSP is hard to keep current. When a component changes, every section that references it has to be updated. In a Word document, that means searching for every mention and hoping you find them all. In a structured data model, you update the component once and every reference reflects the change.

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.

20x defines systems using OSCAL layers:

• Components: every element of the authorization boundary as a documented object
• Capabilities: groupings of components by what they do
• Implemented Requirements: mapping of each KSI or control to the components and capabilities that satisfy it
• System Information: metadata about FIPS 199 level, deployment model, service model, boundary

The relevant KSIs:

• KSI-AFR-03 (Authorization Data Sharing): share authorization data per the ADS process. Non-machine-based validation tests that the trust center makes all reports and authorized shared data available. Our 20x implementation data shows this validated through the trust center within the user portal.
• KSI-AFR-09 (Persistent Validation and Assessment): persistently validate, assess, and report on the effectiveness and status of security decisions and policies. Non-machine-based validation ensures that KSI failures result in Issue Ticket creation. This is the feedback loop: when a validation check fails, it creates a tracked finding, not a dashboard alert that nobody watches.

Trust center requirements under ADS:

• ADS-CSX-UTC (MUST for 20x): use a FedRAMP-compatible trust center
• ADS-TRC-USH (MUST): uninterrupted sharing
• ADS-TRC-PAC (MUST): documented programmatic access
• ADS-TRC-AAI (MUST): agency user inventory
• ADS-TRC-ACL (MUST): access logging, 6+ months

Machine-readable is not optional in 20x. It is the primary format. The trust center is the delivery mechanism. Agencies access authorization data programmatically, with access logging, through a self-service portal. No email distribution. No PDF attachments.

KSI-AFR-09 is the operational link. It validates that security decisions are not just documented but continuously tested. When a compliance check fails, an Issue Ticket is created automatically with the validation failure details. That Issue Ticket feeds the POA&M report and the VDR data. Documentation is not a snapshot. It is a living system that tracks its own accuracy.

Common gap on the path to 20x: SSPs still in Word or PDF, no OSCAL capability, no trust center, no programmatic access to authorization data, and no process for automated validation of security decisions.

If your SSP is a Word document you update annually, you are not ready for 20x. The destination is an authorization 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. FedRAMP wants specific formats. CMMC assessors want organized evidence. As ADS and 20x matured, the expectation shifted to machine-readable OSCAL output alongside human-readable documents. 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 OSCAL-based documentation in Stratus GRC-ITSM. The goal: make the system definition the source and the documents the outputs.

1. System definition as the data model. Components, Capabilities, Implemented Requirements, and System Information are first-class objects in the platform. Not a bolt-on. Every element of the authorization boundary is a Component with an ID, title, type, description, purpose, provider, and its relationship to federal data or CUI.
2. Component inventory linkage. Every component links to the live asset inventory. The asset record is the operational truth. The component record is the authorization truth. They stay linked. When the inventory changes, the component relationship surfaces the change for documentation review.
3. Implemented Requirements as structured data. Each FedRAMP control, CMMC practice, or KSI is mapped to the Components and Capabilities that implement it. The implementation statement, validation method, and pass/fail criteria are stored as structured fields. This is where the “how we actually do it” lives, tied to specific components, not as a paragraph in a Word document.
4. Auto-generated artifacts. The SSP, boundary description, control implementation summary, Customer Responsibility Matrix, and other authorization artifacts are generated from this data. Update a component’s implementation description once, and every document that references it reflects the change. No search-and-replace through a 300-page file.
5. Human and machine-readable output. Both formats generate from the same source. Agencies and assessors get readable documents. Automated tools get structured OSCAL data. This meets ADS-CSO-CBF for Rev5 Balance and the machine-readable primary format for 20x.
6. Trust center delivery for 20x. Programmatic access, agency user inventory, and access logging are wired to the trust center. ADS-CSX-UTC, ADS-TRC-PAC, ADS-TRC-AAI, and ADS-TRC-ACL are satisfied by the trust center implementation itself, not by a separate access management process.
7. KSI-AFR-09 integration. Each KSI’s implementation summary references the Components and Implemented Requirements that satisfy it. Changes to implementations are tracked. When a compliance validation fails, an Issue Ticket is created automatically with the failure details. Documentation and validation live in the same system.

graph TD
    COMP[Components] --> SSP[SSP]
    CAP[Capabilities] --> SSP
    IR[Implemented Requirements] --> SSP
    SI[System Information] --> SSP
    COMP --> BD[Boundary Description]
    COMP --> CRM[Customer Responsibility Matrix]
    SSP --> HR[Human-Readable]
    SSP --> MR[Machine-Readable / OSCAL]
 
    style COMP fill:#2b5797,stroke:#5b9bd5,color:#fff
    style CAP fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style IR fill:#5c4a1a,stroke:#ffc857,color:#fff
    style SI fill:#4a1a5c,stroke:#c77dff,color:#fff
    style SSP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style BD fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style CRM fill:#1a3d1a,stroke:#a9dc76,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 an SSP 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 authorization packages, and FedRAMP 20x OSCAL artifacts.

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