Are you compliant or are you testing anyway?

But what about the handling of personal and other business-critical data on non-production systems? Unless strict authorization management, similar to that for production systems, clearly structures access to sandboxes and QA systems, the door is still wide open to the technical possibilities of unintentional data leakage.

The authorization system

Our experience shows that internal as well as external developers often get relatively easy access to QA systems, usually with much more extensive permissions than they would ever get in the production environment.

After all, testing should be carried out with fully comprehensive real data. This is because reduced, but logically consistent data sets only allow a functional consistency that also covers all real special cases and makes reliable performance statements to a limited extent.

In addition, they can also only be achieved with extensive configuration work and also require relatively long export/import lead times.

Copy and clone

This is why many companies rely on the homogeneous system copy or system clone. Because system copies have never been easier, more frequent and faster than today. QA and test systems are built and/or updated at the proverbial push of a button, especially in conjunction with comparatively inexpensive and "easily procurable" cloud environments.

This is generally a good thing. However, this means that complete databases, including personal and other business-critical data, are increasingly accessible to unauthorized persons. If these systems are also under the radar of data protection officers and the DSGVO (keyword:

right to information, or: "in which systems are which of my personal data stored?"), in case of doubt, several violations of current laws and internal as well as external compliance requirements can be found at the same time.

There are only a few ways to get a grip on this. First, strict limitation of the number of systems and consistent deletion of personal and other critical data - in our view, clearly contrary to the objective of these systems.

Secondly, strict implementation of authorization concepts analogous to the productive environments - and the associated restriction of the working ability and efficiency of developers, consultants, testers.

Third, persistent data anonymization ensures that such systems no longer offer sensitive and business-critical data - in our view, this is the best way forward, provided that the "logical ability to work" of the data is still guaranteed.

This means that these systems no longer carry critical real data, but continue to offer data sets that look real and are logically consistent. Age structures should generally remain similar, regional distributions as well as other clusterings/segmentations.

Financial data records, IBAN or checksums for credit cards should be calculated just as correctly as street addresses are assigned to correct postal codes. And a few more critical cases.

All of these logical dependencies should be taken into account initially during anonymization, and not just within one system in the business process chain, but across all systems and databases in the entire business process. The fact that other application platforms are sometimes involved in addition to SAP systems should also be more than just kept in mind.

Templates for all

The good thing about this is that the data models of most major application vendors are known. And so providers like us with Libelle DataMasking have mature templates on board that already cover a large part of these requirements. Available out of the box, immediately usable and also incrementally expandable.

In the entire subject area of compliance, the construction site "critical data in non-production systems" can thus be regulated comparatively simply and quickly with regard to internal and external specifications, without restricting the ability of consultants and developers to work.