pii-data-flow

# PII Data Flow ## Cardinal Rule **You cannot govern what you cannot see.** The PII dataflow is a first-class artifact — a map of *every* field that identifies a person, *everywhere* it lives (primary DB, cache, search index, backup, analytics, CRM, vendor integration). If the map doesn't exist, the system is not compliant, regardless of how good the code is. ## PII classification (LGPD Art. 5) | Class | Examples | Minimum controls | |---|---|---| | **Sensitive (Art. 5 II)** | CPF, race, religion, health, sexual orientation, political, biometric, genetic | encryption at rest + column-level access log + RLS + pseudonymization if used outside primary DB | | **Regular PII** | name, email, phone, address, IP, device ID | encryption at rest + RLS + retention policy | | **Pseudonymized** | hashed surrogate IDs | classified as PII if keyed lookup exists; non-PII only if re-identification is technically infeasible | | **Public / non-PII** | aggregated analytics (cell >= k), company names | no PII controls required | Sensitive PII triggers stricter retention (usually 5y max unless legal obligation), mandatory RIPD, and DPO review before new processing. ## The PII dataflow map (deliverable) For every PII field, the map records: ```yaml # Example entry in pii-inventory.yaml - field: users.cpf class: sensitive legal_basis: legal_obligation # per LGPD Art. 7 V (fiscal requirements) purposes: [billing, tax-reporting] storage: - primary: {table: users, column: cpf, en...