Governance & Risk Management , Standards, Regulations & Compliance

For decades, organizations have managed security and compliance through policies, standards, procedures, spreadsheets and reports - artifacts that have served governance functions well. But these tools increasingly struggle to keep pace with dynamic regulatory environments and advances in frontier technology. They also fall short in supporting strategic planning and investment decisions.

See Also: AI Impersonation Is the New Arms Race-Is Your Workforce Ready?

As enterprises embrace automation and move toward an autonomous paradigm, a Policy as Code program will help transform policies from static documents into continuously verifiable, evidence-based, data-driven decisions for strategic technology and business partnerships.

The core problem for enterprises is not a shortage of policies, but the absence of machine-readable, enforceable and auditable policies that can generate evidence in near real time. Traditional methods cannot address the accelerating complexity of modern environments - multi-cloud, microservices, ephemeral infrastructure and continuous deployment pipelines - let alone keep pace with them.

Policy as Code is the structural answer to this problem. Not a tool or a product, but a discipline that brings policies to the same version-controlled, continuously evaluated fabric as the technology and operational processes they govern.

The discipline operates across three areas simultaneously:

• Modernizing policies, standards and procedures;
• Embedding validation, verification and evidence collection with software development and operational processes;
• Governance with continuous assurance.

Policy as Code represents a transformational move in how enterprises approach their operating model, and its success depends on four enablers working in concert: executive sponsorship, technology leadership alignment, engineering participation and governance, risk and compliance modernization.

Policy modernization for most enterprises is not a greenfield to start. They have to address the challenge of translating existing policies expressed in natural language across multiple domains, carrying regulatory obligations and approved governance processes, to machine-readable form without losing intent and enterprise context.

Mapping is a critical step in policy modernization. Policy documents, policies, standards and procedures, along with control content such as objectives, requirements, implementation steps and operational procedure steps, and regulatory obligations should be inventoried, version-controlled and assigned unique identifiers. Without this foundation, it is impossible to gain visibility into control effectiveness, coverage, drift and measurable outcomes that inform technology strategy and investment decisions.

Open Security Controls Assessment Language, or OSCAL, provides a machine-readable representation of controls, assessments, evidence, findings and remediation plans. It provides seven structured data models: catalog, profile, component definition, system security plan, assessment plan, assessment result, and plan of action and milestones that together represent the entire life cycle of a security control from definition through evidence. OSCAL can help produce an enterprise's own control catalog, component definition and system security plan for enterprise-specific implementation specifics expressed in JSON, XML or YAML formats.

For enterprises inheriting NIST SP 800 53, the official OSCAL catalog can be directly imported. For bespoke internal controls, compliance-trestle can help make conversion tractable. Not every control is needed for every system. OSCAL profile model allows selection of applicable controls from catalog and produces a baseline trimmed for enterprise context. This becomes input for enforcing rules.

Open Policy Agent, OPA, is an open-source policy engine that evaluates policies written in Rego and automatically makes consistent allow-or-deny decisions across applications, infrastructure, Kubernetes, APIs, and CI/CD pipelines, enabling automated governance and continuous enforcement. Cedar, Kyverno, Cerbos and HashiCorp Sentinel are other options available for policy enforcement purposes. OPA is a useful example to walk through the Policy-as-Code program.

It is important to understand that OSCAL and OPA are complementary to each other, operating at different layers and different points in the life cycle of the Policy-as-Code program. As the Policy-as-Code program matures, the benefits of integrating OSCAL and OPA become evident. Another tool that is part of the NIST OSCAL ecosystem is the compliance 2 policy - C2P - bridge. It was developed under IBM research, and it transforms OSCAL artifacts into native enforcement-engine formats like OPA Rego, Kyverno policies and AWS Config rules and normalizes the results back into OSCAL format. For enterprises not starting from a blank sheet, C2P dramatically reduces the authoring burden of connecting governance documentation to live enforcement.

One of the biggest values of the Policy-as-Code program is control traceability. The traceability chain involves various levels and all must be connected to claim traceability to hold. Every exception and violation at every level should be tracked and that will help trace back to policy, control owner, technical implementation, evidence, and risk acceptance as applicable.

The below example illustrates how Policy as Code works.

Example: MFA From Policy to Code

The control is NIST SP 800-53 IA-2(1) multi-factor authentication for privileged accounts. We will follow it through all levels - OSCAL catalog entry, profile tailoring, component definition, OPA - Rego rule, CI/CD gate validation, evidence generation and AR finding.

The catalog entry is imported from NIST's published OSCAL content. It is just referenced.

2. OSCAL Profile Tailored Baseline

The profile includes IA-2(1) and sets the parameter value to privileged. This scoping decision of which accounts are "privileged" is a governance decision made once here and propagated automatically to all downstream enforcement.

3. Enforcement With OPA – Rego Rule

Input

Rego Policy

Output

Deployment is blocked.

4. Evidence Generation

AR format produced by the pipeline is a machine-generated, human-readable finding that an authorizing official can review.

The target-id: "ia-2.1_obj" field links this finding directly to the assessment objective in the OSCAL Catalog. The cosign-bundle property links it to a cryptographically signed, reproducible artifact in the pipeline. A regulator can verify both ends of the chain independently.

The diagram below shows the full reference architecture of a Policy-as-Code program connecting modernization of policies, SDLC and non-SDLC flows, governance, and the continuous monitoring loop.

The Policy-as-Code program described above is powerful but labor-intensive to initiate and maintain. This is precisely where agentic artificial intelligence creates structural advantage.

Agentic AI in this context means AI systems that can take multi-step autonomous actions, reading regulatory documents, authoring OSCAL artifacts, generating and testing Rego policies, triaging violations, and proposing remediation with a human in the loop for approval at governance boundaries. The agent does not replace the control owner; it dramatically reduces the time from "regulatory change published" to "enforcement rule deployed and evidenced."

The relationship between AI and Policy as Code runs in both directions. AI accelerates the Policy-as-Code program, but Policy as Code is also one of the most effective tools available for governing AI systems themselves. The current challenges of AI deployment in enterprises map almost directly onto the problems that Policy as Code is designed to solve.

A mature Policy-as-Code program, sustained over two or three years, produces a structural move in the enterprise's risk posture. The audit becomes a review of machine-generated evidence, not a data collection exercise. New systems inherit the control baseline from existing component definitions rather than writing new security plans from scratch. And when a regulatory change arrives, the question is not "what do we need to do to comply?" but "which rules need updating, and when will the updated evidence be available?" - an engineering question, not a governance crisis.

That transition is what the Policy-as-Code program, properly implemented and sustained, ultimately delivers.