I decided to look at some of the other SAP data processing agreements and found a similar language in their support and professional services DPAs: « The customer does not grant SAP access to the licensee`s (customer`s or a third party`s) systems or personal information, unless such access is essential for the provision of SAP services. The customer may not store personal data in non-productive environments. Sap customers have recently received emails outlining these changes in the terms and conditions, forcing customers to take action very quickly. How personal data arrives in non-productive environments Over the past 20 years, I`ve worked with over 200 SAP customers, and I only remember someone who hadn`t made a system copy to test in the last five years. Legacy System Migration Workbench (LSMW) and other batch loading mechanisms automate user activities when loading data, allowing tables to be loaded with data in minutes. These processes or other interfaces that load data are usually tested at least once with actual data before being run in production. Do these projects withdraw and retrieve the actual data from the test systems? These changes in SAP`s terms and conditions (Cloud, Service and Support) have implemented two SAP guidance documents – best practice guides and DPAs – on a very firm collision course. If you continue to copy real data into non-production systems or test real data loads in those systems, you need to find a way to delete the personal data. With the multiplicity of data protection laws, including the GDPR, that have emerged in the last couple of years (more are expected in the next two years), it`s no surprise that SAP makes this clear distinction and I expect most SIs to follow their lead. This does not necessarily mean the end of copies of the system, but it does require further action. I would like to urge organisations to take this opportunity to ask themselves whether they really need all the production data to test it. Our Sync™ and Object Sync customers™ Solutions can provide much thinner test clients and on-demand data for functional experts. Both now include direct integration into Data Secure™ so that the data can be hidden with the same directives, and moreover, the data is hidden at the end – so that the production system already remains hidden.
At least Data Secure™ can help hide copied systems before they are shared with users. Recently, we have seen a number of customers replace their own Z programs for masking test data with our « Best of Breed » solution in this area. They have found that the volume and complexity of the consequent masking of their data has increased significantly in recent years. This makes it more difficult to completely hide all the sites where the data is stored (including cluster arrays) and be able to run the activities fast enough so as not to delay projects that need the test data.