Compliance Readiness

Phase 14 · Document 07 · Security, Privacy and Governance Prev: 06 — Audit Logs · Up: Phase 14 Index

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

Compliance is where security and privacy meet the law and the enterprise sales cycle. For a startup, "are you SOC 2 compliant? do you have a DPA? where is our data stored? are you EU AI Act ready?" are the questions that gate enterprise deals — often deciding the sale more than your model quality (Phase 12). For any company touching regulated data (health, finance, EU residents, children), non-compliance carries real penalties (GDPR fines reach the tens of millions / % of global revenue). And the EU AI Act has made AI itself a regulated category with obligations that scale by risk tier. The good news: if you've implemented docs 01–06, you've already built most of what compliance requires — compliance is largely about proving those controls exist and run. This doc maps the major frameworks, the artifacts you need, and how to be "audit-ready" without drowning a small team in process.

2. Core Concept

Plain-English primer: compliance is provable, documented control

Security/privacy (docs 01–06) is doing the right things. Compliance is proving you do them, against a named framework (a law or standard with specific requirements), with evidence (policies, logs, configs, attestations) that an auditor or customer can verify. Two failure modes: doing the controls but having no evidence (you fail the audit anyway), or having paperwork but the controls don't actually run (you pass the audit and still get breached). You need both — and the evidence should be a byproduct of real controls, not theater.

SECURITY/PRIVACY (01–06) = DO the controls.   COMPLIANCE = PROVE you do, vs a FRAMEWORK, with EVIDENCE (policies + logs [06] + configs + attestations).
   gap A: controls but no evidence → fail the audit.   gap B: paperwork but no real controls → pass the audit, still breached.
   goal: evidence is a BYPRODUCT of controls that genuinely run.

Who you are under the law: controller vs processor

Privacy law assigns roles. The data controller decides why/how personal data is processed (usually you, toward your users). A data processor processes data on the controller's behalf (your LLM provider is your processor; if you serve businesses, you may be their processor). This determines obligations and is formalized in the DPA (Data Processing Agreement) — the contract every processor relationship needs (02). Sub-processors (your provider, your cloud) must be disclosed and flowed-down.

The major frameworks (what each is for)

• GDPR (EU) / CCPA-CPRA (California) — privacy law. Core duties: lawful basis/consent, data minimization, purpose limitation, storage limitation (retention), and data-subject rights (access, erasure, portability, objection) — all of which you built in 02. Applies by residency of the person, not your location.
• SOC 2 — a security attestation (not a law) widely demanded in B2B SaaS. An independent auditor attests your controls against the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). Type I = controls exist at a point in time; Type II = controls operated effectively over a period (months). The most common enterprise gate.
• HIPAA (US healthcare) — protects PHI; requires a BAA (Business Associate Agreement) with any vendor touching PHI (including your LLM provider, if they'll sign one) and strict safeguards. Often pushes toward self-hosting/ZDR (Phase 6/02).
• PCI DSS (payment cards), FedRAMP (US gov), ISO 27001 (international security management) — domain/region-specific; same pattern (controls + evidence + audit).
• EU AI Act — the first broad AI-specific law. Risk-tiered: unacceptable (banned), high-risk (strict obligations: risk management, data governance, transparency, human oversight, logging), limited-risk (transparency duties — e.g., disclose users are talking to AI, label AI-generated content), minimal. Determine your tier and obligations. The NIST AI RMF (US, voluntary) is the governance counterpart (Govern/Map/Measure/Manage).

Data residency and sovereignty

Where data physically lives is itself a requirement. Many customers/laws mandate data stay in a region (EU data in the EU, etc.). This affects which provider region/endpoint you call, where you store logs/vectors, and whether you must self-host (Phase 6). Enterprise contracts often specify residency explicitly; a fail-closed residency check (don't route data to a non-compliant region) is the enforcement (Phase 8.09).

AI-specific governance (beyond classic compliance)

LLMs add governance concerns auditors increasingly probe:

• Model/AI governance — which models are approved, model cards/system cards for documentation (Phase 3), versioning and eval gates before deployment (Phase 12.08).
• Transparency — disclosing AI use to users (EU AI Act limited-risk), and AI-output labeling/watermarking where required.
• Training-data provenance & IP — what data trained/fine-tuned your model, licensing, and copyright exposure (Phase 13.06).
• Bias/fairness & human oversight — documented evaluation and a human-in-the-loop for consequential decisions (Phase 12.07/Phase 10.05).

The artifacts of audit-readiness (the deliverables)

Compliance is, concretely, a set of maintained documents + working controls + evidence:

• Policies: privacy policy, data-retention policy (02), incident-response plan (06), acceptable-use, access-control.
• Records: Data Processing Agreement(s), sub-processor list, a data map / RoPA (record of processing activities — what data, why, where, how long), DPIA (Data Protection Impact Assessment) for high-risk processing.
• Evidence: audit logs (06), access reviews, encryption configs (at rest/in transit), vendor security assessments, pen-test / red-team reports (01/Phase 12.07).
• Demonstrable rights handling: working access + erasure flows (02).

Compliance-automation tools (Vanta, Drata, Secureframe) help collect evidence continuously — turning audit-readiness into a background process rather than a fire drill.

The startup reality: right-size it

You don't need everything on day one. Right-size to your customers and data: a dev-tools startup selling to SMBs needs a privacy policy, a DPA with its provider, and basic security hygiene; the moment you chase enterprise or touch regulated data, SOC 2 Type II + DPA + data map + residency become deal-blockers worth pursuing early (SOC 2 Type II takes months of evidence). Treat compliance as continuous (evidence accrues from controls that run), not a one-time scramble.

3. Mental Model

   COMPLIANCE = PROVE you do security/privacy [01–06], vs a named FRAMEWORK, with EVIDENCE (policies + logs [06] + configs + attestations)
   need BOTH real controls AND evidence (evidence = byproduct of controls that genuinely run). controls-no-evidence → fail audit; paperwork-no-controls → breached.

   ROLES: data CONTROLLER (decides why/how — usually you) vs PROCESSOR (acts for controller — your PROVIDER is yours) → DPA contract [02]; disclose sub-processors

   FRAMEWORKS:
     GDPR/CCPA = PRIVACY LAW (minimize, retention, RIGHTS access/erasure [02]; by person's residency)
     SOC 2 = security ATTESTATION (Trust Services Criteria; Type I=point-in-time, Type II=over months) ← #1 B2B gate
     HIPAA = health PHI → BAA (+ often self-host/ZDR [6/02]); PCI/FedRAMP/ISO27001 = domain/region-specific
     EU AI ACT = AI-specific, RISK-TIERED (unacceptable=banned · high=strict · limited=transparency/disclose-AI · minimal); NIST AI RMF = US voluntary governance
   DATA RESIDENCY: where data physically lives is a requirement → provider region/log/vector location or SELF-HOST [6]; fail-closed residency check [8.09]
   AI GOVERNANCE: approved models + model/system cards [3] + eval gates [12.08] · transparency/labeling · training-data provenance/IP [13.06] · bias + human oversight [12.07/10.05]

   ★ ARTIFACTS: policies (privacy/retention/IR/AUP/access) · records (DPA, sub-processor list, DATA MAP/RoPA, DPIA) ·
                evidence (audit logs [06], access reviews, encryption, vendor assessments, PEN-TEST/red-team [01/12.07]) · working access+ERASURE flows [02]
   STARTUP: RIGHT-SIZE to customers/data; SOC2 Type II + DPA + data map + residency = enterprise deal-blockers → start EARLY (Type II = months). Continuous, not a scramble (Vanta/Drata).

Mnemonic: compliance proves — against a named framework, with evidence — that the controls you built in 01–06 actually run; know your role (controller vs processor) and your frameworks (GDPR, SOC 2, HIPAA, EU AI Act), enforce data residency, govern your models, and right-size it: SOC 2 + DPA + data map are the enterprise deal-blockers, so start early.

4. Hitchhiker's Guide

What to look for first: who are your customers and what data do you touch? That determines your frameworks (enterprise B2B → SOC 2 + DPA; EU residents → GDPR; health → HIPAA; high-risk AI use → EU AI Act). Then: can you produce evidence that your controls run?

What to ignore at first: chasing every certification. Right-size: get the framework your customers/data actually require; don't pursue FedRAMP for an SMB dev tool.

What misleads beginners:

• Treating compliance as paperwork. Paperwork without working controls = you pass and still get breached — evidence must reflect real controls (01–06).
• Doing controls but keeping no evidence. You fail the audit anyway — instrument so evidence (logs, configs) accrues automatically (06).
• Ignoring the DPA / processor role. Sending personal data to a provider without a DPA is a gap (02).
• Forgetting data residency. Routing EU data to a US region can breach contracts/law — fail-closed residency (Phase 8.09).
• Starting SOC 2 too late. Type II needs months of evidence — begin before the enterprise deal, not during it.
• Overlooking the EU AI Act. AI use now has its own risk-tiered obligations (even just disclosing users talk to AI).

How experts reason: they scope frameworks to customers/data, build compliance as a byproduct of real controls (01–06) with continuous evidence (automation tools), keep the core records (DPA, sub-processor list, data map/RoPA, DPIA for high-risk), enforce data residency (region routing or self-hosting), add AI governance (approved models, cards, eval gates, transparency, provenance), maintain working rights flows (access/erasure), and start the slow certifications (SOC 2 Type II) early.

What matters in production: the controls genuinely run and you can prove it; a DPA + correct provider tier/region; a current data map; demonstrable access/erasure; AI-specific governance; and audit-readiness as an ongoing state.

How to debug/verify: pick a control (e.g., "PII is scrubbed before logging") — can you show the policy, the code, and the evidence it runs? Can you produce a data map on request? Can you execute an erasure end-to-end (02)? Is EU data provably staying in the EU? Which EU AI Act tier are you, and do you meet it?

Questions to ask: which frameworks apply (customers/data/residency)? controller or processor — DPA in place? is evidence accruing from real controls? data map current? rights flows working? residency enforced? EU AI Act tier + obligations? SOC 2 started early enough?

What silently kills deals / triggers fines: no SOC 2/DPA when enterprise asks, paper controls that don't run, no evidence for real controls, residency violations, broken erasure, and unaddressed EU AI Act obligations.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• Compliance = proving (vs a named framework, with evidence) that the security/privacy controls of 01–06 actually run — you need both real controls and evidence.
• Know your role: controller (decides) vs processor (acts for controller) — your provider is your processor, formalized by a DPA; disclose sub-processors (02).
• GDPR/CCPA = privacy law (minimization, retention, rights incl. erasure), by the person's residency (02).
• SOC 2 = the #1 B2B security attestation — Trust Services Criteria; Type II (over months) is the common enterprise gate, so start early.
• HIPAA needs a BAA (often pushing to self-host/ZDR); PCI/FedRAMP/ISO 27001 are domain/region-specific (Phase 6).
• The EU AI Act is risk-tiered (unacceptable/high/limited/minimal) with obligations incl. transparency (disclose AI use); NIST AI RMF is the voluntary governance counterpart.
• Data residency is a requirement — control provider region/log/vector location or self-host; enforce a fail-closed residency check (Phase 8.09).
• Audit-readiness = maintained policies + records (DPA, data map/RoPA, DPIA) + evidence (audit logs, pen-tests) + working rights flows — right-size to customers/data and treat it as continuous.

9. Observations from Real Systems

• SOC 2 Type II is the recurring enterprise deal-blocker — startups that wait until a big prospect asks lose months; the ones that start early close faster.
• DPAs + sub-processor lists are standard B2B asks — buyers want to know your provider, region, and retention before sending data (02).
• Healthcare/finance push to self-hosting or ZDR — when a provider won't sign a BAA or guarantee residency, teams move to local/open-weight models (Phase 6).
• Compliance-automation tools (Vanta/Drata/Secureframe) turned audit-readiness into a continuous, evidence-collecting background process — now the norm for startups.
• The EU AI Act reshaped roadmaps — even low-risk apps now add "you're talking to an AI" disclosures and AI-output labeling to meet transparency duties.

10. Common Misconceptions

11. Engineering Decision Framework

COMPLIANCE READINESS (right-size to customers + data):
 1. SCOPE: who are your customers + what data? → frameworks: enterprise B2B → SOC 2 + DPA; EU residents → GDPR; health → HIPAA/BAA;
    payments → PCI; gov → FedRAMP; high-risk AI use → EU AI Act tier.
 2. ROLE: controller or processor? sign DPA(s); disclose sub-processors (provider, cloud) [02].
 3. CONTROLS = the real work of 01–06; make EVIDENCE a byproduct (audit logs [06], configs, access reviews); automate (Vanta/Drata).
 4. RESIDENCY: route to compliant provider region / store logs+vectors in-region / self-host [6]; fail-closed residency check [8.09].
 5. AI GOVERNANCE: approved-model list + model/system cards [3] + eval gates [12.08] + transparency/labeling + training-data provenance [13.06] + human oversight [10.05].
 6. RECORDS: privacy/retention/IR policies, DATA MAP/RoPA, DPIA (high-risk), working ACCESS + ERASURE flows [02].
 7. SLOW certs (SOC 2 Type II) → START EARLY. Treat compliance as CONTINUOUS, not a one-time scramble.

12. Hands-On Lab

Goal

Produce a compliance-readiness assessment for a sample LLM product: identify applicable frameworks, map controls (01–06) to evidence, and draft the core artifacts.

Prerequisites

• A sample product description (customers, data types, regions) and the controls built in docs 01–06.

Steps

1. Scope frameworks: from customers + data + regions, list which apply (SOC 2? GDPR? HIPAA? EU AI Act tier? residency?).
2. Role + DPA: determine controller/processor; note the DPA needed with your provider and your sub-processor list (02).
3. Control→evidence matrix: for each requirement, map the control (from 01–06) and the evidence that proves it runs (policy, config, audit log [06], test). Flag gaps.
4. Data map (RoPA): document what personal data you process, why, where it's stored/sent, and retention (02).
5. Residency + AI governance: state your data-residency posture and a minimal AI governance set (approved models, system card link, eval gate, AI-use disclosure) (Phase 3/Phase 12.08).
6. Rights demo: show working access + erasure flows end-to-end (02).

Expected output

A right-sized compliance-readiness assessment: applicable frameworks, controller/processor + DPA needs, a control→evidence matrix with gaps, a data map, a residency + AI-governance statement, and demonstrated rights handling.

Debugging tips

• A control with no evidence is an audit failure waiting to happen — instrument it (06).
• Evidence with no real control is theater — verify the control actually runs.

Extension task

Pick one framework (e.g., SOC 2) and draft the control list + the evidence you'd collect for a Type II period; estimate the timeline.

Production extension

Adopt a compliance-automation tool to collect evidence continuously; enforce residency at the gateway (Phase 8.09); wire eval gates + model cards into the AI governance record (Phase 12.08).

What to measure

Frameworks correctly scoped, control→evidence coverage (gaps = 0), data-map completeness, residency enforced, rights flows working, AI-governance artifacts present.

Deliverables

• A compliance-readiness assessment (applicable frameworks + role + DPA).
• A control→evidence matrix (mapping 01–06) with a gap list.
• A data map (RoPA) + a residency + AI-governance statement + demonstrated access/erasure.

13. Verification Questions

Basic

1. What's the difference between doing security/privacy and being compliant?
2. What is the controller-vs-processor distinction, and where does the DPA fit?
3. What is SOC 2, and how do Type I and Type II differ?

Applied 4. How do the GDPR controls you built in 02 map to compliance evidence? 5. What does the EU AI Act add beyond GDPR, and how do risk tiers work?

Debugging 6. An enterprise prospect asks for SOC 2 Type II next month. Why is that a problem, and what do you do? 7. A control runs but you can't prove it in an audit. What's missing?

System design 8. Design the compliance posture for a healthcare LLM product serving EU + US customers.

Startup / product 9. As an early-stage startup, how do you right-size compliance so it enables deals without overwhelming the team?

14. Takeaways

1. Compliance is proving — vs a named framework, with evidence — that the controls of 01–06 actually run (you need both controls and evidence).
2. Know your role and sign DPAs (provider = processor); GDPR/CCPA govern privacy by the person's residency (02).
3. SOC 2 Type II + DPA + data map are the enterprise deal-blockers — start the slow ones early; HIPAA needs a BAA; the EU AI Act is risk-tiered.
4. Enforce data residency (region routing or self-hosting, Phase 6) and add AI governance (approved models, cards, eval gates, transparency, provenance) (Phase 12.08).
5. Right-size to customers/data and treat compliance as continuous — evidence accrues from controls that genuinely run (06).

15. Artifact Checklist

• A framework-scoping doc (which apply, by customers/data/region) + role + DPA needs.
• A control→evidence matrix mapping docs 01–06, with a gap list.
• A data map (RoPA) + residency posture + (high-risk) a DPIA.
• An AI-governance record (approved models, cards, eval gates, AI-use disclosure).
• Working, demonstrable access + erasure flows + a plan for slow certs (SOC 2 Type II).

Up: Phase 14 Index · Phase 14 complete → next phase: Phase 15 — Startup Playbook