DEV Community: Codacon

Why Use NIST OSCAL? Compliance as Data, Not Documents

Codacon — Wed, 14 Oct 2026 23:47:20 +0000

TL;DR

What it is. OSCAL, the Open Security Controls Assessment Language, is an open standard from NIST. It expresses security controls, system security plans, assessments, and remediation plans as structured data in XML, JSON, or YAML. It is free, open source, and developed in the open on GitHub. The latest release at time of writing is v1.2.3.

Why use it. Most compliance work still lives in Word documents and spreadsheets that are out of date the day they are signed. OSCAL turns that paperwork into data that tools can validate, compare, and update. Write a control implementation once and reuse it across frameworks. Hand assessors evidence they can process by machine. Move from an annual snapshot toward continuous assurance.

Why now. Regulators are publishing controls as data. US federal cloud authorization is moving toward machine-readable packages, Canada's control catalogues descend from the NIST controls OSCAL was built around, and Germany now publishes its national baseline natively in OSCAL. Meanwhile the number of frameworks you answer to only grows.

The problem OSCAL solves

Ask a security team how many frameworks it reports against. SOC 2, ISO 27001, NIST SP 800-53, CIS, provincial privacy law, customer questionnaires, and now AI-specific frameworks. Each one gets its own document, its own spreadsheet, and its own late-night copy-and-paste session before the audit.

The underlying facts barely change between them. Multi-factor authentication is enforced the same way whether ISO or SOC 2 asks about it. Yet the same answer is rewritten for each framework, in prose no tool can check, by people who would rather be fixing things.

That model has three failures:

Drift. The document says one thing, the system does another, and nobody notices until an assessor or an attacker does.
Duplication. Every new framework multiplies the work instead of reusing what is already known.
Opacity. A 300-page PDF cannot be queried. "Which controls depend on this identity provider?" takes a week to answer.

What OSCAL actually is

NIST describes OSCAL as a set of formats that give a standardized, machine-readable representation of control information, from catalogs to assessment results. The models fall into three layers:

Control layer. Catalogs hold the control definitions, such as NIST SP 800-53. Profiles select and tailor controls into a baseline, such as Moderate or your own internal standard.
Implementation layer. Component definitions describe how a product or service satisfies controls. A system security plan (SSP) describes how a specific system implements its baseline.
Assessment layer. Assessment plans, assessment results, and plans of action and milestones (POA&M) record what was tested, what was found, and what is being fixed.

Each layer references the one above it. An SSP points to a profile, which points to a catalog. An assessment result points to the SSP. That chain of references is the point: change a control, and you can trace every system and finding it touches.

Why organizations should use it

Write once, map many times

Describe how your platform enforces encryption at rest as a component definition. Reference it from every system that uses the platform. When a framework or a customer asks, the answer comes from the same source, not a fresh rewrite.

Documentation that can be checked

OSCAL content validates against published schemas. A missing control, a broken reference, or a parameter left blank is caught by a tool, not by an assessor three weeks before your deadline. That changes compliance from a writing exercise into something closer to software, with versions, reviews, and automated checks.

Vendor and supplier assurance at scale

If your cloud and SaaS providers publish component definitions, you inherit their control descriptions as data instead of re-reading their PDFs. The same applies in reverse: if you sell to regulated buyers, a clean OSCAL package shortens their review of you.

Continuous assurance instead of annual theatre

Once controls, systems, and findings are linked as data, evidence from your pipelines and cloud configuration can feed assessment results directly. Status becomes a query, not a project. This is where OSCAL meets the rest of a modern secure software development lifecycle: compliance becomes another artifact the pipeline produces and checks.

Exceptions become data, too

Every program has controls it cannot meet as written: a legacy system that cannot take multi-factor authentication, a scanner finding that turns out to be a false positive, a risk the business decides to accept. In most organizations these exceptions live in email threads and a spreadsheet tab. They rarely have an expiry date, the approver has often moved on, and nobody looks at them again until an assessor asks.

OSCAL records exceptions inside the risk record, not beside it. A risk in a POA&M moves through statuses such as open, remediating, deviation-requested, deviation-approved, and closed. Its response is typed as avoid, mitigate, transfer, share, or accept. Properties flag a risk as a false positive, accepted, or risk-adjusted, and a risk log records each status change, who logged it, and when. Because the risk references the finding, the control, and the system, an exception never drifts away from what it excuses.

The payoff is the same as everywhere else in OSCAL: questions become queries. Which accepted risks reach their deadline this quarter? Which systems carry exceptions against the same control? Who approved this deviation, and on what evidence? Give every exception a deadline and the pipeline can flag it for review before it quietly becomes permanent.

Regulatory direction of travel

Machine-readable assurance is no longer a US-only idea. Where you sit changes the details, not the direction.

United States. FedRAMP's RFC-0024 proposes that Rev5 cloud providers submit authorization packages in an approved machine-readable format, with OSCAL named as one, starting with new submissions on September 30, 2026. Check FedRAMP's final rules for the scope and dates that apply to you. NIST also publishes its own catalogs, including SP 800-53 and SP 800-171, as OSCAL content.

Canada. The federal control catalogue, ITSG-33, is based on NIST SP 800-53, so it maps naturally onto OSCAL's catalog and profile model. The Canadian Centre for Cyber Security has not published an official OSCAL edition, but AWS has encoded the CCCS Medium and Protected B High Value Assets cloud profiles in OSCAL as open samples. For defence suppliers, the Canadian Program for Cyber Security Certification (CPCSC) rests on a standard technically identical to NIST SP 800-171, which NIST already publishes in OSCAL. Level 1 self-assessments enter select defence contracts from summer 2026, and Level 2 third-party certification from spring 2027.

Quebec. Nothing in Quebec requires OSCAL today. But Quebec organizations already carry structured obligations that live badly in documents: public bodies answer to the government's information security directive and framework, and Law 25 requires, among other things, privacy impact assessments for certain projects and a register of confidentiality incidents. OSCAL lets you model those obligations as your own catalog, alongside ISO 27001 or ITSG-33, and answer each from the same evidence.

Europe. NIS2 and DORA do not prescribe a data format, and the EU has not published official OSCAL catalogs for them. Germany has moved first: the BSI now publishes its security requirements, including Grundschutz++, the successor to IT-Grundschutz, as OSCAL documents on GitHub. The catalog was published in September 2025, with NIS2 implementation as a legal driver. If one of Europe's most influential baselines now ships as data, others will follow.

If none of these apply to you, the signal still matters: regulators and large buyers are tired of reading PDFs, and machine-readable assurance is where procurement is heading.

No lock-in

OSCAL is an open standard with open-source tooling from NIST and the community. Your compliance data stays portable between GRC platforms, consultants, and assessors. That alone is worth something the next time a tool contract renews.

Why adoption stalls

If OSCAL is this useful, why do so few organizations use it? In our experience, for three reasons:

The gap between the standard and the system. The schemas are well documented. Mapping your actual architecture, inherited controls, and shared responsibilities into them is not.
The legacy pile. Years of SSPs, spreadsheets, and policy documents do not convert themselves, and a naive conversion just produces machine-readable versions of the same drift.
Ownership. OSCAL sits between security, compliance, engineering, and procurement. Without a clear owner and a narrow first scope, it becomes a side project that never ships.

None of these are technical blockers. They are scoping, sequencing, and change-management problems.

Where to start

Pick one system and one baseline. Not the whole estate. One system that matters, assessed against the framework you already answer to most often.
Model the shared components first. Identity, logging, encryption, and your cloud platform carry most controls. Describe them once as component definitions.
Build the SSP from references, not prose. Let the system plan inherit from components instead of restating them.
Validate in the pipeline. Run schema and content checks on every change, the same way you test code.
Connect one evidence source. Feed one automated control check into assessment results, prove the loop works, then expand.

How CODACON can help

The standard is free. The hard part is the translation: turning your real systems, inherited controls, and existing paperwork into an OSCAL model your teams will actually maintain, then embedding it in how you build and assess.

That is where we work. We help organizations scope a first OSCAL implementation, model their shared components, convert what is worth keeping from the legacy pile, and wire validation into their delivery pipeline so the model stays true after we leave.

We have already done this end to end for one organization. The engagement is confidential, so we cannot name the client or share their artifacts, but we can walk you through the approach, the pitfalls we hit, and what it would take in your environment. If you are weighing OSCAL, or have started and stalled, let's talk.

What Should a Board Ask Before Approving an AI Coding Tool Rollout?

Codacon — Sun, 06 Sep 2026 02:10:09 +0000

Vendor demos show how fast AI can write code. The proposal in front of the board should show what happens when that code is wrong.

Before approving an AI coding tool rollout, directors need more than a productivity promise. They need evidence of value, clear limits on access, and someone accountable for stopping the rollout if those limits fail.

Here are the questions that turn an impressive demo into a defensible decision.

Where the board's job starts and stops

A board does not approve every developer tool. It governs material exposure and delegated authority. An AI coding tool crosses that line when it can read source code, hold secrets, or change production systems. Management owns implementation. The board owns the conditions for proceeding.

We frame the questions using the NIST AI Risk Management Framework 1.0 (Govern, Map, Measure, Manage), its Generative AI Profile, NIST AI 600-1, for AI-specific risks, and the Secure Software Development Framework, SP 800-218, for software assurance. NIST describes the AI RMF as voluntary. The questions are our application of that guidance, not a NIST checklist, a certification, or a legal requirement.

1. What business outcome are we buying, and how will we prove it?

Why it matters. Code volume is not a business outcome. Faster code can also mean more review, defects, and rework. METR's July 2025 randomized study found that 16 experienced open-source developers took 19% longer on 246 tasks when allowed to use early-2025 AI tools, while believing they had been faster. METR cautions against generalizing to other teams or current tools, but the lesson holds: perceived speed is not measured speed.

Evidence to request. A baseline taken before the pilot and repeated after: delivery lead time, defect rate, review time per change, rework, and total cost. The AI RMF asks organizations to document expected benefits and costs, including non-monetary ones (MAP 3.1 and 3.2).

Warning sign. The business case rests on the vendor's productivity figure or on "acceptance rate," the share of suggestions developers kept.

2. What can the tool read, retain, transmit, and change?

Why it matters. Exposure depends on permissions, not product names. Suggesting code in an editor is one thing. An agent that runs commands, edits repositories, and triggers deployments is another. AI 600-1 (section 2.9) describes indirect prompt injection: instructions hidden in content the AI reads, such as a code comment or a web page, that can cause it to leak data or run malicious code. Autonomy multiplies that risk.

Evidence to request. A data map: what source code, secrets, and customer data the tool can access, what the vendor retains and for how long, whether inputs train models, and which subprocessors are involved. A permission map: what the tool can execute, commit, and deploy, and whether a human approves each step. Suggest, execute, and deploy should each carry their own approval conditions.

Warning sign. "The vendor doesn't train on our data," with no confirmation that the statement applies to the tier and settings actually purchased.

3. What evidence shows our controls work with AI-generated code?

Why it matters. The SSDF describes practices for reducing vulnerabilities in released software, limiting their impact, and preventing recurrence. Our position: AI-generated code must pass the same assurance process as any other code. The risk is that volume overwhelms it. AI 600-1 names automation bias, the tendency to defer to machine output, as a risk in its own right (section 2.7).

Evidence to request. Pilot results from the company's own repositories and workflows, not a vendor sandbox (MEASURE 2.3). Confirmation that human review, security testing, dependency and licence checks, and build pipeline protection apply to AI-generated changes. Reviewer capacity: changes per reviewer per week, before and after.

Warning sign. Approval times fall while change volume rises. That is rubber-stamping, not efficiency.

4. Who is accountable when something goes wrong?

Why it matters. The AI RMF places responsibility for AI risk decisions with executive leadership (GOVERN 2.3). A rollout owned by "engineering" has no one to call when the tool pushes a credential to a public repository.

Evidence to request. A named executive sponsor with documented acceptance of residual risk. A responsibility matrix spanning engineering, security, legal, and procurement. An exception process: who can grant broader access, and who is informed.

Warning sign. Accountability is shared, or sits with the champion who selected the tool.

5. What vendor and contractual risks are we accepting?

Why it matters. The tool is a supply-chain dependency. The AI RMF asks for third-party risk policies, including intellectual property, and contingency plans for third-party failures (GOVERN 6.1 and 6.2). AI 600-1 notes that the legal status of generated content resembling copyrighted work is still debated (section 2.10). Contract terms are the practical answer, and they vary by tier.

Evidence to request. A vendor assessment covering confidentiality, intellectual property protections and their limits, incident notification timelines, the vendor's right to change models or terms, and exit arrangements including data deletion. A continuity plan if the service is withdrawn. SP 800-218A, NIST's profile for building AI models, applies to vendor diligence, not to the company's developers.

Warning sign. Legal reviewed the standard terms, but nobody confirmed which apply to the purchased configuration.

6. What are the pilot's success criteria and stop conditions?

Why it matters. The AI RMF expects mechanisms and assigned responsibility to disengage or deactivate a system behaving inconsistently with its intended use (MANAGE 2.4). A pilot without stop conditions is a rollout with extra steps.

Evidence to request. Phased access starting with low-risk repositories and non-production environments. Acceptance thresholds set in advance. Incident triggers that pause the pilot: a credential exposure, a vulnerable change reaching production, a data-handling breach. A tested revocation: someone has turned off access and timed it.

Warning sign. Success criteria are written after the pilot, or the stop authority's objectives depend on the rollout.

7. What will the board see after approval?

Why it matters. Approval starts oversight. The AI RMF calls for post-deployment monitoring, incident response, and change management (MANAGE 4.1).

Evidence to request. A one-page quarterly dashboard: outcomes against baseline, adoption by team, defect and rework trends, security incidents involving the tool, control exceptions granted, and exposure changes such as new permissions, model versions, or repositories in scope.

Warning sign. The first report covers adoption and satisfaction only.

Hypothetical example: evidence changes the decision

Illustrative scenario, not a client case. A manufacturer's CTO proposes a company-wide rollout of a coding agent, citing a vendor claim of 40% faster delivery. The audit committee asks for question 1 and 3 evidence. A six-week pilot on two internal services shows lead time down 11%, review time per change up 30%, and two vulnerable dependencies caught only after merge. The committee approves suggestion-only mode across engineering, keeps execute permissions with the pilot teams for one more quarter, and requires reviewer capacity and scan coverage in the next report. Same tool, different decision.

Approval checklist

Baseline and post-pilot measurements of outcomes and cost
Data map and permission map, with separate conditions for suggest, execute, and deploy
Evidence that review, security testing, and pipeline controls cover AI-generated code
Named executive owner, responsibility matrix, and exception process
Vendor assessment, contract terms confirmed for the purchased tier, continuity plan
Written success criteria, incident triggers, and a tested revocation
Quarterly dashboard format agreed

Three decisions

Approve a bounded pilot when the value case is credible but unproven, and the pilot stays in low-risk environments with stop conditions.

Approve expansion subject to conditions when pilot evidence meets the thresholds and the remaining gaps are named, owned, and dated.

Defer pending evidence when management cannot yet answer questions 1, 2, or 6. That is not a rejection. It is oversight.

For an independent view on rollout readiness, our GenAI security readiness assessment covers this ground.