Dynamic data masking (DDM) never touches the stored bytes — encryption and backups protect those. Instead a policy engine intercepts every query at read time and rewrites each column's value based on who is asking:
state(role, col) = MASKED if sensitivity(col) ≥ floor
= policy[role][col] otherwise
exposure(state) = 1.0 (visible) · 0.4 (partial) · 0 (masked)
Risk = 100 · Σ w(col)·exposure(state(role,col)) / Σ w(col)
Each column carries a fixed sensitivity weight w(col) — an ID is 0, a card/SSN is 1.0 — and every role has a base policy (an admin sees names in the clear, an analyst gets them pseudonymized, the public API sees almost nothing). The regulatory mask floor slider models a compliance rule like PCI-DSS or GDPR that overrides even the DBA's own policy once a column's sensitivity crosses the floor — lowering it forces more columns to mask for every role, including admins.
- Role — swaps the base masking policy applied to each column.
- Regulatory mask floor — a hard ceiling on visibility that no role can bypass below it.
- Query rate — how often a simulated read hits a random row; each hit is what the audit trail records.
- Audit logging — when off, queries still execute but leave no trace, exactly like a database with masking but no audit log turned on: a real gap regulators flag.
This is the same layered model production databases use: encryption at rest stops a stolen disk, access control (RBAC) stops the wrong login, dynamic masking stops the right login from over-seeing, and the audit log is what proves it happened. This 2D view renders the same table as a flat grid — drag to pan, scroll/pinch to zoom.