It’s a tricky balance: what CAN and MAY you test?

You MAY not do testing with personal data...and many people say they CAN not do testing with anonymised data. But there is a balance between the two; you are both allowed to and able to do testing with data which is both realistic and scrambled.

The General Data Protection Regulation (GDPR) that came into effect in May 2018 has changed the world’s view on data privacy. Every organisation that is either doing business with European Union citizens, or based within the EU, has spent many hours on the topic. It has changed the way we think about and act on personal data, from both a personal and business view.

In SAP landscapes, one of the big topics for personal data is about the data stored outside production systems, although SAP’s Data Processing Agreement (DPA) does not allow this. Many organisations create full production copies in their testing systems (SAP Client, or more often System Copies) for testing. These copies would include personal and sensitive data. In some scenarios, you may even have a valid reason for using personal data for testing, but doing this is very risky and totally unnecessary.

Copying only the data you need for testing, and no more than that, would already be a big improvement. Not only in terms of GDPR compliance; in my experience, less data also means a lower Total Cost of Ownership (TCO). And copying less data also means having your test-set or development-set of data when you need it: test data on demand. Which means having real and adequate data when you need it. Ultimately, less data outside production means less risk – something every IT organisation would be very happy with.

Benefits of less and scrambled data in testing and development

• Firstly, compliance with GDPR. The regulation is clear; you may only use the data for the intended purpose. Ask yourself if you have permission to use personal data for testing, development and training purposes?
• Being compliant with your SAP DPA; it is your responsibility to be GDPR compliant with the tooling available in the market.
• Reducing the risk of data disclosure with less and scrambled data outside production.
• Improving TCO on hosting/hardware.
• Improving data quality for testing and development via faster and more frequent test data refreshes. This also means better test results and less rework.
• Improving projects and change quality and timelines.

Going back to the challenge: How do we find the balance in having scrambled data for proper testing?

1. Copy only the data you need for testing. Less data = less risk
2. Scramble the data in the SAP data model consistently, meaning ALL the fields that are connected to Personally Identifiable Information (PII)
3. Refresh your test data frequently according to your Test Data Strategy

Our solutions allow you to do just that!

With Data Sync Manager™ (DSM) you can scramble the sensitive data in your SAP landscape consistently. And DSM will also enable you to subset the required data for testing, and less data means less risk. Data Secure™, part of the DSM suite, will take care of scrambling the data. The product has been used in the market for 22 years and has an extensive set of rules to cater for different scrambling needs.