Personal data in SAP test systems: what matters

Why production data in test systems is a data protection issue

In production, authorisation concepts, logging and established processes protect personal data. A copy into the test system takes the data with it, but this protection only partially:

• Broader authorisations: Developers, consultants and key users often work with far-reaching authorisations in the test system so that they can test and analyse errors. Data that is blocked in production because its purpose has ended, and is visible only with a special authorisation, also becomes easier to access this way.
• External service providers: Implementation partners and AMS teams often have easier access to test systems than to production. If teams from countries outside the EU and the EEA access the data, the rules for transfers to third countries also apply (Chapter V GDPR).
• More copies: QA, test, sandbox, training, project systems, plus export files and backups of each system. Every copy is one more place where the data resides.
• Longer retention: What is blocked or deleted in production remains in an older copy until the next refresh. With infrequent refreshes, that can take months.

In its IT-Grundschutz, the German Federal Office for Information Security (BSI) explicitly describes this risk: when tests are run with production data, confidential data could be viewed by unauthorised persons, including third parties commissioned with the testing.

What the GDPR requires in principle

No legal advice. This article outlines principles and technical approaches. Whether measures are sufficient in your case, and which ones, is for your data protection officer and your legal advisers to assess.

The GDPR contains no specific rule for test systems. The general principles of Art. 5(1) GDPR apply, including:

• Purpose limitation (point (b)): Data is collected for specified, explicit and legitimate purposes and must not be further processed in a manner that is incompatible with those purposes.
• Data minimisation (point (c)): Data must be limited to what is necessary for the purpose. For test systems, this raises the question of which data a test really needs.
• Storage limitation (point (e)): Individuals may only be identifiable for as long as is necessary for the purpose.
• Integrity and confidentiality (point (f)): Appropriate security, including protection against unauthorised or unlawful processing.

Under Art. 25 GDPR, the controller implements appropriate technical and organisational measures to put these principles into effect. The article explicitly names pseudonymisation as an example. Art. 32 GDPR lists pseudonymisation and encryption among the measures for a level of security appropriate to the risk. And under Art. 5(2) GDPR, the controller must be able to demonstrate compliance with the principles. In practice, this means recording which data is copied into which systems and how it is protected there.

The BSI’s IT-Grundschutz is more specific. If production data used for testing contains personal information, requirement OPS.1.1.6.A11 states that it must at least be pseudonymised. Where possible, it should be fully anonymised. If a personal reference can still be derived, the data protection officer must be involved, and possibly also the employee representatives.

Anonymising, pseudonymising, masking: the terms

Anonymisation removes the personal reference in such a way that it cannot be restored, or only with a disproportionate effort in terms of time, cost and labour. This is how the German Federal Commissioner for Data Protection and Freedom of Information (BfDI) describes it in a position paper. The principles of data protection do not apply to anonymous information (Recital 26 GDPR). However, the BfDI also points out that absolute anonymisation is often not possible, that sufficient anonymisation must not be assumed prematurely, and that anonymising is itself processing of personal data that requires a legal basis.

Pseudonymisation (Art. 4(5) GDPR) processes data in such a way that it can no longer be attributed to a specific person without additional information. This additional information, such as a mapping table, is kept separately and protected. Pseudonymised data remains personal data.

Masking is not a legal term but a technical umbrella term: values are replaced, scrambled, truncated or blanked. A name is replaced by a fictitious one, an IBAN by a test IBAN with a valid check digit. Whether the result is anonymous or merely pseudonymous is not decided by the individual field, but by the overall picture of the data. Reversible masking with a mapping table is pseudonymisation.

Where personal data is found in SAP

In SAP, personal data is not only found in the obvious master data. Typical locations:

Business partners, customers, suppliers

Names, addresses, telephone numbers, email addresses and contact persons. In S/4HANA, these are held centrally in the business partner (e.g. BUT000) and in address management (ADRC, ADR2, ADR6), as well as in customer and supplier master records (KNA1, LFA1).

Bank details and payments

IBAN and account holder in the business partner (BUT0BK) and in customer and supplier master records (KNBK, LFBK), plus the data from payment runs (e.g. REGUH).

Documents

Documents also contain personal data, such as differing addresses or the data of one-time customers and suppliers (BSEC).

Employee data

Where SAP HCM runs in the same system, personnel master data and payroll results are added. These may include special categories under Art. 9 GDPR, such as information on religious affiliation or health.

Hidden places

Change documents (CDHDR, CDPOS) with old and new field values, long texts and notes, IDocs, application logs, spool and send requests, attachments and the user master records themselves.

Which fields are affected in your system depends on modules, enhancements and customer-specific tables. For employee data in particular, it is worth asking whether it belongs in the test system at all. An inventory therefore comes at the start of every masking concept.

Four approaches for SAP test data containing personal data

• Do not copy at all: Development and training systems often manage without production data. Customizing is already there or arrives by transport, and test data is created manually or by script. The article Test data for S/4HANA shows the options.
• Copy less: A partial copy by time slice brings only the last few months into the test system instead of the entire history. Depending on the tool, entire areas such as employee data can be excluded.
• Mask during the copy: If masking takes effect before the data is written to the target database, the plain text never reaches the test system. If masking only takes place after the copy, the plain-text data sits in the target system until then, possibly also in its log backups.
• Restrict authorisations: Maintain roles in the test system too, assign far-reaching profiles only selectively and regulate access by external service providers. Authorisations complement the other approaches but rarely replace them, because tests often require broad authorisations.

In practice, the approaches are combined. Masking then becomes a fixed part of every refresh, like the other steps in the checklist of follow-up tasks after a copy.

Limits of masking

Masking sounds like a switch. In SAP, it is more of a concept that needs to be maintained. Four areas make it difficult:

• Consistency across tables: The same business partner appears in master data, addresses, documents, payment runs, change documents and IDocs. If the name is replaced in only one place, the rest no longer matches or gives away the plain text. Checks in processes and interfaces also need consistent replacement values, such as valid check digits.
• Free text: Long texts, notes and comment fields contain whatever someone wrote in them. Field-based rules do not reliably detect such content.
• Attachments: Invoices as PDFs, scanned documents or emails. Depending on how they are stored, they reside in the database or on a content server. They can hardly be masked; excluding them is more realistic.
• Recognisability: Even without a name, a record can point to a person: the only customer in a small town, an unusual salary, a supplier with a known order volume. In addition, people working in the test system know many transactions from production.

Then there is maintenance. New fields, enhancements and customer-specific tables have to be added to the rules. Art. 32 GDPR explicitly mentions a process for regularly testing, assessing and evaluating the effectiveness of the measures. Whether a masked test dataset still constitutes personal data is assessed by your data protection function on the basis of the overall picture, not a list of fields.

Masking in the refresh with DRO

The Data Refresh Operator (DRO) combines two of these approaches. It copies a time slice instead of the complete history, for example the last 90 days plus all dependent objects. Older transactions with no connection to the selected time frame never reach the test system in the first place. Masking is integrated with Data Protect:

• Data Protect helps you find data that needs masking.
• You maintain the rules in one place, in the central control system.
• They are applied during export or import. When masking during export, the data leaves production already masked.
• Masking is a step in the run, not a separate follow-up task. A simulation in advance and the audit trail make it traceable what was copied.

Which fields are masked and how, and whether the result is sufficient for your purpose, is something you define with your data protection team. The limits from the previous section apply here too: DRO provides the tool, the assessment remains with you. DRO runs on SAP S/4HANA from release 2023. More about the function on the page Anonymising and masking SAP test data with Data Protect. In a demo, we show how Data Protect would work in your landscape.

Sources

• dsgvo-gesetz.de: Art. 5 GDPR: Principles relating to processing of personal data (in German)
• dsgvo-gesetz.de: Art. 25 GDPR: Data protection by design and by default (in German)
• dsgvo-gesetz.de: Art. 32 GDPR: Security of processing (in German)
• dsgvo-gesetz.de: Art. 9 GDPR: Processing of special categories of personal data (in German)
• BfDI, as of 29 June 2020: Position paper on anonymisation under the GDPR with special consideration of the telecommunications sector (in German)
• BSI, IT-Grundschutz Compendium, 2023 edition: Module OPS.1.1.6 Software Tests and Approvals, requirement A11 (in German)