Making Compliance Machine-Readable
A practical guide to OSCAL implementation—what it is, why it matters, and how to actually deploy it.
The spreadsheet problem
Compliance management in most organizations works the same way it did twenty years ago. Policies live in Word documents. Control matrices live in spreadsheets. Assessment evidence lives in shared drives. Everything requires manual review, comparison, and analysis.
This approach has obvious problems:
- • Mapping controls across frameworks (NIST to ISO to SOC 2) is tedious manual work
- • Documents drift out of sync with each other
- • Audit prep means consolidating information from a dozen sources
- • Proving continuous compliance is essentially impossible
OSCAL—the Open Security Controls Assessment Language—addresses this by making compliance content machine-readable.
What OSCAL actually is
OSCAL is a standardized format for expressing compliance artifacts. Instead of "Section 3.2 of the policy document states that...", you have structured data that computers can process.
NIST developed it. It's not a product you buy—it's an open standard you adopt.
OSCAL document types
Defines controls and their properties. Think NIST 800-53 as structured data.
Selects and tailors controls for your use case. Your organization's baseline.
Documents how a system implements controls. The SSP as code.
Captures assessment findings in a structured format.
All these documents link to each other. Your SSP references your profile. Your profile references control catalogs. Assessment results reference SSP controls. It's a connected graph, not a pile of disconnected documents.
What this enables
Once compliance is machine-readable, you can automate things that used to take weeks:
Control mapping
40 hrs → 4 hrsMachine-readable catalogs let you automatically map controls across frameworks. NIST 800-53 to ISO 27001 to SOC 2—programmatically.
Assessment preparation
120 hrs → 24 hrsPull assessment packages automatically. Evidence, control statements, implementation details—all structured and ready.
Gap analysis
80 hrs → 8 hrsCompare your current controls against a new framework. Identify gaps instantly instead of manually reviewing hundreds of controls.
Continuous compliance
Impossible → PossibleCompare system state against control requirements in real time. Know your compliance posture continuously, not once a year.
How to actually adopt OSCAL
Most OSCAL content focuses on the format specification. Here's what you actually need to do:
Start with catalogs
Import the control frameworks you use. NIST publishes 800-53 and others in OSCAL format already. For frameworks without official OSCAL versions, you'll need to convert them.
Create your organizational profile
Define which controls apply to your organization and any tailoring decisions. This becomes your authoritative baseline.
Convert or create SSPs
Either migrate existing system security plans to OSCAL format, or author new ones directly. This is usually the most work.
Integrate with tooling
Connect to your GRC platform, build assessment workflows, enable the automation that makes this worthwhile.
Migration strategies
Incremental (recommended)
Migrate document types sequentially: catalogs first, then profiles, then SSPs, then assessments. Each step delivers value before the next begins.
Parallel operation
Maintain legacy and OSCAL systems simultaneously during transition. Lower risk but higher ongoing effort due to dual maintenance.
Big bang
Convert everything at once. Higher risk but eliminates the dual-maintenance period. Only for organizations with strong technical capability.
The regulatory direction
OSCAL adoption isn't just about efficiency. Regulators are moving toward requiring machine-readable submissions:
FedRAMP
Now requires OSCAL-formatted SSPs for cloud service provider authorizations. If you sell to the US federal government, this is already a requirement.
Financial regulators
OCC, FDIC, and OSFI are evaluating machine-readable reporting requirements. Early adoption positions you ahead of mandates.
ISO standards
ISO/IEC is developing machine-readable formats aligned with OSCAL principles for international standards like ISO 27001.
Common questions
What format should I use—JSON, XML, or YAML?
JSON for API integration and modern tooling. XML if you have existing XML infrastructure. YAML for human authoring. They're all equivalent and convertible.
Does my GRC platform support OSCAL?
Increasingly, yes. Major platforms are adding import/export capabilities. If yours doesn't, ask your vendor—customer demand drives roadmaps.
How do I convert existing documents?
Structured documents (spreadsheets, databases) can be programmatically converted. Unstructured documents (Word, PDF) need semi-automated extraction with human validation. AI tools can help with the extraction.
What about custom controls?
OSCAL supports custom properties and namespaces. You can extend the standard for organization-specific requirements without breaking standard tooling.
The takeaway
OSCAL represents a fundamental shift from document-centric to data-centric compliance. The operational benefits—60-90% reduction in manual effort—are substantial, and the regulatory trajectory makes adoption increasingly necessary.
The question isn't whether to adopt OSCAL, but when and how. Organizations that establish these capabilities now will be positioned advantageously as requirements evolve.
AI-assisted compliance analysis
Use Onyx Legion to query multiple AI models about regulatory requirements.