Static, dynamic or transformation during extraction?
Static masking produces transformed stored data. Dynamic masking changes what a permitted query or user sees while the underlying values remain. Transformation during extraction changes fields on the path to the target environment. These designs have different trust boundaries. Check whether raw values are present in staging tables, exports, logs, backups or privileged access; a masked UI does not demonstrate that the target dataset is transformed.
Which relationships must survive?
List the fields used to join records, including identifiers shared between databases. Require consistent transformation where the test needs that link, and keep the scope no larger than necessary. Check collisions, uniqueness, null handling and constraints. For source subsets, select relevant records and collect required related rows before validating the transformed result. Connector-specific support belongs in the proof of concept.
What should your acceptance check include?
Include direct identifiers, free text, rare combinations, relationships and places where raw values can escape. Verify the required business query after transformation, then test access boundaries and a failure path. Document residual disclosure risks and the intended users. Pseudonymisation and anonymisation are different concepts; the chosen method alone does not establish the legal status of an entire dataset.
Illustrative scenarios and editorial acceptance criteria; not measured product benchmarks.
References and further reading
- Tonic Structural: subsetting order and relationships
- Delphix: masking workflow
- GDPR: Article 4 and Recital 26