· 8 min read · Compliance Automation
How the Open Security Controls Assessment Language moves compliance out of spreadsheets and into executable JSON, and how Bidda exports every node as OSCAL.
What OSCAL Is and the Problem It Solves
Most compliance work still lives in spreadsheets, word-processor documents, and PDF control matrices. Every tool stores controls in its own layout, so mapping one framework to another is slow manual work, and an auditor cannot read your evidence without a human translating it first. OSCAL, the Open Security Controls Assessment Language, is a National Institute of Standards and Technology project that fixes this by giving controls, the systems they apply to, and the assessment of those controls a single standard structure that machines can read.
The OSCAL Model Layers
OSCAL is organised as a stack of connected models. A catalog is a set of controls, such as the controls in NIST SP 800-53. A profile, sometimes called a baseline, is a selection and tailoring of catalog controls for a particular risk level. A component definition describes how a product satisfies a set of controls. A system security plan records how one specific system implements a baseline. Assessment plans and assessment results capture how controls were tested and what the assessor found. A plan of action and milestones tracks the gaps that remain and the work to close them. Each layer references the one beneath it, so evidence stays connected from the catalog all the way down to a finding.
Why Machine-Readable Compliance Matters Now
Regulators and platforms are moving toward continuous authorisation, where a system proves it stays compliant over time rather than passing a single point-in-time review. The United States FedRAMP programme has been modernising its authorisation process around OSCAL so that security packages can be submitted and checked as data. When controls and evidence are structured, an auditor can ingest them directly, a governance platform can compare two baselines automatically, and an AI agent can read a control without scraping prose it might misread.
OSCAL in JSON, in Practice
In JSON, an OSCAL control is an object with a stable identifier, a human-readable title, and a set of parts. A statement part holds the plain-language requirement. A guidance part holds supporting notes and references. Properties record metadata such as the framework family or a status flag, and links point to the source material. Because the shape is predictable, any OSCAL-aware tool can load the control, show it to a reviewer, and line it up against another framework without custom parsing for every vendor.
How Bidda Exports Nodes as OSCAL
Every Bidda node already carries the pieces an OSCAL control needs, so the mapping is direct. The plain-English summary becomes the control statement. The primary citations become guidance with links to the source instruments. The evidence schema becomes assessment objectives. The deterministic workflow becomes assessment methods and activities. A public catalog of every node is served at /api/v1/oscal/catalog.json with titles, summaries, and source links, so anyone can browse the registry in OSCAL form. A paid node returns its full OSCAL rendering, including the workflow and evidence schema, when the request adds format=oscal.
One Unlock, Two Formats
OSCAL on Bidda is a rendering choice, not a separate product. The underlying node is never converted or edited to produce it. A customer who unlocks a node can take the plain thirteen-key schema by default, or the OSCAL JSON of the same content by asking for it, on the same purchase. This keeps the source-verified node as the single record of truth while letting a governance team drop the OSCAL version straight into an OSCAL-aware tool.
What This Unlocks for GRC Teams and AI Agents
A governance, risk, and compliance team can import Bidda controls into an OSCAL-aware platform and crosswalk them against a NIST SP 800-53 baseline without hand-typing. An AI agent building a compliance workflow can consume controls in a standard vocabulary that it shares with the rest of the toolchain, which reduces the chance of a misread obligation at the point of a decision. Both the human and the agent work from the same structured evidence, traceable back to the primary source.
Frequently Asked Questions
What is NIST OSCAL?OSCAL, the Open Security Controls Assessment Language, is a National Institute of Standards and Technology project that defines machine-readable formats for control catalogs, baselines, system security plans, and assessment results. It lets controls and compliance evidence be exchanged as structured data rather than prose documents.
What formats does OSCAL support?OSCAL is published in three interchangeable formats: XML, JSON, and YAML. The content model is the same across all three, so a tool can convert between them without losing meaning. Bidda serves OSCAL in JSON.
How does Bidda deliver OSCAL?A public OSCAL catalog of every node is served at /api/v1/oscal/catalog.json with titles, summaries, and source links. A paid node returns its full OSCAL rendering, including the workflow and evidence schema, when the request adds format=oscal. The plain schema and the OSCAL rendering come from the same single unlock.
Do I have to convert my nodes to OSCAL to use it?No. OSCAL is an additive rendering of a node. The source-verified golden node is never edited or converted to produce it, so the same record stays the single source of truth whether you consume the plain schema or the OSCAL JSON.