Open Security Controls Assessment Language (OSCAL)
OSCAL is NIST's machine-readable language for representing security controls, control implementations, assessments, assessment results, and remediation records.
Definition
Open Security Controls Assessment Language, usually abbreviated OSCAL, is a NIST-developed set of XML, JSON, and YAML formats for standardized security-control information. NIST describes OSCAL as covering the publication, implementation, and assessment of security controls.
OSCAL is not itself a control framework, audit opinion, certification, or risk score. It is a language for exchanging control evidence in structured form. A catalog can express controls, a profile can tailor a baseline, a system security plan can describe how a system implements controls, and assessment artifacts can record plans, results, and open remediation work.
For AI governance, OSCAL matters because high-impact AI systems increasingly sit inside ordinary security and compliance programs. A model, agent runtime, retrieval store, connector, cloud environment, or data pipeline may need controls for access, logging, configuration, change management, incident response, vulnerability handling, and third-party dependencies.
How It Works
OSCAL is organized into models and layers. The control layer includes catalogs, profiles, and control mappings. The implementation layer includes component definitions and system security plans. The assessment layer includes assessment plans, assessment results, and plans of action and milestones, often shortened to POA&M.
The system security plan model represents a description of control implementation for an information system. The assessment plan model structures what will be assessed and how. The assessment results model records observations, risks, findings, and related evidence. The POA&M model structures unresolved issues and remediation tracking.
As of June 25, 2026, the OSCAL GitHub releases listed v1.2.1 as the latest patch release, while the NIST reference site exposed the v1.2.0 model reference, including the control mapping model. The practical point is version discipline: an OSCAL document should declare the model version and schema expectations that validators, tools, and auditors are using.
Agent Context
AI agents make compliance evidence harder to keep in prose. An agent can call tools, run code, retrieve documents, write tickets, alter repositories, request credentials, and route work through hosted models. A static policy paragraph does not show which controls were implemented at each boundary.
OSCAL can give that evidence a shared shape. A governed agent deployment might map controls to tool permissions, sandbox restrictions, audit logging, data retention, human approval gates, incident escalation, vulnerability scanning, and model-serving infrastructure. The OSCAL record does not prove the agent is safe, but it can make the control claim testable and portable.
Governance and Safety
The governance value is not automation for its own sake. It is the ability to compare what policy requires, what a system claims to implement, what an assessor tested, what failed, what remains open, and who accepted the residual risk. That is especially important when AI systems change through model updates, prompt edits, retrieval changes, dependency upgrades, tool additions, and vendor substitutions.
The main failure mode is compliance theater in machine-readable form. An OSCAL package can be complete and still inaccurate. A control can be marked implemented without meaningful evidence. A generated narrative can sound plausible while hiding missing logs, weak access controls, untested failure modes, or stale dependencies. Human review and technical verification remain necessary.
Defense Pattern
- Declare the version. Record the OSCAL model version, schema, generator, validator, and review date.
- Bind claims to evidence. Link control statements to configuration, logs, tests, tickets, scans, attestations, and responsible owners.
- Separate authoring from approval. Treat AI-assisted drafting as draft evidence, not an accepted assessment result.
- Track open work. Use POA&M records for unresolved control gaps, dates, ownership, and remediation status.
- Diff the package. Review changes when models, tools, data stores, vendors, or control mappings change.
- Do not overclaim. OSCAL can carry evidence for assurance; it is not itself assurance.
Source Discipline
Claims about OSCAL should name the model and the operational purpose: catalog, profile, control mapping, component definition, system security plan, assessment plan, assessment results, or POA&M. Those models answer different questions. Collapsing them into "compliance data" hides whether the document is a baseline, an implementation claim, a test plan, a result, or a remediation queue.
Spiralist Reading
Spiralism reads OSCAL as a grammar for institutional memory. The machine age tempts organizations to replace judgment with dashboards, but it also gives them tools to stop losing the record.
The useful ritual is not the production of one more compliance artifact. It is the discipline of asking: which control, which system, which evidence, which assessor, which exception, which unresolved risk, and which human accepted the answer.
Open Questions
- Which AI-specific controls should be represented as OSCAL extensions rather than prose attachments?
- How should OSCAL packages record fast-changing prompt, tool, retrieval, and model versions?
- What evidence should be visible to affected people, not only auditors and security teams?
- How should organizations verify AI-generated OSCAL drafts before relying on them?
Related Pages
- AI Audits and Third-Party Assurance
- AI Audit Trails
- AI System Inventory
- AI Bill of Materials
- AI Governance
- Secure AI System Development
- NIST AI Risk Management Framework
- NIST SP 800-218A
- Agentic Supply-Chain Vulnerabilities
- SLSA Provenance
Sources
- NIST CSRC, Open Security Controls Assessment Language (OSCAL), reviewed June 25, 2026.
- NIST OSCAL Project, Open Security Controls Assessment Language repository, reviewed June 25, 2026.
- NIST OSCAL, OSCAL v1.2.1 release, reviewed June 25, 2026.
- NIST OSCAL Reference, OSCAL v1.2.0 model reference, reviewed June 25, 2026.
- NIST OSCAL, Control Mapping Model, reviewed June 25, 2026.
- NIST OSCAL, System Security Plan Model, reviewed June 25, 2026.
- NIST OSCAL, Assessment Plan Model, reviewed June 25, 2026.
- NIST OSCAL, Assessment Results Model, reviewed June 25, 2026.
- NIST OSCAL, Plan of Action and Milestones Model, reviewed June 25, 2026.