Lesson 4 of 6
Data protection in refreshed systems
10 min
Listen to this lesson
A production copy brings production data: customer names and addresses, supplier bank details, employee data if HR runs in the system, and pricing that is commercially sensitive. In production, access is tightly controlled. In a test system, dozens of consultants, testers and developers may have broad access. Data protection laws apply to personal data wherever it sits, and a test system is not an exception.
Scrambling and anonymization
Scrambling replaces values in sensitive fields with fictitious ones while keeping formats and relationships intact, so tests still work: a customer remains a customer with a valid-looking address, but not the real one. Good scrambling is consistent (the same original value always becomes the same new value, so links between tables survive) and irreversible. SAP offers its own products for reduced copies and scrambling, such as SAP Test Data Migration Server; check licensing and fit for SAP S/4HANA 2025. Whatever tool is used, the scrambling rules are a design artifact that the data protection officer should approve.
| Data | Risk if exposed | Typical measure |
|---|---|---|
| Customer names, addresses, contacts | Personal data breach | Scramble consistently; keep country and region for tax logic |
| Supplier bank accounts | Fraud and payment errors | Replace with test bank details; block payment file transfer |
| Employee and HR data | Highly sensitive personal data | Exclude or anonymize fully; restrict access strictly |
| Prices and conditions | Commercial confidentiality | Restrict access; scramble only if tests allow |
| Credit and payment history | Personal and financial data | Anonymize the link to identifiable people |
Order matters
Data protection steps belong in the post-copy runbook, before the system opens to testers. A refresh that is scrambled "next week" has exposed real data to every tester for a week. Plan the run time of scrambling in the refresh window, and verify it at handover with spot checks on known records.
- CopyProduction restored into CMQ; system isolated, users locked
- ScrambleApproved scrambling rules applied to personal and bank data
- Spot checkSam and the data protection contact check sample records: no real names or bank accounts
- OpenTest users unlocked with role-based access
- ReviewAccess logs reviewed during the cycle; copy deleted or refreshed on schedule
Access and retention
Scrambling reduces risk; access control limits who can see what is left. Keep the user population of a refreshed system to the people who need it for the current cycle, give testers role-based access rather than broad display rights, and lock developer and consultant users that are not on the plan. Decide up front how long a production copy may live: a copy that is refreshed or deleted on a schedule holds less forgotten personal data than one that sits for years. Record these decisions in the refresh runbook so they are applied every time, not only when someone remembers.
What would you do?
A tester asks for an unscrambled copy of CMQ because a test of the bank file format for Lakeside Components fails with scrambled bank details. What should Sam and Priya do?
- Production copies carry personal and sensitive data; protection rules still apply in test.
- Minimize, scramble consistently, restrict access, contain outbound channels, monitor and delete.
- Scramble before opening the system to testers, and verify with spot checks.
- Meet special test needs with controlled test records, not unscrambled data.
Check your understanding · not graded
Lesson check
1. What makes scrambling "consistent"?
2. When should scrambling run in a refresh?
3. Which measure keeps real data from leaving a test system?
4. A format test needs valid bank details. What is the best approach?