OSCAL: Frameworks as Code

ISO 27001, NIS2, DORA, CRA, AI Act, BSI C5, PCI DSS — every framework is published in its own format, its own language, and its own numbering scheme. Teams work through lengthy PDFs by hand, spreadsheets map framework to framework cell by cell, and every new version restarts the work from scratch. The documents do not interoperate — every mapping is human glue. At the same time, regulators themselves have long been demanding structured data: since 2025, the DORA register of information on ICT third-party providers must be submitted annually in xBRL-CSV format. Compliance as a stack of documents no longer scales — neither for companies nor for auditors.

The Open Security Controls Assessment Language is an open, vendor-neutral NIST standard, developed with industry and maintained openly on GitHub. It grew out of a concrete pain point: authorization packages like FedRAMP's were extensive stacks of documents that no machine could verify. Since the first stable release 1.0.0 on June 7, 2021, the standard has evolved continuously — the current version is 1.2.3, dated August 7, 2026. Every model exists equally in JSON, XML, and YAML, convertible between formats, defined via NIST's Metaschema framework, which generates schemas, converters, and documentation from a single source. The core in one sentence: a framework becomes data instead of PDF — the same words, now addressable and queryable.

OSCAL organizes compliance into three layers: the Control Layer describes what a framework says (Catalog), which parts are selected and tailored (Profile), and — since version 1.2.0 — how frameworks relate to one another (Control Mapping). The Implementation Layer describes how systems implement the controls (Component Definition, System Security Plan). The Assessment Layer describes how testing is performed and what was found (Assessment Plan, Assessment Results, POA&M). The public reference example is FedRAMP: the SP 800-53 catalog is tailored via a baseline profile, an SSP implements the selection, assessments test against it, and the POA&M tracks the gaps — each step referencing the previous one in machine-readable form. The same chain works for any framework once a catalog exists as data.

An OSCAL catalog mirrors the structure of the source document: groups represent chapters, domains, or articles; controls are the addressable requirements with stable IDs; parts carry the verbatim text — statement, guidance, assessment objective — each individually referenceable; params turn a framework's “organization-defined” blanks into fillable data fields; props provide labels and ordering; and the back-matter can hold the source document itself, secured with hashes. What matters most is stable identity: a control such as “ac-1” remains the same reference across versions and mappings — tools, profiles, and evidence point permanently at the same object instead of a page number.

Five properties that are impossible with a PDF and trivial with data: diffable — what exactly changed between two framework versions? Queryable — filter, count, select, and report across all controls. Mappable — relate controls across frameworks: implement once, satisfy many. Traceable — every element can point to the exact source passage it came from. Automatable — tools consume the data directly, without re-keying and without copy-paste drift. For GRC teams this means version upgrades become diffs instead of fresh starts, audits draw on verifiable references, and multi-framework compliance becomes a data operation.

NIST publishes SP 800-53 natively in OSCAL — currently release 5.2.0, including the assessment procedures from SP 800-53A and the four baselines. The strongest adoption driver is FedRAMP: after the 20x pilot phases (26 and 14 machine-readable submissions), the March 2026 decision requires more than 500 existing Rev5 providers to deliver machine-readable or semi-structured authorization packages — with a final deadline of November 1, 2027; in parallel, the 20x program replaces narrative documentation with 46 automatically verifiable Key Security Indicators. Internationally, the Australian Signals Directorate publishes the ISM with Essential Eight profiles in OSCAL, GovTech Singapore is adopting the standard government-wide, CIS delivers Controls v8/v8.1 and the Cloud Security Alliance its CCM v4.1 in machine-readable form; since spring 2026, AWS, according to its own announcement, additionally provides SOC 1 and SOC 2 reports in OSCAL. Since February 2025, the OSCAL Foundation (steering committee including AWS and Cisco) has brought the community together; the OSCAL Compass tooling project has been a CNCF Sandbox project since June 2024.

Since September 30, 2025, the BSI has made its Stand der Technik (state-of-the-art) library available on GitHub — rulebooks machine-readable on an OSCAL basis, under the free CC BY-SA 4.0 license and organized along OSCAL layers. The IT-Grundschutz successor Grundschutz++ appears OSCAL-first: around 1,000 requirements in 20 practices (pilot build mid-2026), a pilot phase until September 30, 2026, official unveiling at it-sa on October 27, 2026, with ISO 27001 certification on this basis planned from 2027 onward. C5:2026 — 168 criteria in 17 subject areas, structurally aligned with EUCS — is also available in machine-readable form for the first time. At EU level, the Horizon projects MEDINA and EMERALD (Certification-as-a-Service, running until October 2026) and the EUROSCAL community are driving OSCAL adoption for automated cloud certification; at ECSO, a European OSCAL Task Force convened for the first time in September 2025. One honest limitation: due to ISO copyright, no freely distributable official catalog exists for ISO 27001 — ISO and IEC are working on their own machine-readable standards through the SMART initiative.

With version 1.2.0 of December 2025, the Control Mapping model became the eighth OSCAL model: mapping-collections connect catalogs or profiles at the control or even statement level — with six set-theoretic relationship types (equal-to, equivalent-to, subset-of, superset-of, intersects-with, no-relationship), a mandatory rationale (syntactic, semantic, or functional per NIST IR 8477), and qualifiers for partial coverage and incompatibilities. This is flanked by the NIST OLIR program with official CSF 2.0 references to ISO/IEC 27001, CIS Controls, and PCI DSS, and by metaframeworks such as the Secure Controls Framework with more than 200 mapped frameworks by its own count. The practical consequence: organizations facing NIS2, the AI Act, ISO 27001, ISO 42001, and the CRA at the same time consolidate onto one internal control set via mapping — the combined gap analysis becomes a query, and five implementation projects become one. One thing remains important: mappings are rarely 1:1 — which is exactly why the model enforces relationship type and rationale instead of silently equating controls.

In the Assessment Results model, evidence itself becomes data: findings link via observations to evidence references, and the evidence files exist as back-matter resources — linked and secured with cryptographic hashes, or embedded directly. This is the foundation for continuous assessments all the way to Continuous ATO concepts, as the US Department of Defense defined in a 2022 memorandum. For the supply chain, the Component Definition is the key: a software or cloud provider describes once, in machine-readable form, how its product supports controls — and customers import this building block directly into their System Security Plan instead of answering yet another questionnaire. The tooling is maturing: compliance-trestle manages OSCAL as code in CI/CD pipelines, Compliance-to-Policy generates native policies for Kyverno or Open Cluster Management from Component Definitions and normalizes check results back into Assessment Results; complementing this, CycloneDX 1.6 connects SBOM and compliance evidence through its attestations. An honest note: the standard's complexity is real — its value emerges when a platform encapsulates it rather than passing it through to users.