Overview

OSCAL stands for Open Security Controls Assessment Language. NIST develops it with industry and the public community as a machine-readable way to describe security controls, their implementation, and their assessment.

Private preparation: Secani's implemented toolkit is being prepared privately for open source and is not published yet. The CLI and agent skills remain future projects.

What is OSCAL?

OSCAL provides a set of connected models for control catalogs, profiles, component definitions, system security plans, assessment plans and results, and plans of action and milestones. These models let teams exchange compliance data between tools instead of locking it in proprietary documents.

OSCAL content can be serialized as JSON, XML, and YAML. Each format represents the same structured security and compliance concepts, so applications can choose the format that best fits their workflows.

OSCAL adoption across regulatory contexts

Research snapshot — last reviewed July 12, 2026. Secani continuously reviews publicly available primary sources and tries to keep this overview current. It is not exhaustive and is not legal advice or a legal assessment. Know of an update or a missing government initiative? Email hello@secani.com.

• 74 jurisdictions reviewed
• 12 confirmed government initiatives
• 5 countries with confirmed official use

“Confirmed official use” includes official government publications, examples, pilots, and scoped operational requirements; it does not imply mandatory OSCAL submission. The table below is a representative selection of seven initiatives from Secani's manually maintained research snapshot.

How to read the maturity score. This is a research maturity score, not a legal ranking:

• 2/5 — Pilot, draft, or official example
• 3/5 — Maintained official publication
• 4/5 — Mandatory operational use within a defined scope

An official OSCAL publication does not automatically mean that organizations must submit their own SSPs or assessment results in OSCAL.

OSCAL document lifecycle

Purple: control layer. Teal: implementation layer. Orange: assessment layer.

How to read this lifecycle

0. Receive the catalog. Import an authoritative catalog such as NIST SP 800-53 or BSI IT-Grundschutz. The catalog is the complete set of controls, statements, guidance, and open parameters; you do not author it yourself.
1. Tailor it into a Profile. Choose a baseline or start from scratch, include or exclude controls with rationale, set parameter values, and optionally add organization-specific controls or modify statements. The resulting Profile is a small document that references the Catalog and records these decisions.
2. Resolve the profile. Let the tooling combine the Profile with its Catalog. The result is the effective control list with selections applied and parameter values filled in—the working checklist for everything that follows.
3. Describe the system. Begin the System Security Plan (SSP) with the authorization boundary, users and roles, information types and impact level, and an inventory of software, hardware, policies, and process components.
4. Answer every control. For every statement in the resolved baseline, record how it is implemented, which component provides it, who is responsible, and whether its status is implemented, partial, planned, or not applicable. Vendor Component Definitions can supply reusable answers, while planned work can feed future POA&M entries.
5. Plan the assessment. An independent assessor typically uses the SSP to define which controls and components will be assessed, which methods will be used—examine, interview, or test—and when the work will happen.
6. Record assessment results. The assessor captures observations and supporting evidence, turns them into satisfied or other-than-satisfied findings for each control, and records the resulting risks. Evidence files can be attached through OSCAL back matter.
7. Build the POA&M. The system owner converts open findings and risks into remediation entries that state what will be fixed, who owns it, when it is due, and which milestones lead to completion.
8. Continue monitoring. Remediate, update the SSP, re-test, and update the results and POA&M. When a new Catalog version arrives, return to Profile tailoring and use the tooling to identify what drifted.

NIST resources

• Learn OSCAL from NIST
• Read the NIST project overview
• Explore the official OSCAL repository

Secani projects

Secani's @secani/oscal TypeScript toolkit is implemented and being prepared privately for open source, but it is not published yet. It currently parses, validates, and analyzes OSCAL 1.2.2 JSON documents. The separate oscal-cli command-line interface and secani/oscal-skills collection remain future work.

Until the toolkit repository is public, follow Secani on GitHub for updates.

• Validate OSCAL 1.2.2 JSON in your browser
• Explore the TypeScript toolkit
• Explore oscal-cli