Many services read one shared customer database. How would you decide where personal-data redaction lives — database masking policies, restricted views, the application layer, or a separate tokenised store — and how would you prove the choice holds?

## Decision frame **1. Who are the readers, and is there a chokepoint?** Enforcement must sit at or below the narrowest layer everyone passes. Direct SQL by many teams, BI tools and analysts means the engine is the only chokepoint. A single owning service in front of the data can be the chokepoint — but only if credentials are not shared and nobody can bypass it. **2. How sensitive is the field, and do you need the raw value at all?** Fields you never operate on (card number, national ID) are candidates for tokenisation or write-time truncation. Fields needed for matching but not display (email for dedupe) can be stored as a keyed hash plus a masked display copy. Fields needed in full for business logic must be stored and therefore governed. **3. What must still work?** Joins, uniqueness, search and analytics constrain the choice. Tokenisation preserves equality joins when tokens are stable. Application-level encryption kills range queries. Views and column grants preserve everything the projection still contains. ## Mapping controls to jobs - **Restricted views + column privileges** — real authorization, uniform across every client, fail-closed when columns are added. This is the backbone: no application role holds direct SELECT on a table carrying PII. - **Dynamic masking policies** — reduce casual exposure for roles that legitimately query the table (support, on-call tooling). Never the sole control, because predicates leak. - **Application-layer redaction** — the only place with request context: purpose of use, consent state, tenant, per-field scopes from the access token. Strong policy expressiveness, weak enforcement guarantee. - **Tokenisation / separate PII store** — strongest reduction: the operational database cannot leak what it does not hold, and audit scope shrinks to the vault. Costs a network hop, an availability dependency, and a migration. - **Static masking** — mandatory for non-production. Any strategy that leaves real PII in a restorable dump used by developers has already failed. ## Cross-cutting concerns that decide the argument **Copy paths.** Query-layer redaction does nothing for backups, logical replication, CDC into the warehouse, and CSV exports. Whichever design you pick, enumerate every path data leaves by and state the control on each. This is usually where a plausible design collapses. **Exemptions and auditability.** Someone can always see the raw value. Name who, make it a role requiring elevation, and log every read through it. "Who saw this customer's national ID last quarter" should be answerable. **Change cost.** Views are versioned objects with a release process; masking policies are catalog changes; tokenisation is a migration plus a runtime dependency. Match the cost to the sensitivity rather than applying the heaviest control everywhere. **Verification.** Design an assertion suite: for each role, a test that queries every sensitive column and expects denial; a test that new columns default to hidden; a check that non-production datasets fail a PII scan; a review that nothing sensitive is granted to PUBLIC. Controls without tests decay silently. ## The answer to give Enforce with database privileges and views because they are the only layer no consumer can skip; use masking policies as ergonomics for trusted staff; move the most sensitive fields out of the database entirely; and treat exports, backups and non-production copies as first-class parts of the design rather than afterthoughts.