Orbiq LogoOrbiq
Compliance as Code: A Developer's Guide to Automated Compliance
Published Mar 26, 2026
By Orbiq Team

Compliance as Code: A Developer's Guide to Automated Compliance

Compliance as code defines and enforces compliance requirements through machine-readable code — learn the principles, tools, and API patterns to automate it.

Developers
Compliance as Code
Compliance Automation
DevSecOps
API
CI/CD
Trust Center

Compliance as Code: A Developer's Guide to Automated Compliance

Compliance as code is the practice of defining, managing, and enforcing compliance requirements through machine-readable code rather than manual processes, spreadsheets, or static documents.

For developers working in B2B software companies, compliance as code means treating security policies, audit evidence, and certification tracking the same way you treat application code — version-controlled, testable, automated, and integrated into your CI/CD pipeline. Instead of a quarterly scramble to collect screenshots and fill audit binders, compliance checks run continuously alongside your deployments.

According to Gartner's 2026 Market Guide for DevOps Continuous Compliance Automation Tools, by 2028, 65% of organizations will embed compliance automation in DevOps, reducing risk and improving lead times by at least 25% [1]. For EU-based companies under NIS2 and DORA, the pressure is already here: both frameworks expect continuous compliance evidence, not point-in-time audits.

The Shift from Spreadsheet Compliance to Programmable Compliance

Traditional compliance workflows look like this: a compliance manager maintains a spreadsheet of controls, manually collects evidence before each audit, emails documents to auditors, and hopes nothing has drifted since the last review. This approach worked when companies had a single framework and one audit per year.

It breaks down when you face:

  • Multiple overlapping frameworks — ISO 27001, SOC 2, NIS2, and DORA share dozens of controls but require different evidence formats. Manual mapping creates duplication, inconsistency, and inevitable gaps.
  • Cloud infrastructure that changes hourly — Infrastructure-as-code deployments can invalidate compliance evidence within minutes. Point-in-time assessments miss configuration drift entirely.
  • Enterprise buyers demanding proof before signing — Procurement teams now require security documentation upfront, not after the verbal close. Manually assembling compliance packages for each prospect does not scale.
  • Regulations requiring continuous evidence — NIS2 and DORA expect ongoing compliance demonstration, not annual checkbox exercises.

Compliance as code solves these problems by making compliance requirements executable. Instead of a document that says "all production databases must be encrypted at rest," you write a policy check that queries your cloud provider API and fails your deployment if encryption is not enabled.

Key Principles of Compliance as Code

Version Control

Every compliance policy, control definition, and evidence collection script lives in a Git repository. Changes are reviewed through pull requests, approved by the appropriate stakeholders, and tracked with full audit history. When an auditor asks "when did this policy change and who approved it?" the answer is a Git commit.

Automation

Evidence collection, control monitoring, and compliance reporting run automatically — triggered by deployments, scheduled intervals, or API events. No human needs to remember to take a screenshot or update a spreadsheet.

Continuous Monitoring

Rather than checking compliance once per quarter, compliance-as-code systems monitor continuously. When a control drifts out of compliance — an expired certification, a misconfigured access policy, a document that needs updating — the system detects it immediately and alerts the right team.

Testability

Compliance checks are written as testable assertions. Just as you write unit tests for application logic, you write compliance tests for security controls. These tests run in CI/CD and fail the build if a compliance requirement is not met.

Declarative Policies

Instead of procedural runbooks ("log into AWS, navigate to S3, check encryption settings"), compliance-as-code uses declarative policies that define the desired state ("all S3 buckets must have server-side encryption enabled"). The automation layer handles the how.

Compliance as Code vs Traditional GRC Tools

CapabilityTraditional GRCCompliance as Code
Policy storageWord documents, SharePointGit repository with version history
Evidence collectionManual screenshots, spreadsheetsAutomated API queries and scripts
Control monitoringPeriodic manual reviewContinuous automated checks
Change trackingDocument revision history (if maintained)Git commits with PR reviews and approvals
Audit preparationWeeks of manual compilationOn-demand generated evidence packages
Developer integrationSeparate workflow, separate toolsIntegrated into CI/CD pipeline
Drift detectionFound during next auditReal-time alerts
Framework mappingManual cross-referencingProgrammatic mapping with shared evidence

Traditional GRC tools are valuable for governance workflows, risk registers, and board-level reporting. Compliance as code handles the operational evidence layer — the actual collection, monitoring, and enforcement of controls. Many organizations use both.

Common Tools for Compliance as Code

Open Policy Agent (OPA)

Open Policy Agent is the most widely adopted open-source policy engine for compliance as code. You write policies in Rego, OPA's declarative language, and enforce them across Kubernetes, APIs, CI/CD pipelines, and infrastructure. Every policy decision is logged, creating an audit trail suitable for ISO 27001, SOC 2, NIS2, and DORA requirements [2].

# Example: Deny any S3 bucket without server-side encryption
deny[msg] {
  input.resource.type == "aws_s3_bucket"
  not input.resource.properties.server_side_encryption_configuration
  msg := "S3 bucket must have server-side encryption enabled"
}

OPA integrates with Terraform (via Conftest or Regula), Kubernetes (via Gatekeeper), and GitHub Actions — giving you policy enforcement at every layer of your stack.

GitHub Actions / GitLab CI

CI/CD platforms are the execution layer for compliance-as-code workflows. Compliance checks run as pipeline steps: querying APIs for certification status, validating infrastructure configurations against declared policies, and syncing approved policy documents to your trust center.

Terrapin and Regula

For infrastructure-as-code security, Regula evaluates Terraform plans against 500+ built-in OPA policies for security misconfigurations before they reach production. This is "shift-left compliance" — finding drift before it deploys.

NIS2 and DORA: Why EU Companies Need Compliance as Code Now

NIS2 and DORA both depart from traditional annual-audit thinking. They expect continuous compliance evidence and impose reporting deadlines that manual processes cannot meet:

  • NIS2 requires incident notification within 24 hours for significant incidents, with fines up to €10 million or 2% of global annual turnover for non-compliance [3]
  • DORA (financial entities) requires initial incident reporting within 4 hours and mandates ICT risk management documentation as a living system, not a point-in-time snapshot [4]

Compliance as code directly addresses these requirements:

  • Continuous monitoring replaces quarterly reviews with real-time control status
  • Automated evidence collection ensures your audit package is always current
  • Git-tracked policy changes provide the change management audit trail regulators expect
  • API-driven document management keeps your trust center synchronized with your actual compliance posture

For EU companies on NIS2 and DORA timelines, moving from spreadsheet compliance to programmable compliance is not optional — it is the only way to demonstrate ongoing conformity without building a team of full-time compliance administrators.

How Orbiq Enables Compliance as Code

Orbiq's REST API exposes every trust center operation as a programmable endpoint, making it a natural building block for compliance-as-code workflows. Here is how each API capability maps to compliance-as-code principles:

API-Driven Document Management

Instead of manually uploading compliance documents through a web interface, use the Documents API to publish, version, and manage documents programmatically:

# Upload a new version of your security policy
curl -X POST "$ORBIQ_BASE_URL/documents" \
  -H "Authorization: Bearer $ORBIQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Information Security Policy v3.2",
    "access_level": "public",
    "featured": true
  }'

# Then upload the file contents
curl -X PUT "$ORBIQ_BASE_URL/documents/{document_id}/file" \
  -H "Authorization: Bearer $ORBIQ_API_KEY" \
  -H "Content-Type: application/pdf" \
  --data-binary "@security-policy-v3.2.pdf"

When your security policy changes, a CI/CD step uploads the new version automatically. Your trust center always reflects the latest approved document.

Programmatic Certification Tracking

Track certification status through the API and build automated monitoring:

async function checkCertificationExpiry() {
  const body = await fetch(`${ORBIQ_BASE_URL}/certifications`, {
    headers: { Authorization: `Bearer ${ORBIQ_API_KEY}` }
  }).then((response) => response.json());

  const certifications = body.certifications ?? [];

  const thirtyDaysFromNow = new Date();
  thirtyDaysFromNow.setDate(thirtyDaysFromNow.getDate() + 30);

  for (const cert of certifications) {
    const expiry = new Date(cert.expiry_date);
    if (expiry <= thirtyDaysFromNow) {
      console.log(`WARNING: ${cert.title} expires on ${cert.expiry_date}`);
      await notifyComplianceTeam(cert);
    }
  }
}

Run this as a daily scheduled job. Your compliance team gets notified before certifications lapse — not after an auditor or customer discovers the gap.

Automated Access Request Workflows

Build approval logic that runs automatically when prospects request access to compliance documents:

import requests

def process_access_requests():
    body = requests.get(
        f"{BASE_URL}/access-requests",
        headers={"Authorization": f"Bearer {ORBIQ_API_KEY}"}
    ).json()

    requests_data = body.get("contacts", [])

    approved_domains = ["bigcorp.com", "enterprise.io", "partner.co"]

    for req in requests_data:
        if req["review_status"] != "to_review":
            continue

        requester_domain = req.get("email", "").split("@")[-1]

        if requester_domain in approved_domains:
            requests.patch(
                f"{BASE_URL}/access-requests/{req['id']}",
                headers={"Authorization": f"Bearer {ORBIQ_API_KEY}"},
                json={"review_status": "approved"}
            )
        else:
            notify_security_team(req)

Knowledge Base Retrieval for Security Answers

The published Admin API reference documents a GET /knowledge-base endpoint, which gives you a developer-safe way to pull approved Q&A content into your own automation layer:

async function loadKnowledgeBase() {
  const response = await fetch(`${ORBIQ_BASE_URL}/knowledge-base`, {
    headers: { Authorization: `Bearer ${ORBIQ_API_KEY}` },
  });

  const body = await response.json();

  // The Orbiq API uses resource-specific top-level collection keys.
  // Normalize them once in your wrapper rather than scattering assumptions.
  const entries = body.knowledge_base ?? body.entries ?? [];

  return entries.map((item) => ({
    question: item.question,
    answer: item.answer,
    category: item.category,
  }));
}

This is the safer pattern for compliance-as-code workflows: keep approved answers in the trust center knowledge base, retrieve them through the documented API, and let your own automation decide how to match them to questionnaires or internal checks. For a deeper implementation walkthrough, see How to Build an MCP Server for Compliance Automation.

Example: CI/CD Pipeline for Compliance

Here is a practical example of compliance as code integrated into a GitHub Actions workflow:

name: Compliance Checks
on:
  schedule:
    - cron: "0 8 * * 1" # Every Monday at 8am
  push:
    branches: [main]
    paths:
      - "policies/**"
      - "docs/compliance/**"

jobs:
  compliance-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check certification expiry
        env:
          ORBIQ_API_KEY: ${{ secrets.ORBIQ_API_KEY }}
        run: |
          node scripts/check-cert-expiry.js

      - name: Sync updated policies to trust center
        if: github.event_name == 'push'
        env:
          ORBIQ_API_KEY: ${{ secrets.ORBIQ_API_KEY }}
        run: |
          node scripts/sync-policies.js

      - name: Verify document freshness
        env:
          ORBIQ_API_KEY: ${{ secrets.ORBIQ_API_KEY }}
        run: |
          node scripts/check-doc-freshness.js

This pipeline runs on two triggers: a weekly schedule to check certification expiry and document freshness, and on every push to main that modifies policy files to sync updates to your trust center automatically.

Getting Started with Compliance as Code

If you are moving from manual compliance to a code-driven approach, start with these three steps:

  1. Inventory your controls and evidence sources. Before automating, list every control you need to maintain and where the evidence lives. Map each control to the API endpoint or data source that can provide evidence programmatically.

  2. Automate evidence collection first. The highest-ROI starting point is replacing manual screenshot-taking and spreadsheet-updating with automated API queries. Use Orbiq's Documents and Certifications APIs to keep your trust center current without manual uploads.

  3. Add monitoring and alerting. Once evidence collection is automated, add continuous monitoring: certification expiry checks, document freshness validation, and access request processing. These can start as simple cron jobs and evolve into event-driven workflows.

For a step-by-step guide to setting up the API foundations, see How to Build a Trust Center with the Orbiq API. For the agentic AI approach — where AI agents handle compliance workflows autonomously — see Agentic AI for Compliance.

How Orbiq Helps

Orbiq is the API-first trust center platform that makes compliance as code practical for EU companies. The published Admin API v1 reference covers the core operations developers actually automate: document management, certification tracking, knowledge base retrieval, NDA workflows, access request review, brand settings, and API key management. That documented surface is what makes CI/CD checks, scheduled compliance jobs, and MCP wrappers maintainable over time.

The platform is EU-hosted, SOC 2 compliant, and designed for developer workflows. Whether you are building compliance checks into your CI/CD pipeline, automating vendor assurance processes, or deploying white-label trust centers for multiple clients, Orbiq's API gives you the building blocks to treat compliance as code rather than compliance as paperwork.

Explore the full API at the Orbiq Developer Hub or read the API reference.

FAQ

What is compliance as code?

Compliance as code is the practice of defining, managing, and enforcing compliance requirements through machine-readable code. Instead of maintaining policies in Word documents and collecting evidence in spreadsheets, compliance as code uses version-controlled scripts, automated API calls, and CI/CD integrations to monitor controls, collect evidence, and enforce policies continuously.

How is compliance as code different from compliance automation?

Compliance automation refers broadly to any software that replaces manual compliance work. Compliance as code is a specific methodology within that umbrella — it emphasizes treating compliance artifacts the same way developers treat application code: version-controlled, testable, reviewable through pull requests, and integrated into CI/CD pipelines. Compliance automation may use a GUI; compliance as code is inherently developer-driven. For more on compliance automation platforms, see the Compliance Automation glossary entry.

What tools do I need for compliance as code?

At minimum, you need a version control system (Git), a CI/CD platform (GitHub Actions, GitLab CI, etc.), and an API-first compliance platform like Orbiq. For policy enforcement, Open Policy Agent (OPA) with Rego policies is the de facto standard for declarative, testable compliance rules. You write policy checks and evidence collection scripts that run in your pipeline and call the compliance platform's API to sync documents, monitor certifications, and process access requests.

Can compliance as code work for ISO 27001 and SOC 2?

Yes. Both ISO 27001 and SOC 2 define controls that can be monitored and evidenced through automated checks. Technical controls (encryption, access management, logging) are 70–90% automatable. Governance and process controls still require human oversight, but evidence collection and reporting for those controls can be automated. Compliance as code handles the evidence layer; human judgment handles the governance layer.

How do I integrate compliance as code with my existing CI/CD pipeline?

Add compliance checks as pipeline steps alongside your existing build and test stages. For example, add a step that queries the Orbiq Certifications API to verify no certifications are expiring, a step that syncs updated policy documents to your trust center, and a step that validates your security configuration against declared policies. These checks can block deployments (fail the build) or run as advisory notifications depending on your risk tolerance.

Does compliance as code satisfy NIS2 and DORA requirements?

Compliance as code is particularly well-suited for NIS2 and DORA. Both regulations require continuous compliance evidence — not annual snapshots. NIS2 mandates 24-hour incident notification and ongoing risk management. DORA requires 4-hour incident reporting and living ICT risk documentation. Automating evidence collection and continuous monitoring directly supports these requirements.

Sources & References

  1. Gartner Market Guide for DevOps Continuous Compliance Automation Tools 2026 — TechIntelPro — "By 2028, 65% of organizations will embed compliance automation in DevOps, reducing risk and improving lead times by at least 25%"
  2. Open Policy Agent (OPA) — openpolicyagent.org — Policy engine and audit trail capabilities
  3. NIS2 vs DORA: Differences, Obligations & Deadlines 2026 — heydata.eu — NIS2 fine structure and incident reporting deadlines
  4. Navigating DORA and NIS2 Compliance — SANS Institute — DORA 4-hour incident reporting requirement
Compliance as Code: A Developer's Guide to Automated...