Compliance Framework Pattern

How to map SOC 2 / ISO 27001 / GDPR / HIPAA controls onto your codebase + ops, so audits are evidence-driven, not theatre.

TL;DR (human)

Compliance frameworks are catalogs of controls. Each control is "the system must do X" + "show evidence". Don't build special compliance machinery — instead, design the system so the controls are natural outputs of normal practice. The audit becomes "show me the dashboards / runbooks / logs / runbooks that already exist" — not "build a binder for the auditor".

For agents

The frameworks (overview)

Most B2B SaaS pursues SOC 2 Type II first; ISO 27001 for international expansion; GDPR / LGPD / CCPA for global users.

The Five Trust Service Criteria (SOC 2)

Pick Security + the ones relevant to your contracts. Most B2B do Security + Availability + Confidentiality.

Type I vs Type II

• Type I: snapshot. "The controls were designed correctly at this date." Cheaper, faster.
• Type II: 6-12 month observation period. "The controls operated effectively over time." What enterprise buyers actually want.

Most products end up at Type II.

Map controls to existing practices

The trick: most of the controls are things this playbook already prescribes. Examples:

When you build the system per the playbook, you implement most controls naturally. Compliance becomes documentation, not engineering.

Evidence as a natural artifact

Auditors ask for evidence of controls. Examples of what they accept:

• Code review evidence: PR with manifest + reviewer approval (per ../governance/pr-intent-pattern.md).
• Access review evidence: quarterly RBAC review record + signed audit-ledger entries.
• Vulnerability triage: Snyk / Dependabot / triage tickets + closure timestamps.
• Backup verification: quarterly restore-drill report.
• Incident response: post-mortem documents (per on-call-rotation-pattern.md).
• Change management: ADR / RFC + PR-intent for every meaningful change.
• Encryption: KMS configuration + vault audit-log of key rotations.
• Monitoring: dashboard screenshots + on-call response records.
• Training: completion records for security awareness training.

If you have to invent the evidence at audit time, the control isn't real. The control is real when the evidence already exists in normal operations.

Quarterly access review

A specific, recurring compliance ritual:

1. Pull all role assignments + per-user capability lists.
2. Per team / per system owner: review the list.
3. Confirm each access is still appropriate.
4. Revoke what isn't (employees rotated out; projects ended; over-grants).
5. Document the review (audit-log; signed approval).

A system that makes this easy:

• RBAC store query produces the list.
• Stale-grant detection (no use in N days) flags candidates.
• Bulk revocation is a single command.
• Audit-ledger records the review.

Vendor management

Compliance frameworks require:

• Inventory of all third-party vendors / SaaS in your stack.
• Per-vendor risk assessment (what data do they touch? what cert do they hold?).
• Vendor SOC 2 / ISO copy on file.
• Annual review.
• Off-boarding procedure when a vendor is removed.

Maintain a vendor registry doc. Update as part of normal onboarding when adding a new service.

GDPR + LGPD + CCPA specifics

Common requirements:

GDPR / LGPD / CCPA overlap significantly. One implementation usually satisfies multiple.

Cookie consent (where applicable)

For user-facing web:

• Strictly-necessary cookies don't need consent.
• Analytics / marketing cookies require explicit opt-in (EU) or opt-out (CA).
• Banner: granular toggles; respects user choice; persisted.

Avoid: dark patterns ("Accept all" prominent vs "Reject" hidden); pre-checked boxes; "consent or leave" walls outside legal grounds.

HIPAA-specific (if you touch PHI)

• BAA (Business Associate Agreement) with cloud provider mandatory.
• Encryption at rest mandatory (no exceptions).
• Access logging per PHI access — beyond regular audit.
• Minimum necessary access — capability scoped tightly.
• Workforce training records.
• Annual risk assessment.

HIPAA scope creeps; carefully boundary which features touch PHI and which don't. A non-PHI feature that touches PHI mistakenly drags the whole product into scope.

PCI-DSS (if you touch card numbers)

Most products don't store cards — tokenise via Stripe / Braintree / Adyen. Your scope is the integration layer.

If you actually store card data, the scope is enormous (network segmentation, quarterly scans, annual audits, restricted personnel). Almost never worth it; use a tokeniser.

The auditor relationship

Auditors are not the enemy. They:

• Want to confirm controls work; not find faults.
• Accept reasonable evidence (no need to invent paperwork).
• Tell you up front what they need.

Conventions that help:

• A dedicated compliance lead (engineer + ops + legal triangle).
• Quarterly internal pre-audit (run the same questions; close gaps).
• Evidence in a shared drive with structure that maps to controls.
• Engineers respond to specific questions from the auditor; not "do anything they ask".

Common failure modes

• Compliance as a separate practice. Engineering builds; compliance bolts on. Slow + brittle. → Build controls into normal practice.
• Evidence theater. Generating documents at audit time that no one ever uses. → Evidence as natural artifacts.
• No quarterly access review. Auditor asks; you scramble. → Schedule + tool.
• Privacy policy ≠ actual practice. The policy says one thing; the code does another. → Policy reflects code; both reviewed together.
• GDPR DSAR runs as an ad-hoc script. Slow + error-prone. → Tooling per data-classification-pattern.md.
• PCI / HIPAA scope creep. One feature drags rest of product into scope. → Boundary deliberately.
• Vendor SOC 2 expired. Audit fail. → Annual review with calendar reminders.

Adoption path

1. Day 0: this playbook's practices in place; no compliance "program" yet.
2. Pre-audit: select framework (typically SOC 2 first); gap-assess.
3. Engagement: hire auditor; lead time 3-6 months.
4. Observation period (Type II): 6 months minimum; evidence collected continuously.
5. Audit report: typically completes 6-9 months after engagement starts.
6. Maintenance: annual re-audit; continuous evidence.

Tooling stack (typical)

See also

• rbac-pattern.md, vault-pattern.md, audit-ledger-pattern.md
• vulnerability-mgmt-pattern.md, dependency-hygiene-pattern.md
• data-classification-pattern.md, multi-tenant-isolation-pattern.md
• on-call-rotation-pattern.md, secrets-leak-postmortem-playbook.md
• threat-model-template.md
• ../../phases/06-operate/README.md — operate phase covers most compliance rituals.