Policy as Code ExamplesFrom Spreadsheet to Enforcement

What Policy as Code Means in Practice

Most compliance programs still rely on manual evidence collection: spreadsheets, screenshots, and quarterly reviews. Policy as code replaces that with structured rules that can be versioned, tested, and run on a schedule. When a control fails, you get an alert. When an auditor asks for evidence, you export a signed report instead of hunting through tickets.

Example 1: SOC 2 Logical Access (YAML)

CC6.1 requires logical access security measures. Instead of reviewing user lists manually, define a rule that checks MFA status and account activity automatically.

policy:
  id: soc2-cc6.1
  name: Logical Access Controls
  framework: SOC 2
  control: CC6.1
  
rules:
  - id: mfa-enforced
    resource: iam::user
    condition:
      property: mfa_enabled
      operator: equals
      value: true
    severity: high
    
  - id: inactive-user-review
    resource: iam::user
    condition:
      property: last_login_days
      operator: less_than
      value: 90
    severity: medium
    remediation: disable_or_notify

This policy checks every IAM user in your environment. If MFA is disabled, it flags a high-severity finding. If an account has not logged in for 90 days, it triggers a medium-severity alert with an automatic remediation step.

Example 2: PCI DSS PAN Encryption (YAML)

Requirement 3.4 of PCI DSS governs how primary account numbers (PAN) are stored. The rule below validates that storage volumes use approved encryption and that databases tokenize card data.

policy:
  id: pci-dss-3.4
  name: PAN Storage Encryption
  framework: PCI DSS
  control: "3.4"
  
rules:
  - id: pan-encrypted-at-rest
    resource: storage::volume
    condition:
      property: encryption_type
      operator: in
      value: [AES-256, RSA-4096]
    severity: critical
    
  - id: pan-tokenized
    resource: database::table
    condition:
      property: pan_storage_method
      operator: equals
      value: tokenized
    severity: critical

Critical-severity rules like these are evaluated continuously. If a new volume is provisioned without AES-256, the policy engine flags it within minutes — not at the next quarterly audit.

Example 3: NDPR Data Minimization (JSON)

The Nigeria Data Protection Regulation requires that personal data is kept no longer than necessary and processed only for specified purposes. JSON schemas work well when integrating with existing API-driven compliance pipelines.

{
  "policy": {
    "id": "ndpr-data-minimization",
    "name": "Data Minimization",
    "framework": "NDPR",
    "control": "Section 2.1(a)"
  },
  "rules": [
    {
      "id": "retention-limit",
      "resource": "database::table",
      "condition": {
        "property": "retention_days",
        "operator": "less_than_or_equal",
        "value": 365
      },
      "severity": "medium"
    },
    {
      "id": "purpose-specified",
      "resource": "data::processing_activity",
      "condition": {
        "property": "legal_basis",
        "operator": "not_empty"
      },
      "severity": "high"
    }
  ]
}

The retention-limit rule maps directly to NDPR Section 2.1(a). The purpose-specified rule ensures every processing activity has a documented legal basis before data enters your pipeline.

Common Policy as Code Patterns

How C3E Runs Policy as Code at Scale

AthenGuard C3E is built on the same principles shown in the examples above. You write (or import) policies in YAML or JSON, map them to frameworks like SOC 2, HIPAA, PCI DSS, or NDPR, and C3E validates them continuously against your cloud, SaaS, and on-premises environments.

When a control fails, C3E records the finding, timestamps the evidence, and stores it in an immutable audit trail. When an auditor arrives, you generate a signed evidence package in PDF, CSV, or JSON — not a folder of screenshots.