Reusable Masking Policies
Masking is only useful if the masked data is still usable. DBShifts masks deterministically: the same input produces the same output every time, so a customer ID masked in two tables still joins, and a foreign key still resolves. A policy captures a set of rules so the next project does not start from nothing.
Before you start
- A project with an analyzed schema, so columns are known.
- A decision about which columns are sensitive — the PII scan proposes, you dispose.
Steps
- 1
Configure masking rules on any project (Data Masking tool), then 'Save current as policy…'
- 2
Or click 'Suggest from PII scan' to seed rules from the server-side PII detection (regex + Luhn validation on sampled rows)
- 3
Apply a saved policy to any other project in one click — rules merge, the policy wins on conflicts
- 4
Strategies: hash, redact, fake, nullify, partial — previewed on live sample rows before you commit
What goes wrong
Detection is deterministic, and deliberately so
PII detection is pattern-based — regex plus validation such as a Luhn check on card numbers. It does not send your data to a model to be classified. That is a product commitment, not an implementation detail.
The scan proposes; it does not decide
A column named notes holding pasted email addresses will not match a pattern. Review the suggestions against what you know about the data before applying a policy to a real export.
Nullify breaks NOT NULL
Nullifying a column the target declares NOT NULL fails the insert. Use redact or fake where the column must hold a value, and keep nullify for genuinely optional fields.