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

January 14, 2019
Written by Paul Hammersley

As Senior Vice-President of the ALM Products at EPI-USE Labs, Paul Hammersley's portfolio includes test data management, landscape optimisation, and archiving. He has been a remarkable technical force in the SAP arena for over 20 years, and has extensive hands-on experience of implementing Data Sync Manager (DSM) and helping clients to manage data across the breadth of their SAP landscapes.

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

 

 

Explore Popular Tags

GDPR Data Privacy Data Security Data Secure GDPR compliance Data Redaction data scrambling General Data Protection Regulation Data Redact POPI Act POPIA SAP Data Security SAP GDPR Data Archiving Data Sync Manager SAP data privacy and compliance Right to be forgotten Data privacy compliance Data privacy regulations GDPR readiness GDPR deadline Personal data SAP SAP security GRC for SAP SAP systems Access Risk management Access risk controls Data minimisation Data security breaches Governance, Risk Management and Compliance (GRC) SAP data privacy and security compliance COVID-19 Data Privacy suite Data privacy by design Risk monitoring SAP data copying and masking SAR Soterion Subject Access Request anonymised data Australian Privacy Act 1988 CCPA Cenoti Client Sync Data Protection Day Data masking European operations Federal Law GDPR fine Guest order ICO May 2018 Object Sync One-time customer Privacy by Design Reducing risk Right to Erasure Risk minimisation S/4HANA Migrations SAP S/4HANA SAP data SAP data privacy & security Secure scrambled production data for testing Test Data Management security breach Backlog privacy debt Black Friday Black Friday hangover Black Friday sales Breach Notification Brexit Budget Canada data privacy legislation Cenoti, connecting SAP with Splunk Cloud migrations Confidentiality Consent DSM DSM Readiness Assessment Data Portability Data Removal Data Replication Data Sync Manager (DSM) Data integrity Data processor versus controller Data retention rules Documentation EPI-USE Labs’ solutions Employee data Europe Friday 25 May 2018 GDPR-type legislation GRC GRC for SAP tools General Data Protection HCM HR ILM Information Commissioner’s Office Information transfer Infotype 41 JSOX New Zealand Privacy Act Online shopping Penalties Phantom Proportional Data Protect personal employee data Removing data in SAP Right to Access Rise with SAP Risk management S4HANA SAP Cloud SAP Data Privacy Suite SAP RISE SAP SuccessFactors SAP access risk simulations SAP data encryption SIEM SOX Sarbanes-Oxley (SOX) legislation Security Security Information and Event Management Security for SAP. Live Sensitive HCM data South African data privacy legislation Splunk Splunk UBA Splunk’s Enterprise Security Success Factors Territorial Scope UK Government User Access Review Virtual conference What does the European GDPR mean for Australia? ebook masking rules quality of test data system copy uk sox
+ See More

Get Instant Updates


Leave a Comment: