OSCAL for FedRAMP: What It Is and Why It Matters

OSCAL (the Open Security Controls Assessment Language) is a NIST-led, machine-readable standard for expressing security controls, system security plans, and assessment results in structured XML, JSON, and YAML instead of Word and Excel documents. FedRAMP uses OSCAL so authorization packages can be validated, exchanged, and assessed by software rather than read line by line, and it is the data format underpinning the automation goals of FedRAMP 20x.

Key takeaways

• OSCAL stands for Open Security Controls Assessment Language and is maintained by NIST in collaboration with industry, with formats available in XML, JSON, and YAML.
• OSCAL is organized into three layers, control, implementation, and assessment, that together hold seven core models, from the control catalog up to the POA&M.
• FedRAMP publishes OSCAL baselines and templates (SSP, SAP, SAR, POA&M) and validation rules in the GSA fedramp-automation repository, built on NIST OSCAL 1.0.4.
• FedRAMP 20x leans on OSCAL and Key Security Indicators (KSIs) to make authorization data continuously machine-readable, but the file format alone does not equal 20x readiness.
• OSCAL is the data standard; it does not collect evidence, define your boundary, or prove a control is working. Those still require live operational systems.

What is OSCAL?

OSCAL is a set of open, machine-readable formats for representing security and compliance information so that tools, not just humans, can process it. NIST describes it as an initiative to "modernize and automate the processes of security and compliance," providing formats in XML, JSON, and YAML that streamline control-based risk assessments and can reduce audit durations from months to minutes.

The core idea is a shift from document-centric compliance to data-centric compliance. A traditional System Security Plan is a 300-plus page Word file that a human assessor reads and a human author maintains. The same information expressed in OSCAL is a structured data file with defined fields, identifiers, and relationships, so a validator can check that required content exists, a tool can generate a human-readable version on demand, and two versions of a package can be compared automatically.

OSCAL does not invent new security requirements. It is a neutral encoding for the controls, baselines, and assessment artifacts that already exist in frameworks like NIST SP 800-53. The value is in expression and exchange: the same control implementation, written once in OSCAL, can be read by any conforming tool without re-keying.

What are the OSCAL models?

OSCAL is organized as a stack of layers, where each higher layer builds on and references the layer beneath it. NIST defines three layers, control, implementation, and assessment, that contain the core authorization-package models. The table below lists each model and what it represents.

OSCAL model	Layer	What it represents
Catalog	Control	A set of controls (for example, NIST SP 800-53) expressed in machine-readable form. The catalog is the basis for every other model; controls used elsewhere must first be defined here.
Profile	Control	A selection and tailoring of catalog controls into a baseline or overlay, with full traceability back to the source catalog. FedRAMP Low, Moderate, and High baselines are published as OSCAL profiles.
Component Definition	Implementation	A reusable description of a single component (software, service, policy, or process) and how its configuration satisfies controls, so SSP tooling can pre-populate implementations.
System Security Plan (SSP)	Implementation	The security implementation of a specific system against a chosen baseline. The machine-readable SSP can be imported into tools and transformed back into a human-readable document.
Assessment Plan (SAP)	Assessment	How and when an assessment will be performed, including scope and the activities to be conducted.
Assessment Results (SAR)	Assessment	The findings produced by assessment activities, including when it was performed, the scope, evidence collected, and results. Supports both snapshot and continuous assessment.
Plan of Action and Milestones (POA&M)	Assessment	The set of findings that the system owner must remediate, tracked from a periodic or continuous assessment.

Source: NIST OSCAL, Layers and Models

A defining property of this stack is native traceability. Because each model imports the artifacts beneath it, you can trace a single finding in a POA&M back through the SAR, the SSP, the profile that selected the control, and the catalog where the control was originally defined. That end-to-end chain is what makes OSCAL packages auditable by machine rather than by manual cross-reference. NIST also maintains a Control Mapping model in the control layer for relating controls across different frameworks, though the seven models above are the ones that make up a FedRAMP authorization package.

Why does FedRAMP use OSCAL?

FedRAMP uses OSCAL because a federal authorization package is enormous, repetitive, and exchanged among many parties, the cloud service provider, the third-party assessment organization (3PAO), and the authorizing agency, and a structured format removes the manual labor and error that come with passing documents between them.

The FedRAMP Program Management Office publishes its OSCAL work in the GSA fedramp-automation repository. That work includes the FedRAMP Rev 5 baselines for High, Moderate, Low, and LI-SaaS as OSCAL profiles; OSCAL templates for the SSP, SAP, SAR, and POA&M in XML, JSON, and YAML; a FedRAMP OSCAL Registry that defines FedRAMP-specific extensions and accepted values; and a set of Schematron validation rules that check whether a submitted OSCAL package actually conforms to FedRAMP requirements. FedRAMP's OSCAL artifacts are built on NIST OSCAL 1.0.4.

The practical payoff is validation before submission. Instead of a 3PAO or agency discovering a missing field deep in review, a CSP can run its OSCAL package through FedRAMP's published rules and catch structural gaps up front. The same data also flows: a control implementation written once in the SSP can be referenced by the SAP and SAR without re-entry, and the POA&M ties directly to the findings that produced it.

If you are moving an existing package into this format, our companion walkthrough on how to convert your SSP to OSCAL covers the hands-on steps; this post stays on the concepts.

How does OSCAL relate to FedRAMP 20x and KSIs?

FedRAMP 20x is built on the assumption that authorization data is machine-readable and continuously current, and OSCAL is the format that carries that data. Where the legacy Rev 5 process treats OSCAL as a better way to submit a largely static package, 20x treats structured, automatable data as the operating model itself.

The bridge between OSCAL and 20x is the Key Security Indicator. KSIs are FedRAMP-defined, validatable statements about a system's security posture, things that can be checked with evidence rather than described in narrative prose. The aim is to replace long control write-ups with indicators a tool can evaluate and report on, and OSCAL's assessment-layer models (assessment results and POA&M) are the natural place for that machine-readable evidence to live. Teams pursuing this path typically want to automate KSI evidence collection directly from their cloud and identity systems so the OSCAL package reflects the real running state.

This is also where a common misconception needs correcting. Being able to export OSCAL is not the same as being 20x-ready. OSCAL is a schema; it can carry current, validated evidence, but it cannot create that evidence on its own. If the inventory is stale and the KSI evidence is collected manually, an OSCAL export is just old compliance data in a modern wrapper. We unpack this fully in why OSCAL alone is not 20x readiness. The short version: OSCAL is necessary plumbing for 20x, but the readiness comes from the live evidence operations behind it.

What OSCAL does not do

OSCAL is a data standard, so it is worth being precise about its limits. OSCAL does not define your authorization boundary, discover in-scope resources, validate cloud configurations, prove that multi-factor authentication is enforced, confirm logging coverage, or keep your inventory current. Those depend on evidence sources, validation logic, and human ownership, not on the file format.

In other words, OSCAL is how you express the truth about a system. It does not produce that truth. A correctly structured, fully valid OSCAL SSP can still describe a system inaccurately if the data feeding it is wrong. The format guarantees consistency and machine-readability, not accuracy. This distinction is the single most useful thing to keep in mind when a tool or vendor claims OSCAL support: the question is never just "can it emit OSCAL?" but "where does the data come from, and is it current?"

Frequently asked questions

What does OSCAL stand for?

OSCAL stands for Open Security Controls Assessment Language. It is a NIST-led initiative, developed with industry, that provides open, machine-readable formats (XML, JSON, and YAML) for representing security controls and compliance information.

Is OSCAL required for FedRAMP?

FedRAMP has invested heavily in OSCAL and publishes its baselines, templates, and validation rules in OSCAL, and machine-readable packages are central to the direction of FedRAMP 20x. The degree to which OSCAL submission is mandatory depends on the specific path and current FedRAMP guidance, so confirm the requirement for your authorization route against fedramp.gov rather than assuming. Either way, OSCAL is the format FedRAMP's automation is built around.

What are the seven OSCAL models?

The seven core OSCAL models are the Catalog and Profile (control layer); the Component Definition and System Security Plan (implementation layer); and the Assessment Plan, Assessment Results, and Plan of Action and Milestones (assessment layer). Each higher model references the ones beneath it, giving end-to-end traceability from a finding back to the originating control.

What is the difference between OSCAL and NIST SP 800-53?

NIST SP 800-53 is the catalog of security and privacy controls, the actual requirements. OSCAL is the machine-readable language used to express those controls, plus the baselines, system plans, and assessment artifacts that reference them. NIST publishes SP 800-53 Rev 5 itself in OSCAL format, so the two are complementary: 800-53 is the content, OSCAL is the encoding.

Does OSCAL replace the SSP?

No. OSCAL changes the SSP's format, not its purpose. The System Security Plan is one of the OSCAL implementation-layer models, so the SSP still exists, it is just expressed as structured data that tools can validate and that can be transformed back into a human-readable document on demand.

What formats does OSCAL support?

OSCAL content is available in XML, JSON, and YAML. Because YAML is a superset of JSON, the same JSON schema can often validate YAML as well, and NIST provides converters between XML and JSON for each model.

Does exporting OSCAL make me FedRAMP 20x-ready?

No. OSCAL is the format that carries 20x data, but 20x readiness depends on current, validated evidence behind Key Security Indicators, continuous validation, and authorization data sharing. An OSCAL export built from stale or manual data is modern in format but not 20x-ready in substance.

Sources

• NIST OSCAL, Open Security Controls Assessment Language
• NIST OSCAL, Layers and Models
• NIST OSCAL, Model Overview
• GSA FedRAMP Automation repository
• FedRAMP, Using the FedRAMP OSCAL Resources and Templates
• NIST SP 800-53 Rev 5 (CSRC)

---

Last updated: June 2026. Written by the Boundera team.