Data security · Snowflake · PII architecture

Maximum security. But not a single dashboard still worked.

The vault system was watertight: PII out of the table, key stored separately, join needed for the real value. Watertight, until a dashboard fired that join without access. You don't get a masked value. You get an error.

Before & after
Crypto shredding
PII in the vault, key in the table
Step 1 · Original table
Name
Email
Postcode
Key
J. Smith
key-a1…
key-a1…
a1b2c3
↓
Step 2 · Vault table
Email_real
Postcode_real
[email protected]
EC1A 1BB
↓
Step 3 · Dashboard query
JOIN on vault
✗

JOIN fails without access. Dashboard breaks.

Access = see everything or nothing. No middle ground.

Dynamic masking policy
No vault. No join. Just the table.
One table · policy per column
Name
Email
Postcode
Salary
J. Smith
j.s@…
EC1A
£4,200
S. Brown
s.b@…
W1A
£3,800
Masking policy
↓
Dashboard query
SELECT * FROM customers
✓

Query always succeeds, for every role

Visibility per column, configurable per role.

See the difference per role

Click a role to see what the same query returns.

SELECT * FROM customers role: Administrator
Name Email address Postcode Salary
Each column has its own policy. Postcode for Analyst returns only the district, useful for regional analysis, without privacy risk. Salary is always visible for Analyst because that role compiles budget reports.
Maximum security does not need to exclude usability. That is a design choice.
← Back to all cases