Lesson 56 — Compliance

Stack: GDPR / SOC 2 / ISO 27001 · Project: TicketFlow Status: Published — the regulatory framework from the backend's view Prerequisite: Lesson 55 — Scaling

Objectives

1. Place GDPR in TicketFlow's data life cycle: lawfulness, minimization, rights and the proofs the backend must be able to show.
2. Understand SOC 2 / ISO 27001 as control systems (not paperwork): what they audit and which evidence the backend produces.
3. Design the compliance audit: the append-only audit log (23), retention, and the system's internal DPO.

1. GDPR in the data's life cycle

GDPR (23 built the how; here the framework): the operating PRINCIPLES: (1) lawfulness: each datum's legal basis — the buyer: contract performance (the sale); marketing: revocable consent (15's checkbox); (2) minimization: only the necessary datum — checkout asks for email, NOT the national ID (23: the datum you don't collect you don't protect); (3) purpose limitation: the purchase's email does not feed the ad profile without a new basis; (4) accuracy and storage limitation: retention (§3); (5) integrity and confidentiality: 22-23's encryption/security; (6) accountability: BEING ABLE TO PROVE IT (§4's processing record).

The RIGHTS and their backend implementation (23 built them; here the full map): access (23's export), rectification (the editable profile), erasure (deletion with the exceptions: INVOICING is retained by law — the money's datum is not deleted, it is anonymized), portability (the export in machine-readable format: 23's JSON), objection/restriction (the profile's flag), and breach notification (47's incident with data: 72 h to the regulator — §4's breach runbook).

2. The data map (the document the DPO asks for)

The record of processing activities (Art. 30): the map of WHICH datum, for WHAT purpose, LEGAL basis, WHERE it lives, HOW LONG it is retained and WHO touches it:

The map's three keys: the card datum LIVES at the gateway (23: never in your DB — §3's PCI); the map IS the document erasure/portability consult (what to delete? the map says it); and the map lives in docs/compliance/ (48: docs-as-code) with quarterly review.

3. SOC 2 / ISO 27001: the controls the backend produces

SOC 2 (and its cousin ISO 27001) audit CONTROLS operating: not "there is a policy", but "the policy executes and there is evidence". The controls TicketFlow's backend ALREADY produces with the course:

The senior backend's lesson: compliance gets BUILT with the course's same engineering (23/45/47) — the certifier's audit asks for the evidence and the course's tools generate it by themselves. SOC 2's real cost: 80% is organizing what good engineering already does; the remaining 20% is the record's and the DPO's paperwork.

4. The audit log and retention: the system that answers the auditor

The audit log (23) completed into a system: append-only (no UPDATE/DELETE: 21's DB permission), with who/what/when/result/origin, and the auditor's queries: "who saw user X's datum?", "who downloaded the export?", "who changed event Y's price?" — each one is ONE query (45: the auditor's lookup). Retention by type (§2's map): the audit log 12 months hot + 2 cold (45: the diagnostic log's retention IS different: 30 days); the buyer's datum 5-6 years (fiscal); marketing consent: the opt-in's evidence stores the date and the consent version's text ("they said yes to THIS version" is the auditor's proof).

The breach runbook (the 72 h): detect (46's alert), scope (47: the protocol), contain (41's flag/rollback), notify (the regulator + the affected if high risk: 48's doc template), and the postmortem with the regulatory action closed. The runbook gets WRITTEN TODAY (48: the doc with expiry): breach day improvises nothing with the clock running.

5. The system's internal DPO: automating compliance

What the backend automates of compliance (the "internal DPO"): (1) the export/erasure as an API with SLA (23: 30 legal days, your system does it in minutes) and the audit of each execution; (2) the data map generated (00b's schemas annotated with basis/retention: 48's reference that the Art. 30 record consumes); (3) retention as a job (31: expiring data purges ITSELF with the purge audited); (4) the PII scan (the test failing if a new free-text field enters a table without a legal-basis annotation — compliance's linter); (5) the SOC 2 evidences as system reports (the login report, the access report: §4's queries on 31's cron). The closing principle: compliance is not a separate project: it is the observable consequence of the course's engineering — every control is already there; what remains is documenting and proving it.

Self-assessment

1. The 6 GDPR principles: which legal basis does the buyer's email have and which marketing's? Which exception prevents deleting the money's datum?
2. The Art. 30 map: why does the card datum never live in your DB, and which document does the DPO consume?
3. What does SOC 2 audit, and which evidence does each course control produce (§3's table)? Which is the certificate's 80/20?
4. The audit log: which 3 auditor queries does it answer, and what retention does each datum type have?
5. What does the "internal DPO" automate, and why is compliance a consequence of the course's engineering?

Continue with the exercises. The solutions only after trying it yourself.