skip to Main Content
42 01 (3)

Is Your Business GPDR-Proof?

A step-by-step guide to make sure your SAP system is GPDR-compliant

When the European Union’s General Data Protection Regulation (GDPR) went into effect in May last year, the scale of the penalties and size of the potential fines sent shivers down the spine of many enterprises – not just in Europe, but all over the world. Because, the mere fact that a business isn’t physically located in the E.U. won’t get them off the hook if they accidentally or intentionally infringe the rules.

The E.U. is taking things seriously. In July it announced plans to fine British Airways GBP 183.38 million (HK$1.788 billion) for an alleged breach of the GDPR. The next day it announced its intention to fine Marriott International GBP 99 million (HK$965 million). And, while Hong Kong firms have been spared so far, that doesn’t mean local businesses can afford to ignore the implications of GPDR.

The question for some SAP users is what do to and where to start? The answer is start at the beginning, and take it one step at a time!

Step 1 – Define In-Scope SAP Data

A preparation plan starts by identifying all the SAP environments, clients, master data tables, and fields containing personal information of European residents, even customized z-tables and z-fields. All SAP systems such as SAP ERP Central Component (ECC), Business Intelligence (BI), Customer Relationship Management (CRM), and other solutions should be included in the preparation project. Backups, legacy systems, and archives of SAP databases should also be included in the planning. Digitized documents integrated into SAP containing private information should also be covered. 

The quantity and quality of sensitive personal data to protect largely differs between industries and legal areas. Certain sectors, such as healthcare, insurance, banking, recruitment, and marketing, deal with a high volume and wide variety of personal information.

During the scope planning, it is important to validate with the business owners why the personal information is collected for the impact assessment. Confirming the specific and legitimate needs for keeping personal information with business experts is highly advisable. 

Also, understanding the business need for each type of information helps to define responsible contact and data retention requirements and to show how data is transferred and interfaced between the SAP system and other systems and organizations. Reducing the amount of personal information will facilitate the preparation by mitigating risk in the SAP system.

Step 2 – Monitor How an SAP System Exports and Transfers Personal Data

Compliance with GDPR requires the auditing of SAP logs to detect risky behavior by users. All downloads of private information should be strictly justified by a business need, protected, erased when no longer needed, and authorized by the compliance function. For instance, exporting reports by the SAP List Viewer (ALV) without a legitimate business justification is considered a data breach that should be reported. 

A GPDR preparation project should plan how, by whom, and how often the SAP security logs will be reviewed for downloaded data with private information. The protection of downloaded sensitive information outside the SAP system is a related issue to address in a readiness plan. 

Step 3 – Define Action Plans to Anonymize Personal Data

The GDPR recommends the use of data pseudonymization to prevent unauthorized access to personal data. Pseudonymization is a technique whereby the personal data records are replaced by dummy codes to make it impossible to identify the people in question. Pseudonymization still allows some authorized relevant users to display the original master data. 

This is particularly relevant for non-production environments, such as when granting access to developers, testers, functional analysts, and contract workers. Encryption and data scrambling are also valid action plans, and SAP offer solutions for protecting data in development and testing environments (e.g., SAP TDMS HCM 4.0). 

Step 4 – Define Action Plans to Block and Erase Personal Data

The GDPR requires organizations to erase personal data without undue delay when it is no longer needed or when an employee, client, or other third party objects to the inclusion of the data and exercises the right to be forgotten. 

In an SAP system, personal information is not erased, but it is blocked to comply with document retention rules and to maintain the data integrity between tables. Once it is recoded in an SAP system, data cannot be properly erased in a legal sense. However, blocking information prevents further retrieval or processing. 

Step 5 – Get buy-in from the top 

The financial and human resources required for a GPDR preparation project will vary significantly, depending on the seriousness and complexity of the privacy risks. Getting the support from senior management is critical for the success of such preparation efforts. 

Last but not least

Experts in SAP systems should lead organizations in preparing changes in policies, people, and control practices to adopt the data protection principles mandated by the GDPR. Because the GPDR affects anyone handling the personal data of E.U. residents – whether they are based in the E.U. or not – identifying available options in your SAP system to mitigate the related compliance risks isn’t optional. The scale of sanctions and legal requirements mean that compliance is a must.

 

 

Back To Top