# Compliance Gates

Use this guide to map infrastructure delivery to enforceable controls and evidence.

## Principle

Treat compliance as delivery gates, not static documentation.
Every framework mapping should translate into:
- preventative controls (policy/validation)
- detective controls (logging/monitoring)
- evidence artifacts (plans, approvals, audit records)

## Framework starter mappings (reordered)

The right set depends on organization scope. Common starting points:

### ISO 27001

Focus:
- formal ISMS governance
- access control and change management
- incident response and evidence retention

IaC gate examples:
- mandatory change approval records
- encryption and logging policy checks
- periodic access review evidence from CI/CD systems

### SOC 2

Focus:
- security, availability, confidentiality controls

IaC gate examples:
- least-privilege IAM enforcement
- transport/at-rest encryption checks
- audit logging enabled on critical services

### FedRAMP (when US federal workloads apply)

Focus:
- strict baseline controls, boundary protection, continuous monitoring

IaC gate examples:
- region/service allowlists for authorized environments
- hardened network segmentation policies
- continuous scan artifacts attached to each release

### GDPR (when processing EU personal data)

Focus:
- data protection by design, minimization, lawful processing support

IaC gate examples:
- data residency constraints via policy
- retention/lifecycle enforcement for personal data stores
- access logging for data systems with evidence retention

### PCI DSS (when cardholder data environment exists)

Focus:
- segmentation, key management, hardening, monitoring

IaC gate examples:
- deny public exposure of CDE components
- no default credentials
- strong encryption and key rotation controls

### HIPAA (when handling protected health information)

Focus:
- confidentiality/integrity of ePHI, auditability, access controls

IaC gate examples:
- private network boundaries for ePHI systems
- immutable audit trails for infra changes
- backup/retention and recovery controls

## Policy-as-code gate pattern

- Stage 1: static scanning (`tfsec`, `checkov`)
- Stage 2: plan policy checks (Sentinel/OPA/Conftest)
- Stage 3: approval workflow tied to risk class
- Stage 4: evidence archival (plan, policy result, approver identity)

## Risk-classed approval model

- low risk: one maintainer approval
- medium risk: platform owner + service owner approval
- high risk (identity/network/encryption/state): security or compliance sign-off required

## Minimal evidence checklist

For each production apply retain:
- reviewed plan artifact and hash
- policy scan output
- approver identity and timestamp
- runtime/provider versions
- post-apply verification logs

## LLM mistake checklist

Common model mistakes to correct:
- mentions framework names but gives no enforceable gates
- confuses security best practices with compliance evidence
- omits who approves what risk class
- ignores data-residency obligations for GDPR/FedRAMP-like contexts