This article is divided into two parts.
The first part covers what OSCAL is, what its seven models do, and what FedRAMP actually requires and when. It also covers where FedRAMP 20x goes its own way, and if you should care about OSCAL even if you don’t need to file FedRAMP.
Part two covers what’s missing for OSCAL standards to help ensure machine-readable compliance doesn’t just become another checkbox exercise. This section explains how Gist intercepts a proposed change, evaluating it against machine-readable controls such as OSCAL.
What OSCAL Is, and Why NIST Built It
Most compliance programs run on a series of documents. The ‘system security plan’ might live in Word, the ‘control matrix’ lives in Excel, and a few people who know where the facts sit spend weeks assembling both before an audit. Then another framework asks the same questions in a different order, and the work happens again.
The documents pass the audit, year after year. And the information inside them goes nowhere else, because no system connects them, and nobody catches the section that contradicts another one.
OSCAL, the Open Security Controls Assessment Language, was built to end that. NIST developed it with industry input as a family of formats in XML, JSON, and YAML that carry control catalogs, tailored baselines, implementation details, and assessment findings as structured data. The current release, v1.2.2, landed on April 30, 2026.
From the OSCAL Hub: “OSCAL is a NIST-developed family of seven interrelated document types. Together they cover the full security lifecycle: from defining controls, to selecting and tailoring them, to documenting how a system implements them, to planning and recording assessments, to tracking remediation. Each type has a well-defined schema and can be expressed in JSON, XML, or YAML.”
OSCAL adds no controls, rewrites nothing in NIST SP 800-53, and takes no position on whether your encryption meets the bar. What OSCAL changes is the container. Once a control implementation lives as a field rather than a paragraph, software can validate it and carry it into the next document without anyone retyping a word.
For compliance directors in healthcare and financial services, the appeal is tangible. Their teams map the same controls across SOC 2, ISO 27001, and HIPAA by hand, in spreadsheets, while the regulations underneath keep shifting. Organizations now monitor more than 250 regulatory changes a day, according to Mordor Intelligence. Hand-maintained mappings cannot survive that pace.
The OSCAL format consists of seven stages, each one matching a stage that a typical compliance program already runs.
The Seven OSCAL Stages, Explained
The seven OSCAL models developed by NIST are organized into three distinct layers that cover the entire security compliance and risk management lifecycle.
Control Layer
- Catalog: Acts as the foundational library containing a complete, un-tailored collection of security controls and requirements (such as NIST SP 800-53).
- Profile: Selects, filters, and customizes a specific subset of controls from one or more catalogs to create a targeted baseline (such as a FedRAMP Moderate baseline).
Implementation Layer
- Component Definition: Describes reusable software, hardware, or service components and documents how they satisfy specific security controls.
- System Security Plan (SSP): Serves as the core blueprint for an information system, detailing its boundaries, characteristics, and how it implements a chosen profile using specific components.
Assessment Layer
- Assessment Plan (SAP): Outlines the formal strategy, scope, and procedures for testing and evaluating how well a system implements its security controls.
- Assessment Results (SAR): Records the factual findings, observations, and data resulting from the execution of an assessment plan.
- Plan of Action and Milestones (POA&M): Tracks the remediation activities and planned resolutions for any security weaknesses or deficiencies discovered during an assessment.
So seven documents owned by seven people become one linked record, with the relationships written down instead of assumed. FedRAMP built its modernization plan on that idea, which is where most of the confusion about OSCAL begins.
What is the Actual FedRamp Timeline?
Search for the OSCAL deadline and the answer looks settled. Vendor blog after vendor blog names September 30, 2026, often in bold, sometimes with a countdown. Compliance teams have built roadmaps around it.
The date came from a proposal. FedRAMP published RFC-0024 in January 2026 asking for machine-readable Rev5 authorization packages, carried that September deadline, and then opened a public comment period that closed in March. The industry pushed back hard on the timeline.
FedRAMP listened. Its outcome notice replaced the single deadline with a phased model split by certification class, and said so plainly: the agency would “update both the expected requirements and timelines to enable gradual adoption over a much longer period of time.” Class D systems, the High baseline, owe comprehensive machine-readable data. Classes A through C move to a semi-structured text format that retires Word and Excel without demanding full OSCAL. Both are due by November 1, 2027.
Nearer dates matter more right now. FedRAMP launched its Consolidated Rules for 2026 on June 25, and those rules bind every participant from January 1, 2027. New Rev5 certification applications close June 11, 2027.
Machine-readable compliance is coming fast, but reaching the federal market on a schedule the market can absorb.
Are OSCAL and FedRAMP 20x Connected?
OSCAL carries the Rev5 certification, and RFC-0024 scoped its machine-readable package proposal to Rev5 processes. FedRAMP 20x rests on Key Security Indicators instead, 56 of them at Low impact and 61 at Moderate, and providers validate them continuously rather than documenting them once a year. FedRAMP publishes those requirements in its own JSON schema, in a public rules repository, and the 20x documentation never mentions OSCAL at all.
So 20x inherited OSCAL’s premise without adopting its format. Both want compliance facts to arrive as data pulled from live systems. They disagree only about the file type. Several tooling vendors bridge the seam by converting the KSI catalog into OSCAL profiles, which works well enough, though it reflects a vendor choice rather than a FedRAMP rule.
Does OSCAL Apply to Enterprises With No Federal Exposure?
A GRC director at an insurance carrier or a hospital network has no FedRAMP package to file and no agency sponsor to satisfy. So new federal formatting rules may seem like somebody else’s homework.
Here’s why enterprises with no federal exposure still need to pay attention:
- It makes things easier even if you are not bound by FedRamp because cross-framework mapping breaks down by hand. A control that satisfies SOC 2, ISO 27001, and HIPAA has to be described three ways, and every revision to any one of them sends someone back to re-check all three. Structured control data holds those mappings as relationships a system maintains. A spreadsheet holds them as a snapshot that goes stale the week after somebody builds it.
- Structured evidence makes more sense for enterprises. Security questionnaires already ask for evidence rather than assertions, and the vendor risk teams sending them would rather receive a structured attestation than a PDF they have to read and re-key.
- The GRC platforms are moving regardless. Vendors are building toward OSCAL because their federal customers require it, which means the format arrives inside your existing stack whether or not you picked it.
Stay tuned for part two where we tackle how the OSCAL problem is bigger than syntax.
FAQ
OSCAL, the Open Security Controls Assessment Language, is a NIST standard that expresses control catalogs, baselines, implementations, and assessment results as structured data in XML, JSON, or YAML. It adds no controls of its own. What it changes is how compliance content gets stored, so software can validate and reuse it.
Machine-readable submission is coming for Rev5 authorization packages, though not on the September 2026 date most articles cite. FedRAMP replaced that proposal with a phased model split by certification class, landing November 1, 2027. Its Consolidated Rules for 2026 bind every participant from January 1, 2027.
FedRAMP 20x rests on Key Security Indicators and publishes its requirements in FedRAMP’s own JSON schema rather than OSCAL. The 20x documentation does not reference OSCAL. Some vendors convert the KSI catalog into OSCAL profiles inside their own tooling, which reflects a vendor choice rather than a program requirement.
Catalog holds published controls. Profile tailors them into a baseline. Component Definition describes how a technology satisfies controls. System Security Plan documents one specific system. Assessment Plan sets out testing. Assessment Results captures what the testing produced. Plan of Action and Milestones tracks open items with owners and due dates.
Increasingly, yes. Cross-framework mapping across SOC 2, ISO 27001, and HIPAA breaks down when a person maintains it by hand. Enterprise buyers want structured attestations rather than PDFs. And GRC platforms are building toward OSCAL for their federal customers, so the format reaches your stack regardless.
OSCAL is a data format rather than a product. Continuous compliance platforms confirm that infrastructure controls exist and hold their settings between checks. Neither one reads a Jira ticket or a pull request. Gist covers that layer, capturing what changed, who assessed it, and what evidence supports the decision.
A record that answers the schema’s questions: which control, implemented by which component, assessed on which date, evidenced by what, and with which exceptions still open. Gist builds that record from design docs, tickets, and pull requests as changes happen, rather than reconstructing it during audit week.
