Data protection by design in the SAP world

January 19, 2017
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.

Explicit in the General Data Protection Regulation (GDPR) legislation is the instruction that the protection of sensitive data must be ‘by design’.

In the past, ignorance was never a valid excuse concerning the old legislation, but the fines were so small that companies would happily plead ignorance, and pay the bill.

GDPR has changed that dramatically. With the fines being a maximum of 4% of global revenue (or €20 million, whichever is greater) companies will be much more keen to comply. This figure was originally earmarked to be 5%, but was negotiated down. Even now, there are predictions in some quarters that early in 2018 there is likely to be a high-profile transgressor on the wrong end of a very significant fine.  

It’s clear that the best way to avoid the maximum fine is to show that there are processes and procedures in place, and that these have been critically and well thought out, and implemented. If this is the case and a company is still found guilty of neglect or non-compliance, they can at least show serious intent to comply. The reality is that the actual detail of what is required in a specific situation is very hard to be completely sure of. And in many cases, the written law contributes 75% of what’s needed, but legal precedent determines how the law is interpreted in a particular jurisdiction.

So how do we deliver ‘data protection by design’ in the SAP world?

In Part 2 of the post on this topic - the Enterprise spread of personal data, I talked about the myriad of test systems which are often copies of production. Clearly, the best policy here is to remove or mask anything which could be determined as personal data. Changing a customer to ‘Mr Smith’ but leaving their home address intact may come under the term “pseudo-anonymisation”. Consensus among legal experts is that Pseudonymised data remains personal data because it can be re-associated with a specific consumer. The regulation applies to pseudonymised data, with some differences, but does not apply to fully-anonymised data, as discussed previously.

Another important point in the regulation is consent. It’s clear that there is an obligation to be able to track and show how and where personal data is stored. The subject can either consent to the storage of personal data in that form, or request removal. The regulation is very clear that placing an all-encompassing consent clause in the small print will not suffice. Consent must be freely given, specific and informed. If consent is required, it has to be expressly given: "clear affirmative action by the data subject."

The first step is to be able to find and display all the data related to a particular data subject across the company’s SAP landscape. At that point, we can either accept the subject’s explicit consent, or we can carry out ‘removal’; or in the case of SAP, removal of the sensitive text parts but not the entire master record. In most cases, the fields we need to remove are actually mandatory in a SAP system so a single ‘REDACTED’ type value may be required. However, it is essential to understand the SAP data model very well to ensure you do not redact something actually required by the systems to function.

Helping our clients to find a solution

Fortunately, this is an area my colleagues and I have been working in for 20 years. Of course there is no one-size-fits-all solution, so we are working with our clients to help them understand their choices and give them guidance about data types and where data is stored in SAP. We’re also running workshops and webinars about GDPR to help explain the challenges faced by businesses.

We believe some companies will work on a reactive approach, waiting for requests and responding to them, but some will be proactive and build a ‘data retention policy’ into their process. The masking engine required for this is something we’ve had in one format or another for about eight years. I was involved in some of the design sessions with our developers, and particularly the UI team, and they put forward some really interesting ideas on how we can really help customers to plan their data protection by design in the SAP world.

More updates on Data Security are being posted here.  Subscribe to stay up to date.

Our GDPR solutions and services can help you deliver data protection by design in the SAP world.

 

 

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: