Data Masking in SAP Systems

The handling of personal data is a recurring topic: might it be politicians that want to store mobile phone data, or that hackers gain access to data and publish it, or misuse it for criminal purposes. IT is somehow always in the middle of it.

Both internal audits and auditors are increasingly making notes that the handling of data must be newly regulated (keyword: compliance). For example, in QA or training systems, data used for testing or training purposes must not be readable in "plain text". This is an understandable concern, but: how can it best be implemented in an SAP environment? And: How do you "correctly" anonymize data?

Let's start with the last question:

In the simplest case, the relevant fields are simply made "unrecognizable" by, for example, entering xxx in the name field, yyy in the first name field, etc. Solves the problem, but does not help you to work with the data.

An alternative is to replace fields with one (or more) constants. For example, Max Mustermann or Klara Müller, who have been famous for decades. You may have several constants for each field.

The most sensible and most difficult way is to anonymize field-sensitive data. Here it is important to first get an overview of what is to be anonymized: Address, bank details, personnel number, account data, and so on. Then the question also arises as to what dependencies there are. For example, age should be taken into account in patient data. A newborn should not become a teenager. The question of whether the anonymised data is relevant for further processing elsewhere can also be important: If addresses are anonymised and a plausibility check of the address is performed in another process step, it must be ensured that the anonymised address exists. These examples and dependencies can be continued as required.

Another very important point is knowing in which tables within an SAP system the data is stored everywhere and which dependencies exist.

Then there is the question of when the data must be anonymized. Anonymized data is needed in quality assurance systems, development systems, sandboxes and training systems. Therefore, it should always be anonymized before a user accesses the data:

Possibility 1: If data is transferred specifically, e.g. a patient master record or a personnel number, the data should arrive in the target system already anonymized.
Possibility 2: Within the scope of a system copy. As one of the last steps in the system copy, anonymization is started, and then the SAP system is released.
Since anonymization as described above is a complex topic, Empirius relies on the cooperation with expert tools, especially FIS/hrd. The added value lies in the integration of both procedures according to option two. A practical example:

The Klinikum Stuttgart invests a lot of time in training and further education of its employees. The data in the training system must be made so anonymous that the "students" (i.e. nurses, doctors and carers) no longer have any reference to the original data, but are nevertheless trained using real cases.

For the regular setup of the training system a system copy of the productive system is made with BlueSystemCopy, for the anonymization of the patient data FIS/hrd-ish is used. The integration of both tools ensures a secure, fully automated creation of the training system with anonymized, but always up-to-date data. Thus, training courses can be carried out quickly and without complications using relevant data.

Mr. Pfeiffer, Head of the Systems Department at the Stuttgart Clinic:

"Anonymization with FIS/hrd-ish in combination with BlueCopy is a good way for us to make weekly copies for the training system with little effort. The decisive factor is that the anonymization software creates logical, but anonymized patient data."