Most compliance programs fail not because of bad intent but because the tooling is fundamentally mismatched to the problem. OSCAL is the first serious attempt to fix that at the format level.

The actual problem

Walk into most organisations running a compliance program and you’ll find the same thing: a SharePoint folder full of Word documents, a sprawling Excel workbook someone built three years ago, and a calendar reminder that says “start audit prep” six weeks before the assessment. The security team spends two months compiling screenshots, chasing down configuration exports, and writing narrative responses to control questions — most of which they answered the same way last year, and the year before that.

This isn’t a people problem. The people doing this work are often sharp. It’s a format problem. Word and Excel are not compliance tools. They’re document editors that compliance got pressed into because nothing better existed.

The consequences are predictable: documentation that’s outdated the moment it’s published, compliance status that’s only known during audits, evidence collection that’s manual and error-prone, and frameworks that can’t talk to each other — so SOC 2 evidence lives in one place, ISO/IEC 27001 evidence in another, and the 60% overlap between them gets documented twice.

What OSCAL actually is

NIST’s Open Security Controls Assessment Language is a set of machine-readable formats — XML, JSON, YAML — for expressing security controls, system implementations, and assessment results. That description undersells it. What it really is: a data model for compliance.

Instead of a Word document describing how your organisation implements access control, you have a structured data file. Instead of a spreadsheet tracking which controls you’ve addressed, you have a version-controlled artifact that can be queried, validated, and processed automatically. Instead of a manually assembled audit package, you have a pipeline that generates one on demand from current system state.

OSCAL defines several layers:

  • Catalogs — the controls themselves (NIST SP 800-53, for instance, is available as an OSCAL catalog)
  • Profiles — your selected baseline, the subset of controls you’ve chosen to implement
  • Component definitions — reusable descriptions of how a specific technology implements controls
  • System Security Plans — your full implementation narrative, generated from the above
  • Assessment plans and results — what was tested, how, and what was found
  • Plans of Action and Milestones — findings tracking through remediation

Each layer references the ones below it. Change something at the component level — say, you’ve updated your Kubernetes hardening configuration — and that change propagates to the SSP automatically. The SSP reflects current state because it’s generated from current data, not maintained by hand.

The version control angle

This is where it gets interesting for engineering teams. OSCAL artifacts are text files. Text files go in Git.

That means your compliance posture gets the same treatment as your infrastructure code: pull requests, review, history, blame. Want to know when a control implementation changed and why? git log. Want to propose a change to your security baseline? Open a PR. Want to ensure nothing merges without automated validation? Add a CI check.

This isn’t theoretical. The NIST OSCAL team maintains tooling for schema validation. FedRAMP has published their own OSCAL templates and validation rules. The ecosystem is early but moving fast, and the foundational investment — getting your controls into machine-readable form — pays dividends regardless of which tooling wins.

The multi-framework problem, solved properly

One of the most painful realities of compliance at growing companies is framework sprawl. You get SOC 2 done, then a customer asks about ISO/IEC 27001, then you start selling to EU financial institutions and DORA enters the picture. Each framework has its own documentation requirements, its own evidence formats, its own audit rituals.

With OSCAL, a single control implementation can be mapped to multiple frameworks simultaneously. Access control mechanisms you’ve documented for SOC 2 CC6.1 are the same mechanisms relevant to ISO/IEC 27001 A.5.15 and NIST SP 800-53 AC-2. You document the implementation once. The mapping tells auditors which of their framework’s requirements it satisfies.

The reduction in redundant work isn’t marginal. Organisations with mature OSCAL implementations routinely report 80–90% reductions in audit preparation time. That’s not a projection — it’s what happens when you stop compiling evidence manually and start generating it from data.

What this means in practice

Adopting OSCAL isn’t a weekend project. The tooling ecosystem is still maturing, the learning curve on the data model is real, and integrating OSCAL artifacts into CI/CD pipelines requires engineering work. It’s an investment.

But the alternative is also an investment — it’s just a recurring one, paid in human hours every time an audit approaches, every time a framework gets added, every time a system changes and someone has to remember to update the documentation.

The organisations that move to OSCAL now aren’t just solving a near-term compliance problem. They’re building infrastructure that scales — where adding a new framework means adding a mapping, not rebuilding a program from scratch, and where continuous compliance becomes a property of the system rather than a periodic scramble.

That’s the part worth paying attention to.