Controls-as-Code

Treating security controls the way we treat infrastructure: defined once, version-controlled, mapped across frameworks, and machine-readable. This repo is a working pattern for GRC that executes instead of a control matrix that rots in a spreadsheet.

Built for environments carrying multiple overlapping regimes at once — FedRAMP, CMMC, StateRAMP, HIPAA/HITRUST, ISO 27001, and ISO/IEC 42001 (AI management systems) — where the same control is answered several different ways for several different audits. Define it once; crosswalk it everywhere.

Includes AI-governance controls: as ISO/IEC 42001 and the NIST AI RMF land on regulated organizations, AI controls belong in the same source-of-truth catalog as everything else — not in a separate silo. See the companion ai-management-system repo for the AI-specific depth.

Framework- and vendor-neutral. Examples use open standards (NIST 800-53, OSCAL). Mappings and components are illustrative and synthetic — no organization's real control implementation is represented here.

---

Why this exists

The recurring failure mode in GRC isn't knowing the controls — it's keeping them coherent. A control gets implemented, an auditor's interpretation drifts, a sister framework asks the same thing in different words, and evidence lives in someone's inbox. Multiply by four frameworks and the program spends its time reconciling instead of reducing risk.

Controls-as-code attacks that directly:

• One source of truth — each control defined once, in structured form.
• Crosswalks, not re-work — map a single implementation to every framework that asks for it.
• Machine-readable — OSCAL output that GRC platforms and SSP tooling can consume.
• Diffable & reviewable — control changes go through pull requests, like any other engineering change.

---

What's here

controls-as-code/
├── README.md
├── catalog/
│   └── controls.yaml              # source-of-truth control definitions (synthetic)
├── crosswalks/
│   ├── 800-53_to_csf.md           # NIST 800-53 ↔ CSF mapping
│   ├── 800-53_to_iso27001.md      # NIST 800-53 ↔ ISO 27001
│   ├── 800-171_to_cmmc.md         # 800-171 ↔ CMMC practices
│   └── iso27001_to_42001.md       # ISMS ↔ AI management system overlap
├── oscal/
│   └── component-definition.json  # OSCAL component example
├── policy-as-code/
│   ├── access-control.rego        # example policy expressed as code (OPA/Rego)
│   ├── access-control_test.rego   # test suite for the policy (opa test)
│   └── examples/                  # sample inputs for `opa eval`
├── scripts/
│   └── validate_mappings.py       # checks every control maps to ≥1 framework + has evidence ref
└── .github/workflows/
    └── validate.yml               # CI: catalog validation + `opa test`

Example: one control, defined once

# catalog/controls.yaml  (synthetic example)
- id: AC-2
  title: Account Management
  statement: >
    Accounts are provisioned, reviewed, and de-provisioned through an
    approved, auditable workflow with least-privilege defaults.
  implementation: identity-provider + access-review-cadence
  maps_to:
    nist_800_53: [AC-2]
    csf: [PR.AC-1, PR.AC-4]
    iso_27001: [A.9.2.1, A.9.2.2]
    cmmc: [AC.L2-3.1.1]
  evidence:
    - source: identity-provider
      artifact: quarterly-access-review-export
      cadence: quarterly

That single definition answers four frameworks and points at its own evidence. Change it once, and every crosswalk and SSP component downstream stays consistent.

---

---

Verify it yourself

# 1. Catalog integrity — every control maps to a framework and names evidence
pip install pyyaml
python scripts/validate_mappings.py

# 2. Policy tests — prove the AC-2 policy enforces what it claims
opa test policy-as-code/ -v

# 3. Run the policy against a sample input
opa eval -d policy-as-code/access-control.rego \
  -i policy-as-code/examples/review-violations.json \
  "data.controls.ac2.violations"

Both checks run automatically in CI on every push and pull request (see .github/workflows/validate.yml).

---

Design principles

1. Define once, map many — the control is the unit; frameworks are views onto it.
2. Evidence is part of the control — a control definition that doesn't name its evidence source isn't done.
3. Open standards first — OSCAL and published catalogs over proprietary formats, so it ports.
4. Reviewable like code — every change is a diff, every diff is a decision record.
5. Honest automation boundary — this scaffolds and validates structure; the human judgment about whether a control is adequate stays human.

Who it's for

GRC leads and security engineers in multi-framework, regulated environments who are tired of reconciling the same control across audits by hand.

---

License

MIT — see LICENSE.

Original work. All controls, mappings, and evidence references are illustrative and synthetic; nothing here reflects any organization's actual control implementation.