Self-Service BI, Twelve Personal Data Columns, Six Weeks to Go-Live
Corvant Bank is deploying a self-service BI layer over its customer warehouse for 1,800 users across six countries. The privacy office classified 12 columns as personal data, including national ID, date of birth, and full address. The security team's proposal is to apply static masking in the warehouse by zeroing or hashing those columns in the analyst schema. Analysts object that a hashed national ID breaks joins to the case-management system, and that date-of-birth truncation destroys the age-band logic in 30 existing reports. A fraud analyst group already holds an exempt role that sees raw values. The bank operates under GDPR-style rules, and the local regulator requires purpose limitation; the fraud team's lawful basis differs from marketing's. Go-live is in six weeks.
1. Evaluate static masking in the warehouse against dynamic, purpose-aware controls, and recommend an approach. Justify your answer against joins, existing reports, and lawful basis.
Read the worked answer
Why static masking fails here. Hashing the national ID in the analyst schema breaks the join to case management unless the same salt and algorithm are applied on both sides - and if they are, the hash is a stable pseudonym that still joins, so anyone who can compute it can re-identify. National IDs are low-entropy and often enumerable; an unsalted hash is reversible by brute force in minutes, and a salted one is reversible by anyone holding the salt. Zeroing the column has the same effect on joins. Truncating DOB breaks 30 reports because those reports encode cuts designed against full precision.
Static masking therefore buys a compliance artefact at the cost of duplicate pipelines and broken analytics, and it will be circumvented by an extract within a quarter.
Recommendation: dynamic, purpose-aware controls.
- Keep raw values in a restricted base layer; expose through views or the semantic layer with masking applied at query time by role.
- Preserve joinability with a random, non-derived surrogate member key used as the join key everywhere. Never let a pseudonymized field serve as the join key.
- For general users expose age band plus a DOB-verified flag; keep full DOB behind an elevated role. Rebuild the 30 reports against the band rather than truncated dates.
- Split access by purpose, not seniority. Marketing (consent) and fraud (legal obligation or legitimate interest) have different lawful bases; sharing an AD group leaks purpose.
- Where export is unavoidable, tokenize with format-preserving encryption and keep the token vault outside the warehouse.
GDPR point. Hashing is pseudonymization, not anonymization, whenever a key or salt exists - the data remains personal data and the obligations travel with it.
2. Design the control set for the exempt fraud role and for re-identification risk in published reports.
Read the worked answer
Fraud exempt role.
- Named individuals, time-bound entitlement (for example 90 days) with automatic expiry and written re-justification.
- Documented purpose and lawful basis per user, with privacy office sign-off before grant.
- Full session logging with query text retained; monthly review by someone outside fraud; alerts on bulk export or anomalous row counts.
- A break-glass path for genuine urgency - granted, logged, reviewed within 24 hours - rather than an informal workaround.
- Quarterly recertification by the fraud head, with segregation of duties so the same person cannot grant and use access.
- No local downloads; exports require a ticket and are tokenized.
Re-identification in published reports.
- Suppress any cell below 5, and apply complementary suppression so a suppressed cell cannot be recovered by subtracting from a published total - the classic error is suppressing one of three cells, which reveals it.
- Treat quasi-identifiers as a set: DOB plus postcode plus sex is often unique. Generalize to age band and partial postcode before publishing externally.
- Round counts or apply small-cell perturbation for external distribution.
- Test the rule against the last 12 months of reports: how many rows would be suppressed, and does suppression break trend analysis? If it does, aggregate to a level where it does not.
Honest limitation. Masking and suppression reduce but do not eliminate re-identification risk. The residual risk should be explicitly accepted and recorded by the privacy office, not assumed away by the control set.