What Is Open Security Controls Assessment Language (OSCAL)?
OSCAL is not a new security framework or set of controls. Rather, it is a common language for describing security controls, implementations and assessment results in a machine-readable format. OSCAL uses structured data formats such as JSON, XML and YAML so that software tools — not just human reviewers — can process compliance information.
At its core, OSCAL replaces narrative-heavy documentation with data models that describe what controls exist, how they are implemented and how well they perform. This allows agencies to reuse the same control information across systems and assessments, rather than recreating documentation every time.
According to Michael Epley, chief architect and security strategist for public sector at Red Hat, OSCAL was developed to address a long-standing documentation challenge.
“OSCAL was created to solve the static documentation crisis,” Epley says. “For decades, security teams have lived in Word and Excel, creating massive PDFs that are outdated the moment they are saved.”
The Problem With Traditional Security Control Documentation
For many state and local governments, security compliance still revolves around large system security plans, spreadsheets and attachments that must be updated manually. These documents are often copied from system to system, revised by hand and stored in disconnected locations.
That approach introduces several problems. Manual documentation takes time and invites errors. Updates must be repeated across multiple files. And because the information isn’t machine-readable, it can’t be easily validated or analyzed by tools.
Epley notes that these challenges hit state and local governments particularly hard.
“State and local governments should care because they still have to prove compliance to federal requirements, including NIST, HIPAA, CJIS (Criminal Justice Information Services) and more,” he says. “OSCAL provides a ‘map once, comply many’ approach through standardized control representation across frameworks.”
Epley also points out that OSCAL can help smaller agencies avoid starting from scratch.
“It helps smaller agencies more easily ingest security profiles from larger agencies and partners without having to completely wipe their slates clean,” Epley says. “It also gives agencies an avenue to require machine-readable security data from their vendors.”
READ MORE: Here’s a guide to AI governance for state and local agencies.
How OSCAL Works: Machine-Readable Formats and Layered Architecture
OSCAL organizes security information into structured models that represent different parts of the compliance lifecycle. These models include control catalogs, system implementations and assessment results, all expressed in machine-readable formats.
Instead of writing long narratives describing how controls are implemented, agencies model the information as data. That data can then be validated automatically, reused across systems and integrated with compliance tools.
This fundamentally changes how security teams work from day to day.
“OSCAL changes the daily grind from formatting narratives to managing data,” Epley says. “It shifts teams from document formatting and manual processes to managing machine-readable data.”
Rather than performing periodic, point-in-time audits, OSCAL enables continuous validation.
“This replaces bulky, static Word documents with dynamic JSON, XML or YAML files,” Epley explains, “enabling a move from infrequent snapshot-in-time audits to continuous monitoring and automated validation.”
Epley offers a practical example: Instead of searching through a 500-page document, a security engineer can rely on an OSCAL-driven dashboard.
“If a new validation error occurs, the dashboard flags it and a fix can be pushed via code,” he says. “Once all the system checks turn green, the work is done and an audit trail is maintained in real time.”
