Data Processing Agreements for SAP are changing. Don’t be caught out.

By Paul Hammersley
Paul Hammersley

Paul has for many years been a remarkable technical force at EPI-USE Labs. As VP of the ALM Products, his portfolio includes System Landscape Optimization, and his hands-on experience of implementing Data Sync Manager and helping clients to manage data across the breadth of their SAP landscapes is unique. He has specialised knowledge about data security and how GDPR (the General Data Protection Regulation) impacts companies running SAP.

Written on Jan 14, 2019 7:03:24 AM

2 minute read

Data Processing Agreements for SAP are changing Header Image
Are you compliant with the terms of your SAP support contract?

One of my colleagues shared with me an excerpt from the SAP Cloud Services Data Processing Agreement (DPA), which states, “This DPA does not apply to non-production environments of the Cloud Service if such environments are made available by SAP, and Customer shall not store Personal Data in such environments.”

I decided to also look at some of the other SAP data processing agreements, and found similar language in their support and professional services DPAs:“Customer shall not grant SAP access to Licensee systems or personal information (of Customer or any third party) unless such access is essential for the performance of SAP Services. Customer shall not store any Personal Data in non-production environments.”

SAP customers have recently been receiving emails highlighting these changes to terms and conditions, requiring customers to take action very soon.

How Personal Data arrives in non-production environments
Over the last 20 years, I’ve worked with well over 200 SAP customers, and I can remember only one that had not carried out some form of system copy for testing in the previous five years. The defacto standard for refreshing test systems is a system copy, either by snapshots, mirroring technology, back-up/restore or database copy techniques. SAP even provides Best Practice documents for System Landscape copy showing customers how to carry out these procedures. The end point of this is all the data from production is in the test system, including personal data on employees, customers, vendors and other business partners. For organisations with a lot of B2C activity, this is an incredible amount of personal data, potentially including health and creditworthiness information.

But there is another way data arrives in non-production systems. Many people working with mature SAP landscapes forget how the landscape developed the way it did, or how major projects such as acquisitions or new sales areas bring in data. LSMW (Legacy System Migration Workbench) and other batch load mechanisms automate the user activities of data loading, allowing spreadsheets of data to be loaded in minutes. These processes or other interfaces that load data are normally tested with real data at least once before they are run in production. Do the people responsible for those projects go back and clean up the real data in the test systems afterwards?

Shifting sands
These changes to the SAP terms and conditions (cloud, service and support) put two guideline documents from SAP – best practice guides and DPAs – on a very firm collision course. Anyone continuing to copy real data to non-production systems or test real data loads in those systems must now find a way to remove the personal data.

With the raft of data privacy laws, including GDPR, coming out in the last two years (with more scheduled in the next two years), it’s not surprising that SAP would make this clear distinction and I expect most SIs will also follow their lead.

It doesn’t necessarily mean an end to system copies, but it does require further action. I would urge organisations to take this opportunity to consider whether they really need all the data from Production for testing. Our Client Sync™ and Object Sync™ solutions can provide much leaner test clients and data on demand for functional experts respectively. Both now include direct integration to Data Secure™, so the data can be masked with the same policies, and what’s more the data is masked on exit – so it leaves the production system already masked. At the very least  Data Secure™ can assist with masking of copied systems before they are released to the users.

Recently we’ve seen a raft of customers replacing their own Z-programs for masking test data with our ‘best of breed’ solution in this space. They’ve found the volumes and complexity of consistently masking their data going up drastically over the last few years. This makes it harder to completely mask all places the data is stored in (including cluster tables), and be able to execute the activities quickly enough not to delay projects needing the test data. Data Secure™ has been designed, developed and enhanced with input from over 200 customers to better manage this need.

Find more information:
Data Secure | Client Sync solution for lean test clients with pre-masked data | Object Sync for masked test data on demand | SAP GDPR Compliance/Data Privacy Suite

SAP GDPR webinar
Topics: test data management sap European operations personal data system copy SAP GDPR

Add a comment