Lesson 5 of 7
Privacy and masking
10 min
Listen to this lesson
A copy of production is a copy of every personal record in it: customer contacts, one-off customers who are private individuals, supplier bank details, employee data if HR runs in the system, and the names and addresses inside documents, attachments and interface messages. Using that copy for testing is processing personal data for a new purpose. The TCoE does not set privacy policy; Nadia's security and GRC team and the privacy office do. But the TCoE designs the environments and data services, so it must build privacy into them from the start.
What the law asks, in testing terms
| Principle (GDPR reference) | What it means for test data | Contoso practice |
|---|---|---|
| Purpose limitation and data minimization (Art. 5(1)(b) and (c)) | Use only the personal data testing really needs | Masked copies by default; real values only where a test cannot work without them |
| Data protection by design and by default (Art. 25) | Privacy is built into environments, not added later | Masking is a step in the post-copy runbook, before any tester logs on |
| Security of processing (Art. 32) | Pseudonymization, access control and confidentiality | Named access only; no offshore access to unmasked systems |
| Pseudonymized versus anonymous data (Recital 26) | Pseudonymized data is still personal data; truly anonymous data is out of scope | Masked copies are still treated as personal data and protected |
GDPR principles applied to SAP test data. Your privacy office decides which laws apply and how.
Which laws apply depends on where your data subjects are. Contoso is a US company, so its baseline comes from US state privacy laws and contracts; it uses the GDPR as its design reference because it is the most demanding widely used standard. The Wave 2 acquisition adds Mexican personal data: Mexico published a new Federal Law on the Protection of Personal Data Held by Private Parties on March 20, 2025, in force the next day, and the supervisory functions of the former INAI moved to the Secretaría Anticorrupción y Buen Gobierno. The European Data Protection Board's Guidelines 01/2025 on pseudonymisation, published for consultation in January 2025, explain why pseudonymized data remains personal data when anyone can link it back. Ask the privacy office for a one-page rule that names the laws in scope; don't interpret them yourself.
Four ways to get test data
| Approach | Realism | Privacy risk | Effort | Good for |
|---|---|---|---|---|
| Full production copy, unmasked | Highest | Highest: every personal record is exposed | Low | Rarely justified; only with strict, time-limited access |
| Masked copy | High | Reduced, but still personal data if re-identifiable | Medium: a masking step every refresh | Pre-production regression, performance, release UAT |
| Selective subset, masked | Medium to high | Lower: less data, less exposure | High: scoping and consistency | Smaller test systems, partner environments |
| Synthetic data | Depends on recipes | Lowest: no real persons | High at first, low once automated | Automation, development, training, offshore work |
- Does the test need production volumes or real data distributions?Yes → masked copy (or masked subset) · No → next question
- Can recipes create the records the test needs?Yes → synthetic data from recipes · No → masked subset scoped to the case
- Does any test truly need real personal values?Yes → privacy office approval, time limit and named access · No → keep masking on
- Will people outside the approved group see the system?Yes → synthetic or masked only, never unmasked · No → follow the catalog's access rule
Why masking SAP data is harder than it looks
Masking a single table is easy. Masking SAP consistently is not, because the same person appears in many places. A business partner's name sits in the business partner tables, the address in the central address tables, bank details and tax numbers in their own tables, and the same values are repeated in sales documents, billing output, change documents (which record old and new values), application logs, IDoc payloads and workflow containers. Attachments and stored output, such as invoice PDFs, may carry names and addresses too. A masking design must list every place personal data lives in your system, mask it consistently so that the same customer gets the same masked name everywhere, and keep referential integrity so tests still work.
SAP HANA offers data anonymization through anonymized views using k-anonymity, l-diversity and differential privacy, and SAP's tutorial is clear that the original data stays unchanged. That makes it a tool for analytics on sensitive data, not a way to mask the application tables a test system runs on. For ECC, many customers used SAP Test Data Migration Server for selective copies and scrambling; check the Product Availability Matrix for current support on your S/4HANA release before planning around it. Whatever tool you use, the design decisions above are yours.
Access, retention and evidence
- Access: every catalog entry states its data classification and who may log on. Unmasked or partly masked systems get named access, reviewed each quarter by Nadia's team.
- Sharing: partners and offshore teams work only in masked or synthetic environments (sap-tcoe-407 covers partner access).
- Retention: test systems are refreshed, so old copies disappear; exports, spreadsheets and screenshots used as evidence do not. Evidence standards should forbid personal data in screenshots where a masked record would do.
- Evidence: keep a masking log per refresh: which rules ran, how many records, the check results and who approved opening the system.
What would you do?
During UAT of a release in CMR, Maria says a billing output test needs a real customer's email address "to see what the customer will receive." What should Priya do?
- A production copy used for testing is processing personal data; build privacy into environments by design.
- Use a masked copy for pre-production and synthetic data from recipes for automation, development and offshore work.
- Mask consistently across master data, documents, change documents, logs, IDocs and attachments, keeping referential integrity.
- Masked data that can be re-identified is still personal data: restrict access, log masking, and keep personal data out of evidence.
Check your understanding · not graded
Lesson check
1. Under the GDPR, how is pseudonymized test data treated?
2. Why is masking only the business partner master data insufficient in SAP?
3. What are SAP HANA anonymized views designed for?
4. When in the post-copy runbook should masking run?