Key takeaway: The Open Security Controls Assessment Language (OSCAL) is NIST's standard for expressing controls, system security plans, assessment plans, results and plans of action as machine-readable data in JSON, XML or YAML. Under Consolidated Rules 2026 (CR26), authorization data moves from documents to data: Certification Data Sharing calls for human-readable and machine-readable JSON data with programmatic access, and OSCAL is a FedRAMP-identified format. There is no September 2026 OSCAL deadline. RFC-0024 proposed one, and the final rules replaced it with the CR26 schedule below. Hand-authoring OSCAL does not scale, and NISTcompliance.ai generates it from control evidence.
This hub explains the OSCAL models, how a package fits together, what CR26 requires and when, and how Quzara generates OSCAL from evidence.
Dates checked against fedramp.gov on October 14, 2026. Model list from NIST.
OSCAL is a set of NIST-developed formats that express security controls, system descriptions, assessment plans, results and plans of action as structured data. It replaces the Word, Excel and PDF packages that FedRAMP providers have exchanged for about a decade with data that software can validate, compare against baselines and keep current.
A provider no longer describes a control in a paragraph and hopes a reviewer reads it. A structured OSCAL package ties each implementation statement to the control, the component that satisfies it and the evidence behind it. NIST publishes every model in XML, JSON and YAML, and its JSON schemas cover YAML as well.
Related guides: What Is FedRAMP 20x, Certification Classes A through D, 20x roadmap, Significant Change Notices, the What is OSCAL? guide, and NISTcompliance.ai.
NIST organizes OSCAL into three layers. FedRAMP packages draw on all of them.
Expresses what the controls are and which ones apply.
Describes how a system and its components meet the controls.
Records how controls were tested and what remains open.
Source NIST OSCAL layers.
The control framework the package is measured against.
Selects and tailors the catalog into a baseline. The SSP references the profile.
Component definitions describe what satisfies controls. The SSP references them, the profile and the evidence.
The assessment plan and results reference the SSP, and the results reference the plan.
Tracks findings from the assessment results through remediation.
The package is a linked set of documents, not one file. Because documents refer to each other by identifier, tooling can walk the whole package automatically, and one broken reference fails validation. That is the main reason OSCAL is generated rather than typed.
Machine-readable data is not one deadline. It runs through the Certification Data Sharing and Collaborative Continuous Monitoring rulesets, which carry their own dates, and it feeds the vulnerability reporting that begins on December 7, 2026. For 20x certifications, Certification Data Sharing applies from July 4, 2026 to obtain certification and from January 1, 2027 to maintain it.
CDS calls for human-readable data and machine-readable JSON data with programmatic access, and OSCAL and JSON are the formats FedRAMP identifies. FedRAMP expects human-readable materials to be generated from the machine-readable data, and it has said it will not build the tooling, leaving that to industry (Notice NTC-0009).
Dates for providers on the Rev5 path, from the FedRAMP CR26 deadlines page.
| Ruleset | Obtain | Maintain | Grace period ends |
|---|---|---|---|
| Certification Data Sharing (CDS) | Jan 1, 2027 | Aug 1, 2027 | Feb 1, 2028 |
| Collaborative Continuous Monitoring (CCM) | Jan 1, 2027 | Apr 2, 2027 | Oct 1, 2027 |
| Significant Change Notification (SCN) | Jan 1, 2027 | Jan 1, 2027 | Jun 1, 2027 |
| Vulnerability Detection and Response (VDR) | Dec 7, 2026 | Dec 7, 2026 | Mar 7, 2027 |
| Vulnerability Evaluation and Reporting (VER) | Dec 7, 2026 | Dec 7, 2026 | Mar 7, 2027 |
RFC-0024, issued January 13, 2026, proposed machine-readable packages for Rev5 providers with a September 2026 date. FedRAMP published the initial outcome in Notice NTC-0009 on March 25, 2026 and the final rules in CR26 on June 24, 2026. The CR26 schedule replaced the September date, so plan against the dates in the table.
Primary sources CR26 Rev5 deadlines, Notice NTC-0009, Notice NTC-0014, RFC-0024.
Writing OSCAL by hand is possible. It is slower and more error-prone than the Word document it replaces.
A Moderate baseline SSP in OSCAL JSON runs thousands of lines with exact cross-references. One broken identifier fails validation.
Required fields, formats and enumerated values are validated against the NIST schema, which takes deep schema knowledge to satisfy by hand.
Findings, changes and notices keep arriving. Manual editing cannot keep pace with the cadence CR26 sets.
OSCAL should come from identity, configuration, logging, change and ticketing systems, not from retyping what they already know.
Cybertorch produces the evidence. NISTcompliance.ai structures it into the package the rules require.
Cybertorch runs a 24/7 U.S. citizen SOC on Azure Government, FedRAMP Certified Class D (High). Detections, incidents and vulnerability data become evidence.
NISTcompliance.ai generates OSCAL and other machine-readable compliance packages from control evidence across 800-plus NIST SP 800-53 Rev 5 controls, with mapping to CMMC Level 2 and FISMA.
Ingests vulnerability data to support reporting under Notice NTC-0014, effective December 7, 2026.
Auditor Co-Pilot lets 3PAO, C3PAO and agency assessors query the package and its evidence. Answers cite their sources.
NISTcompliance.ai operates inside the Cybertorch FedRAMP boundary on Azure Government. AI drafts and compares, and ISSOs, assessors and authorizing officials make every determination.
Whether you are modernizing a Rev5 package or building a 20x submission, Quzara and NISTcompliance.ai provide the OSCAL automation and continuous assurance pipeline. Engage Quzara through our GSA HACS vehicle or directly.
