Your ERP project is entering user acceptance testing. Key users want an environment that feels like real life, the integrator is asking for realistic data, and someone suggests the quickest fix: restore a production backup into the sandbox. By the next morning the problem is solved. For the project, at least.
For the company, you have just duplicated your customer files, payroll data, supplier bank details and commercial correspondence into a less protected environment, open to contractors and sometimes located outside the European Union. This guide covers the five ways to build ERP test data, their strengths and traps, what to anonymise first, how to keep the data consistent, and a ten-point checklist to validate before opening the test environment.
Why a raw copy of production in testing is a GDPR risk
The temptation is understandable: nothing looks more like production than production. But three GDPR principles stand squarely in the way (regulation text on EUR-Lex).
- Purpose limitation (Article 5(1)(b)): data collected to invoice a customer or pay an employee was not collected to test software. Reusing it in testing is a change of purpose unless you can document a compatible legal basis, which is rarely defensible.
- Data minimisation (Article 5(1)(c)) and storage limitation (Article 5(1)(e)): a test cycle does not need ten years of payroll history, and the copy often stays in place for months after the project ends.
- Security and data protection by design (Articles 25 and 32): a test environment rarely has the same access control, logging and encryption as production. Data protection authorities such as the French CNIL recommend developing and testing in environments separate from production, using fictitious or anonymised data (CNIL, Testing your applications, in French).
In an ERP, exposure is at its highest because the data cuts across every function:
- HR and payroll data: salaries, sick leave, bank details, sometimes national insurance or social security numbers. This is the most sensitive scope, covered in our article on the GDPR risks of HR and payroll modules.
- Third parties: customers, suppliers, contacts, addresses, emails, commercial terms.
- Banking data: IBANs, SEPA mandates, reconciled statements.
- Wider access: during testing, accounts are opened for the integrator, consultants, offshore teams and key users who never had access to this data in production.
The risk materialises in two ways: a leak from the test environment, which is usually monitored less closely, or an audit that discovers real personal data circulating at a processor with no appropriate contractual framework. In both cases the question will be the same: why use real data when alternatives existed?
The 5 approaches to building ERP test data
There is no single method. The right choice depends on what you are testing (functional acceptance of accounting has different needs from a performance test) and the level of risk you can accept.
1. Full copy of production
The entire database is restored into the sandbox. Realism is maximal and effort minimal, but so is the risk. All personal data is present, with its full history. This approach is only defensible in a pre-production environment treated like production: same access controls, same encryption, same logging, a restricted user base. Regulators accept real data in pre-production only where fictitious or anonymised data is not sufficient, and with a security level equivalent to production.
2. Partial copy (subset)
You extract a coherent subset: one subsidiary, one fiscal year, a sample of customers. Volume falls, and with it storage cost and refresh time, and exposure is reduced through minimisation. But the data is still real: an unmasked subset is no less personal than the full set. The technical trap is referential integrity: extracting 500 customers without their invoices, journal entries and items produces an unusable database.
3. Masking and anonymisation
You start from a production copy, then replace sensitive values (names, addresses, IBANs, emails) with fictitious ones before the environment is opened up. For most projects this is the best trade-off between realism and risk. Mind the terminology: anonymisation under the GDPR makes re-identification impossible, irreversibly (Recital 26). Simply masking a few columns, while leaving cross-referencing possible (date of birth, city and job title are often enough), is in practice pseudonymisation. The critical point: the raw copy passes through an intermediate environment before masking, and that environment must itself be secured and short-lived.
4. Reversible pseudonymisation
Direct identifiers are replaced by tokens, and the mapping table is kept separately. It lets you recover the original data, for example to reproduce a production incident. But Article 4(5) of the GDPR is clear: pseudonymised data remains personal data. The full GDPR framework still applies, and the mapping table becomes a sensitive asset to isolate, in a perimeter with no access for the integrator or testers.
5. Synthetic data
You generate entirely fictitious data from rules: a population of customers, items, orders, balanced journal entries. GDPR risk is close to zero since no real person is involved, and the dataset is reproducible and shareable. The entry cost is higher: you have to model real-world diversity (edge cases, multiple VAT rates, currencies, exceptional discounts) for the tests to be credible. Synthetic data excels at regression and performance testing, less so at business acceptance testing, where users want to recognise “their” cases.
Comparison table
| Approach | Realism | Setup cost | GDPR risk | Refresh effort |
|---|---|---|---|---|
| Full copy | Maximal | Low | Very high | Low |
| Partial copy | High | Medium | High (real data) | Medium |
| Masking / anonymisation | High | Medium to high | Low to medium, depending on masking quality | Medium (script to rerun) |
| Reversible pseudonymisation | High | High | Medium (still personal data) | Medium to high |
| Synthetic data | Medium, depending on modelling | High | Near zero | Low once the generator is built |
In practice, mature projects combine them: a synthetic dataset for technical and automated tests, a masked copy for business acceptance, and a pre-production environment secured like production for the final cutover rehearsal.
What to anonymise first in an ERP
Start by mapping where personal data lives, using your record of processing activities. Here is the usual order of priority.
- Third parties (customers, suppliers, contacts): company names of sole traders, contact names, addresses, phone numbers. Legal entities are not protected by the GDPR, but their contacts are, and sole traders are natural persons.
- HR and payroll: identity, pay, absences, bank details. Exclude from testing as early as possible, or replace with fictitious employees.
- IBANs, company registration numbers, VAT numbers, social security numbers: replace with fictitious values that are still valid in format.
- Emails: an often underestimated risk. A test run that sends real reminders or invoices to real customers is a classic incident. Replace domains with a non-existent domain or a catch-all mailbox, and disable outbound mail connectors.
- Attachments: PDF invoices, contracts, scanned payslips, copies of ID documents. They contain real data even if the database is masked.
The free-text and document management trap
This is where projects fail most often. Careful masking of the “name” and “IBAN” columns leaves untouched the comment fields (“call Mr Smith on 07…”, “off sick until the 15th”), journal entry descriptions, expense claims, payment block reasons and the documents attached in the document management system. These fields follow no format and escape column-based masking rules.
Three responses work together: empty or replace free-text fields with neutral text in the test environment, do not migrate the document store (or replace it with a sample of fictitious documents), and scan the remaining fields with regular expressions (emails, phone numbers, IBANs) to detect what is left.
Preserving consistency: masking that does not break the ERP
Poorly designed masking produces anonymous but unusable data. Four consistency requirements apply.
- Referential integrity: the same customer must get the same fictitious name across all tables and modules (sales, accounts receivable, CRM, interfaces). Use deterministic masking (a function that always produces the same replacement for a given original value) rather than a fresh random draw for each table.
- Accounting totals: mask identities, not amounts. If you alter amounts, trial balances, reconciliations and VAT returns become wrong, and accounting testing loses its value. The sensitivity of amounts is a commercial confidentiality question, to be handled separately from the GDPR.
- Matching keys: document numbers, purchase order references, batch numbers and bank references used for matching must remain consistent with one another.
- Valid formats: a fictitious IBAN must pass its check digits, a VAT number must follow the country format, and national company identifiers must pass their own checksum rules. Otherwise the ERP’s input controls reject the data or, worse, validation tests miss real cases.
This work overlaps with data migration: the same cleansing and validation rules apply, as detailed in our 7-step ERP data migration methodology. A well-built test dataset often doubles as a test bench for migration rehearsals.
Tools and mechanisms by vendor
Features change with versions and licences. The pointers below are starting points to confirm with the vendor or integrator, not guarantees.
- SAP: the SAP ecosystem offers test data management solutions (the TDMS family, and data masking or obfuscation tools, including from third-party vendors). Availability depends on the version (ECC, S/4HANA) and the deployment model. Check with SAP or your partner what is supported in your context, particularly in public cloud, where the environment logic is different.
- Microsoft Dynamics 365: the environment model (production, sandbox) lets you create production copies in a sandbox. A production copy in a sandbox carries the data with it: adding a masking step between the copy and opening access to users remains your responsibility, through scripts or third-party tools.
- Odoo: in self-hosted editions, the PostgreSQL database lets you write SQL or Python masking scripts applied after restore, which gives great freedom but requires maintaining those scripts with every change in the data model. Test databases must also neutralise outgoing mail servers and scheduled actions.
- Other vendors (Sage, Microsoft Business Central, Infor…): ask about environment duplication procedures and whether a masking script can be run before access is opened.
Whatever the vendor, two habits prevent most incidents: automate masking in a versioned, rerunnable script, and disable every outbound connector (email, SMS, EDI, banking, e-invoicing) in the test environment. The principles of environment organisation are detailed in our guide to sandbox, test and staging environments.
The sandbox refresh process
A test dataset degrades: cases evolve, configuration drifts, data ages. You need a refresh process, not a one-off operation.
- Frequency: before each major test cycle, and ahead of the cutover dress rehearsal. An automatic monthly refresh becomes excessive if nobody uses it; the right frequency follows the project calendar.
- Responsibilities: the technical team runs the script; the project manager schedules it; the DPO validates the masking method and keeps a record of it; the business owner confirms the data remains usable.
- GDPR register: if the test environment contains personal data (even pseudonymised), it is a processing activity to document in the register, with its purpose, recipients and retention period.
- Retention period: set an end date for each environment and each copy. When the project closes, destroy the restored production backups and mapping tables. A “temporary” copy that survives for years is the most common finding in audits.
- Integrator contract: if the integrator accesses personal data, even imperfectly masked, it acts as a processor under Article 28 of the GDPR. The data processing agreement must cover test environments, the location of access (for teams outside the EU, transfer rules apply) and the return or destruction of data at the end of the engagement.
10-point checklist before opening a test environment
- The ERP’s personal data is mapped (tables, free-text fields, document store, interfaces).
- The chosen approach (from the five) is selected and justified in writing, with the DPO’s opinion.
- No raw copy of production is accessible to testers and contractors.
- The masking script is versioned, rerunnable and tested on a sample.
- Free-text fields and attachments are handled (emptied, replaced or excluded).
- Consistency checks pass: referential integrity, balances, reconciliations, IBAN and VAT formats.
- All outbound connectors (email, SMS, banking, EDI, e-invoicing) are disabled.
- Access is named, limited to need, logged, and reviewed with the integrator.
- The processing is in the register, and the data processing agreement covers test environments.
- A destruction date is set for the environment, backups and mapping tables.
This checklist fits naturally into the user acceptance preparation described in our guide to ERP testing and UAT.
Going further
Poorly controlled test data costs less to fix before testing opens than after an incident. To structure your approach, download our ERP evaluation grid or talk to the DigitsLane team about building a test dataset suited to your project. For the broader regulatory framework, see also our guide to GDPR compliance for ERP systems.
