Compliance — guardrail packs, publish gate, exceptions

Compliance in CCX is a publish-time gate. Every time you publish a policy, the policy is evaluated against the guardrail packs you’ve bound to your tenant. Failures block publish; warnings surface but let you through. The gate runs in OPA against Rego rules — the same engine and the same language major compliance frameworks already standardise on.

Compliance frameworks overview Policy Compliance landing — every shipped framework plus the tenant’s own guardrail sets.

Shipped packs

Twenty-five packs covering 210 controls land out of the box. Highlights:

PCI-DSS v4.0 — cardholder data environment segmentation, default-deny, port-scoping.
ISO 27001:2022 Annex A — network access control family (A.8.20–A.8.23).
CIS Controls v8 — control 4 (secure configuration), control 12 (network infrastructure).
NIST 800-53 rev 5 — AC, SC, SI families.
HIPAA Security Rule — §164.312(a)(1), §164.312(e)(1).
SOC 2 — CC6.6 (logical access boundaries).
UK Cyber Essentials Plus — boundary firewall requirements.
Enforza baseline — our own opinionated pack: default-drop, no any/any/accept, no flat allows from the internet, etc.

Full list and per-pack control matrix on the Compliance page in the console.

Binding packs to your tenant

Sidebar → Compliance.
For each pack you want active, toggle Bound. Multiple packs can be bound at once — every bound pack runs on every publish.
The page also shows your tenant’s current pass-rate per pack across the policy catalogue, so you can spot which packs are clean and which have outstanding failures.

Guardrail set detail — the individual rules (controls) that make up a tenant pack.

What runs on publish

When you hit Publish in the policy editor:

Schema gate. Structural validation — sections present, rules well-formed, no dangling object references. Always on.
Compliance gate. The policy is rendered to its canonical YAML and handed to OPA along with every bound pack’s Rego bundle. OPA returns per-rule findings.
Verdict.
- Any fail finding → publish is blocked. The editor shows the failing pack, the rule that triggered it, and the human-readable explanation.
- Only warn findings → publish proceeds. Warnings show on the published version’s detail page and on the policy’s history row.
- No findings → silent pass.

Reading a finding

Each finding includes:

Pack — which guardrail flagged it (pci-dss-v4, cis-v8, …).
Control — the specific control reference inside the pack (e.g. PCI-DSS 1.2.1).
Severity — fail or warn.
Rule path — section + rule index that triggered the check.
Why — a one-sentence explanation written by the pack author. Most packs also link out to the control’s primary source.

Exceptions

Sometimes a rule legitimately violates a pack — a deliberate broad-allow on a non-production segment, a flat ICMP allow for diagnostics, etc. Two ways to handle it:

Per-rule exception. Open the rule, Exceptions tab, pick the control to exempt, justify in the textarea. Exceptions are audit-logged and time-boxed (default 90 days; configurable per tenant).
Pack unbind. If a pack consistently doesn’t fit your environment, unbind it from the tenant entirely. Recorded in the audit log.

Custom packs

Tenants on the Enterprise tier can upload their own Rego bundles. The pack format is plain OPA — a directory of .rego files with a manifest.json declaring the pack ID, version, and the controls it covers. Upload via the Compliance page → Custom packs → Upload bundle. The pack runs through a syntax + sandbox check before it becomes bindable.

What compliance does not do

It does not run at the engine. The engine never sees Rego — it just consumes the YAML the gate let through.
It does not retroactively flag historical versions. A pack you bind today only runs from today’s publishes onward.
It does not interpret intent — it pattern-matches against rule structure. A rule that says accept any/any/443 can’t be excused by the comment field.