Personal data rightly deserve a high level of protection, not only since the GDPR. According to the purpose limitation of personal data, only data that is needed for the specific business purpose may be processed, and only by a group of persons with a legitimate interest. For production environments, this is a procedural/organisational issue and of course also a topic of authorisation management.
But what about non-production environments? In practice, among other things, test systems are often updated with classic system copies. Ergo: production data in non-production environments. Usually, a large number of non-authorised persons (developers, consultants, admins) have access to real data. Maybe not up-to-date, but still clearly personalised.
This presents companies with a critical situation: on the one hand, the test system must contain realistic data to enable meaningful tests, on the other hand, no real data may be used. But how can realistic testing be done without real data in the test environments?
Anonymising data so that it no longer has a concrete personal reference is a remedy. It is an excellent method to provide test data according to the applicable requirements without risks with regard to the GDPR and operational data protection, security and compliance. At first, this sounds easier than it is. This is because, among other things, attention must still be paid to meaningfulness and logical consistency, both within the system and across system boundaries within the landscape.
With this team, you update and anonymise your non-production systems with fresh production data at any time at the push of a button and end-to-end, GDPR-compliant. Automation and optimisation reduce the effort and throughput times of homogeneous system and landscape copies enormously. Critical and sensitive data is persistently anonymised, taking logical relationships into account. Downtimes of the target systems are minimised and the implementation can be carried out without specialists.
The result is realistic, logically correct and consistent data across systems for the development and testing of software and business processes, across all platforms. By the way, also in non-SAP systems.
Based on our best practices from a multitude of implementations, Libelle SystemCopy (LSC) and Libelle DataMasking (LDM) can usually be integrated into your environments in 2-3 days.