Skip to content

Compliance as Code Principles

Home › Explanation › Transformation › Compliance As Code

Introduction

"Compliance as Code" applies software engineering practices to regulatory compliance.

Organizations encode requirements as executable specifications, automate validation, and generate evidence as a delivery pipeline byproduct.

Core insight: Compliance requirements are specifications that can be tested, just like functional requirements.

The Five Principles

Compliance as Code rests on five interconnected principles:

  1. Everything as Code - All compliance artifacts in version control
  2. Continuous Validation - Compliance checked on every commit
  3. Shift-Left Compliance - Issues caught early when fixes are cheap
  4. Automated Evidence - Evidence generated automatically from pipelines
  5. Executable Specifications - Requirements expressed as automated tests

These principles work as a system - implementing only one or two provides limited value; implementing all five creates transformative change.

Principle 1: Everything as Code

What It Means

All compliance artifacts stored as version-controlled text files in Git instead of Word documents in SharePoint.

In practice:

  • Policies in Markdown (or kept in existing document management system)
  • Procedures as Markdown with executable examples
  • Evidence automatically referenced from version control

Requirements Storage

Requirements can be stored as Gherkin specifications

Why It Matters: Version control provides traceability, collaboration via pull requests, searchability, immutability, and automation capabilities impossible with traditional document management.

See: Everything as Code for detailed explanation of the paradigm and benefits.

Principle 2: Continuous Validation

What It Means

Compliance checked on every commit. Compliance tests run in CI/CD pipeline alongside functional tests.

In practice:

  • Risk control scenarios execute in CI (see specifications below)
  • Security scans on every commit
  • Policy violations fail builds
  • Real-time compliance status visible in dashboards

Why It Matters: Continuous validation provides immediate feedback when violations occur, prevents compliance drift, scales without manual review overhead, and provides continuous audit readiness.

See: CD Model Stages 1-7 for how continuous validation integrates into development stages.

Principle 3: Shift-Left Compliance

What It Means

Validate compliance as early as possible in the delivery lifecycle - ideally before code commits.

Shift-Left Economics

The earlier you catch issues, the cheaper they are to fix. Issues found at later stages require:

  • More coordination across teams
  • Incident response procedures
  • Potential regulatory reporting
  • Customer communication
  • Significantly longer resolution time

In practice:

  • Pre-commit hooks check for secrets, forbidden patterns
  • CI validates all risk control scenarios
  • PLTE runs acceptance tests
  • Production monitoring detects drift

See: Testing Strategy for comprehensive shift-left testing approach.

Principle 4: Automated Evidence Collection

What It Means

Evidence generated automatically as byproduct of pipeline execution - no manual collection during audits.

In practice:

  • Test results stored in Git LFS or artifact repository
  • Deployment logs committed automatically
  • Scan results referenced by commit SHA
  • Traceability matrices generated from version control metadata

Why It Matters: Automated evidence eliminates manual collection overhead, ensures completeness, provides tamper-evident audit trail, and enables instant audit responses.

Architecture: Evidence collection integrates into CD Model at multiple stages (commit, PLTE, production).

Principle 5: Executable Specifications

What It Means

User scenarios expressed as executable Gherkin specifications, linked to risk controls that define compliance requirements.

The Risk Control Architecture

Three Layers:

  1. Risk Catalog
  2. Library of all available risk controls
  3. You don't modify this - it's your control library

  4. Example controls: AC-2 (Account Management), IA-2 (Authentication), AU-2 (Audit Events)

  5. Risk Profile

  6. Selects which controls from the catalog apply to YOUR solution
  7. Single repository-wide profile

  8. Based on your risk assessment

  9. Specifications

  10. User scenarios tagged with @control:<id> to link to profile controls
  11. Tests that verify control satisfaction
  12. Evidence that proves compliance

Implementation Note: The catalog and profile use OSCAL (Open Security Controls Assessment Language) for machine-readable compliance.

Understanding the paradigm:

Technical implementation:

Transformation:

Tutorials | How-to Guides | Explanation | Reference

You are here: Explanation — understanding-oriented discussion that clarifies concepts.