Governance and risk management, standards, regulations and compliance
Policy as code turns static compliance documents into enforceable and auditable policies
Shobha Jagaspal •
June 12, 2026

For decades, organizations have managed security and compliance through policies, standards, procedures, spreadsheets, and reports. These deliverables have fulfilled their governance functions. However, these tools are finding it increasingly difficult to keep up with the dynamic regulatory environment and advances in cutting-edge technology. It also falls short in supporting strategic planning and investment decisions.
See also: AI impersonation is the new arms race – is your workforce ready?
As companies embrace automation and move to an autonomous paradigm, Policy as Code programs help transform policies from static documents to continuously verifiable, evidence-based, data-driven decisions for strategic technology and business partnerships.
The core problem for enterprises is not a lack of policies, but rather a lack of machine-readable, enforceable, auditable policies that can generate evidence in near real-time. Traditional methods cannot handle, much less keep up with, the accelerating complexity of modern environments such as multi-cloud, microservices, ephemeral infrastructure, and continuous deployment pipelines.
Policy as Code is a structural solution to this problem. It’s not a tool or a product, it’s a discipline that brings policy into the same version-controlled and continuously evaluated fabric as the technology and operational processes it manages.
This area runs concurrently across three areas:
- Modernize policies, standards, and procedures.
- Incorporate verification, validation, and evidence collection into your software development and operations processes.
- Governance with continuous assurance.
Policy as Code represents a transformative movement in how companies approach their operating models, and its success depends on four enablers working together: executive sponsorship, technology leadership alignment, engineering participation and governance, and risk and compliance modernization.
For most companies, policy modernization is not a greenfield place to start. They must grapple with the challenge of translating existing policies, expressed in natural language across multiple domains, with regulatory obligations and approved governance processes, into machine-readable format without losing intent or corporate context.
Mapping is an important step in policy modernization. Policy documents, policies, standards, procedures, and administrative content such as objectives, requirements, implementation procedures, operational procedures, and regulatory obligations must be inventoried, versioned, and assigned unique identifiers. Without this foundation, it is impossible to visualize control effectiveness, coverage, drift, and measurable results to inform technology strategy and investment decisions.
Open Security Controls Assessment Language (OSCAL) provides machine-readable representations of controls, assessments, evidence, findings, and remediation plans. It provides seven structured data models: Catalog, Profile, Component Definition, System Security Plan, Assessment Plan, Assessment Results, Action Plan and Milestones that represent the entire security management life cycle from definition to evidence. OSCAL helps create system security plans for enterprise-specific control catalogs, component definitions, and enterprise-specific implementation specifications expressed in JSON, XML, or YAML format.
If you are a NIST SP 800 53 inheritor, you can directly import OSCAL’s official catalog. For bespoke internal controls, compliance trestles can help make the transformation manageable. Not all systems require all controls. The OSCAL profile model allows you to select appropriate controls from a catalog and generates a baseline tailored to your enterprise context. This will be the input for applying the rule.
Open Policy Agent (OPA) is an open-source policy engine that evaluates policies written in Rego and automatically makes consistent permit 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 explain Policy-as-Code programs.
It is important to understand that OSCAL and OPA are complementary to each other and operate at different layers and points in the lifecycle of a Policy-as-Code program. As your Policy-as-Code program matures, the benefits of integrating OSCAL and OPA will become apparent. Another tool that is part of the NIST OSCAL ecosystem is Compliance 2 Policy – C2P – Bridge. It was developed based on IBM research and converts OSCAL artifacts into native enforcement engine formats such as OPA Rego, Kyverno policies, and AWS Config rules, and normalizes the results back to OSCAL format. For companies that don’t start with a clean slate, C2P greatly reduces the burden of creating governance documents in linking them to actual enforcement.
One of the greatest values of a Policy-as-Code program is control traceability. The traceability chain contains many levels, all of which must be connected to maintain traceability. All exceptions and violations at all levels should be tracked, and this helps trace back to policy, management ownership, technical implementation, evidence, and risk acceptance where applicable.

The example below shows 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. Track it at all levels: OSCAL catalog entries, profile adjustments, component definitions, OPA – Rego rules, CI/CD gate validation, evidence generation, AR detection, and more.
1. OSCAL Catalog
Catalog entries are imported from OSCAL content published by NIST. This is for reference only.

2. Baseline aligned to OSCAL profile
The profile includes IA-2(1) and sets the parameter value to privileged. This scoping decision about which accounts are “privileged” is a governance decision made once here and automatically reflected to all enforcement agencies downstream.

3. Enforcement by OPA – Rego Rules
input

lego policy

output

Deployment is blocked.
4. Creation of evidence
The AR format produced by the pipeline is a machine-generated, human-readable result that can be reviewed by authorized officials.

The target-id: “ia-2.1_obj” field links this result directly to the assessment target in the OSCAL catalog. The cosign-bundle property links to a cryptographically signed reproducible artifact in your pipeline. The regulator can independently verify both ends of the chain.
The diagram below shows a complete reference architecture for a Policy-as-Code program that connects policy modernization, SDLC and non-SDLC flows, governance, and continuous monitoring loops.

Although the Policy-as-Code program described above is powerful, it takes a lot of effort to start and maintain. This is exactly where agent artificial intelligence creates a structural advantage.
Agent AI in this context refers to an AI system that can perform multi-step autonomous actions, such as reading regulatory documents, creating OSCAL artifacts, generating and testing Rego policies, prioritizing violations, and collaborating with humans to recommend remediation for approval at governance boundaries. The agent does not replace the control’s owner. This will significantly shorten the time from “announcement of regulatory changes” to “implementation of enforcement regulations and presentation of evidence.”
The relationship between AI and Policy as Code is a two-way street. AI accelerates Policy-as-Code programs, but Policy as Code is also one of the most effective tools available for managing the AI systems themselves. The current challenges of AI adoption in enterprises correspond almost directly to the problems Policy as Code is designed to solve.
A mature Policy-as-Code program lasting two to three years creates a structural shift in a company’s risk posture. An audit is not a collection of data, but a review of machine-generated evidence. New systems inherit control baselines from existing component definitions rather than creating a new security plan from scratch. And when regulatory changes arrive, the question isn’t “What do I need to do to comply?” But “Which rules need to be updated? When will updated evidence be available?” – This is an engineering problem, not a governance crisis.
This transition is ultimately what a properly implemented and maintained Policy-as-Code program will enable.
