Most people arrive at a test data decision from one of two directions. Either releases are waiting a fortnight on a DBA ticket for an environment refresh, or somebody asked what customer data is sitting in the dev environments and the answer took three days to assemble.
Those two problems pull in opposite directions, which is why the requirement usually gets written by whoever felt the pain first. Engineering asks for speed. Security asks for coverage. The platform you end up with solves one of them and gets worked around for the other.
Underneath both sits a change in what test data management has to cover. It used to mean one requester: a developer waiting while a DBA restored a backup and ran a masking script over it. Today the same production-shaped data feeds QA, performance engineers, analysts, model training pipelines, third-party processors and auditors, and each needs a different shape of it. That is the practical difference between traditional and modern test data management. The scope now reaches well past development and QA, and protection is chosen according to the data and the purpose rather than applied uniformly to everything.
Five things worth checking before you sign. They follow the order a data request actually travels in.
1. Discover: classification that stays current
Ask a vendor how sensitive data gets found and you will usually get a good answer about the first scan. The more useful question is what happens in month seven.
Take a support agent who pastes a card number into a case note because the customer read it out over the phone. The column is called CASE_NOTES, the field is free text, and the value has no shape a schema scan recognizes. That note is now in every copy of the CRM database, including the ones in development.
It is an ordinary thing to happen, and it is invisible to discovery that stops at the schema.
- CASE_IDno match
- AGENT_IDno match
- CASE_NOTESno match
- CREATED_ATno match
Every column name passes inspection. Nothing here is flagged as sensitive.
An agent pasted a card number into a case note because the customer read it aloud. The field is free text, so the value has no shape a schema scan can recognize.
Mage Data’s discovery is patented and score-based, and it reads free-text and unstructured content rather than column names alone, so protection follows what was classified in the content. How discovery and classification work.
Ask this: “A developer adds a column next sprint, and an agent pastes an account number into a notes field. What makes either of them get masked?”
Worry if: the answer is that you add it to the rule set. That is a maintenance commitment, and it tends to decay when the person who maintained it moves on.
2. Protect: irreversibility you can evidence, per method
This is the criterion buyers most often get wrong, and the legal position is clear enough to plan against.
The European Data Protection Board’s Guidelines 01/2025 on Pseudonymisation state that pseudonymized data which can be attributed to a person using additional information remains personal data under Recital 26 GDPR, and that the assessment has to account for information reasonably likely to be available, including information outside your control. An insurer that tokenizes policyholder names and keeps the mapping table in the same schema has built a sensible safeguard against casual browsing, and has not changed its regulatory position.
The Court of Justice of the European Union’s September 2025 judgment in EDPS v SRB (C-413/23 P) adds a nuance worth taking to your own counsel: identifiability is assessed relative to the recipient, so the same dataset can be personal data for a team holding the key and not for a downstream consumer who cannot re-identify it.
Can attribute every token back to an institution using information it already has.
Cannot attribute the tokens using information reasonably likely to be available.
The assessment must account for additional information reasonably likely to be available, including information outside your control. The burden of showing a recipient cannot re-identify sits with you.
So the question is not whether a platform masks. It is which method was applied to which field, whether that method can be undone, and who holds the key if it can.
Mage Data selects the method per field from the classification rather than applying one treatment to everything, and states reversibility per method. Protection methods.
Ask this: “List every method and mark each reversible or irreversible. For the reversible ones, where is the key and who authorizes a reversal?”
Worry if: you get “all our masking is irreversible” without a method list behind it.
3. Preserve utility: data that is still fit for purpose
If protection breaks the data, protection gets switched off. This is a common route back to unmasked copies, and it rarely appears in a risk register because it presents as a delivery problem.
A worked example from capital markets. An analyst asks for ten days of trades in one sector, plus the same window last year, to study institutional flow. They have no need to know who traded, so you mask the counterparty name. That is not enough on its own: an exact volume on an exact date can be matched against public trade prints until the counterparty comes back out. So you generalize the quantity into a number in the same range, and now trade value no longer equals quantity times price, and commission no longer follows trade value. The dataset fails its own arithmetic. The analyst rejects it, and so would an auditor, for different reasons.
The scale of the underlying problem is well documented. Writing in Nature Communications in 2019, Rocher, Hendrickx and de Montjoye estimated that fifteen demographic attributes would correctly re-identify 99.98% of Americans in any dataset. None of that concerns the name field.
Fit-for-purpose is the phrase that matters here. Protected data has to remain fit for the purpose it was requested for, and three properties decide whether it does. Format, so identifiers keep their shape and joins resolve. Distribution, so the statistical signal the analyst or model depends on is still present. Consistency, so the same input produces the same output in the Oracle table, the file in object storage and the extract that lands in your cloud warehouse.
Mage Data’s masking is deterministic across systems, which is what holds referential integrity once data crosses a platform boundary. Test data management.
Ask this: “Generalize a quantity field so it cannot be matched against public data, then recompute every dependent field. On our schema.”
Worry if: the answer becomes a services engagement, a custom script, or a conversation about why you would not want to do that. All three are the same answer.
4. Govern: one policy, fit for purpose for every consumer
Most platforms govern by environment: one rule for development, another for QA, another for staging. That settles one question a request raises and leaves two open. A complete policy has to decide where the data is going, who is asking for it and why, and how it should arrive.
Start with how. Take a mid-size bank running an Oracle core, a cloud warehouse for analytics and file-based reconciliation feeds landing in object storage. Three destinations, three different shapes of request, and no single mechanism serves all of them.
In-place masking handles the Oracle clone the DBA team already refreshes. The warehouse extract needs protection applied in transit, because the point is that unprotected data never lands at the destination. The reconciliation files need something watching the bucket, because they arrive continuously and nobody is going to run a job for each one.
When a platform only does the first of those, the second gets handled by a script somebody wrote and the third by whoever is on shift. Neither appears in the compliance report. The mechanism a tool supports well tends to become the architecture, and what does not fit becomes an exception path sitting outside whatever governance the platform provides.
Then add who and why. The same table requested by two people is not the same request. A developer building a feature needs realistic data, fully de-identified, with enough context preserved that the application behaves normally. A DBA diagnosing or patching a system needs the database with sensitive values redacted. A user acceptance tester replaying a business scenario may need some real values, with the rest de-identified. A model training pipeline needs de-identified data that keeps its demographic and statistical shape, often as a file or JSON rather than a table. An analyst or AI agent working close to production needs data with its context preserved, not raw records.
Those dimensions multiply. Five kinds of consumer across three destinations is fifteen combinations, and every one configured separately is another place for the rule to drift. A modern platform holds one universal policy and lets it decide, per request, what each consumer receives, in which form and by which route. That is what fit for purpose means at the policy level.
Mage Data runs several delivery paths from a single policy set, including in-place masking, secure data provisioning with protection applied in transit, secure file gateways, database virtualization and self-service provisioning. The classification and the protection rule are defined once. The policy then sets the treatment per consumer and purpose, whether realistic de-identified data for development, redaction for database support, partially real data for acceptance testing or distribution-preserving data in the requested format for model training, and every route enforces the same decision.
Ask this: “How many places do I define this rule if a developer, a DBA and a model pipeline each need the same table, through three delivery paths?”
Worry if: the answer is one per path or one per team, described as flexibility.
5. Prove: evidence a third party will accept
The deliverable is not a protected environment. It is a protected environment you can evidence, for a specific date, to somebody who does not work for you.
India’s Digital Personal Data Protection Rules, 2025, notified in November 2025 with the security obligations taking effect eighteen months later, are more specific about method: Rule 6 names encryption, obfuscation, masking or the use of virtual tokens among the minimum safeguards a data fiduciary must take.
A risk assessment is a written document about a data flow with somebody’s name attached to it. Every copy of production that feeds a test suite, a dashboard or a model is one of those flows. The question stops being whether you protected the data and becomes whether you can show it for a named environment on a named date.
Mage Data records classification, protection method, requester and timestamp per provisioned copy, and exports it. That record comes from the same Data Security Platform that discovers and protects the data, which is why Mage Data’s test data management is assessed as part of data security rather than beside it. Mage Data is included in Gartner’s Market Overview: Data Security Platforms and Market Overview: Data Masking and Synthesis, and on Gartner Peer Insights it is the highest-ranked platform over the past 12 months in both Data Masking and Synthesis and Test Data Management.
Anonymous Customer Reviews 
Gartner, Market Overview: Data Masking and Synthesis, Joerg Fritsch, Andrew Bales, Anson Chen, 19 August 2026, G00860066. Gartner, Market Overview for Data Security Platforms, Q4 2026. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences and should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. GARTNER and PEER INSIGHTS are trademarks and service marks of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.
Ask this: “For a named environment on a named date, what was in it and how was it protected?”
Worry if: the answer stops at a dashboard view. Dashboards are useful for running the program day to day; an assessor needs an exportable record for a specific environment and date.
Take This Into Your Evaluation
Two things are worth doing before you shortlist anyone.
- Count your non-production environments and find out how many hold data derived from production; the number is usually higher than the architecture diagram suggests.
- Take one table from your own estate, with a foreign key chain and one calculated column, and use it as the artifact in every vendor conversation. A specification you supply is worth more than a feature matrix a vendor supplies.
The evaluation guide Coming soon
The five criteria above are the short version. The full guide turns them into six weighted dimensions with 1-3-5 scoring anchors, so two people scoring separately mean the same thing by a 4. It adds twelve demo questions, a proof-of-concept checklist for the stage where the decision actually gets made, a worksheet with columns for evidence and gaps, and the regulatory obligations behind each dimension so privacy counsel can engage with a tooling decision.
It is built to be worked through by a committee across a live evaluation, and it contains no ranked list and no scores we filled in.
You’re not stuck with the TDM tool you bought a decade ago
Mage Data runs alongside your current tool, so nothing stops while you move. Policy migration and side-by-side validation keep the move low-risk.
FAQs
What makes test data management "modern"?
Scope, method and speed. Traditional test data management served developers and QA, applied one masking treatment to everything, and delivered full copies of production on a DBA's schedule. Modern test data management delivers data that is fit for purpose and born compliant. Fit for purpose means every team that legitimately requests data, including analytics, model training and third parties, gets it in the shape its purpose needs, with the protection method chosen per field according to the data, the consumer and the use. Born compliant means sensitive data is masked before it leaves production, so there is no unprotected copy to clean up later. Delivery is self-service in minutes rather than by ticket in days, evidence is recorded for each copy, and test data sits inside the data security platform rather than beside it, governed by the same policy as everything else.
How does Mage Data provision test data without filling storage with copies of production?
In several ways, each chosen per request under the same policy. Database virtualization is the most direct: one masked golden snapshot is shared by many writable virtual copies, each holding only its own changes, which cuts non-production storage by up to 90% and brings provisioning down from days to minutes. Because masking is applied when the snapshot is created rather than after a clone exists, every copy taken from it is protected on arrival. Intelligent subsetting delivers a referentially intact slice instead of the full database, so a test that needs a few thousand customers does not carry millions. Secure data provisioning applies masking in transit, so the target receives protected data and no unmasked staging copy is created on the way. Files are protected as they move, in the format the consumer asked for. And self-service refresh replaces the long-lived copies teams otherwise keep just in case.
Will masked data still work for testing and analytics?
It depends on whether protection is fit for purpose or blanket. Blanket redaction destroys format, distribution and consistency, and will break both a test suite and a model. Mage Data selects the method per data element from classification results, so an identifier keeps its shape under format-preserving encryption and joins survive, a date of birth becomes an age band and the statistical signal is preserved, and deterministic output means the same value masks identically across systems.
What evidence can we give an auditor about non-production data?
A retained, exportable record per provisioned environment: what was discovered, how it was classified, which protection method was applied, who requested the copy and when. That is what PCI DSS Requirement 6.5.5 testing procedures and ISO/IEC 27002 control 8.33 effectively ask for, and it is what Mage Data produces for each copy.
How does Mage Data compare to other test data management tools?
Mage Data delivers test data management as part of its Data Security Platform, and is assessed in both categories. It is included in Gartner's Market Overview: Data Security Platforms and Market Overview: Data Masking and Synthesis, named a Leader in KuppingerCole's Leadership Compass: Data Security Platforms (Q4 2026), and is the highest-ranked platform on Gartner Peer Insights over the past 12 months in both Data Masking and Synthesis and Test Data Management. Bloor Research also named Mage Data a Champion in its Test Data Management (2025) Market Update. Rather than take that on trust, run the five questions in this article at every vendor on your shortlist, including us.
Sources
- European Data Protection Board, Guidelines 01/2025 on Pseudonymisation. edpb.europa.eu
- Court of Justice of the European Union, EDPS v Single Resolution Board, C-413/23 P, judgment of 4 September 2025. curia.europa.eu
- Rocher, Hendrickx and de Montjoye, Nature Communications 10:3069 (2019). doi:10.1038/s41467-019-10933-3
- PCI DSS v4.0 Summary of Changes, recording the move from Requirement 6.4.3 to 6.5.5. pcisecuritystandards.org
- California Privacy Protection Agency, amended CCPA regulations effective 1 January 2026. cppa.ca.gov
- Ministry of Electronics and Information Technology (India), Digital Personal Data Protection Rules, 2025, Rule 6 (reasonable security safeguards). meity.gov.in
- Bloor Research, Test Data Management (2025). Mage Data analyst reports
- Gartner Peer Insights, Mage Data reviews in Data Masking and Synthesis and Test Data Management. gartner.com/reviews
- Gartner, Market Overview: Data Security Platforms; Market Overview: Data Masking and Synthesis. Subscription; cited by title.
- KuppingerCole Analysts, Leadership Compass: Data Security Platforms (Q4 2026). kuppingercole.com
- ISO/IEC 27002:2022, control 8.33 (Information used for testing). Paywalled; cited by control number only.