Two years into the General Data Protection Regulation (GDPR) regime, experience has shown that many organizations have managed to understand and incorporate the GDPR basics into their IT environments, in order to demonstrate their compliance with the Regulation. However, we note that many are currently struggling with more complex exercises, including the performance of data protection impact assessments or aligning their current data management activities with the GDPR principles.
In the context of the SAP IT landscape, the main concerns will lie in the understanding of the scope of the GDPR-reach, accurate data identification and developing the means to adequately remove any obsolete personal data. This article looks into some of the intricacies of managing GDPR compliance within the SAP environment.
Absolutely. Whenever an ERP system is used to control your internal or external business processes, it is likely to involve processing of personal data and there is no getting around the GDPR. Whether your organization uses a SAP solution, or any of the other ERP solutions in the market, the core privacy principles will have to be taken into account. We do have to consider that solutions such as SAP, Oracle or Microsoft Dynamics are often already of a certain age, and all pre-date the latest privacy legislations. These tools and solutions were never built with these stringent requirements in mind, and have not made it an easy process to ensure full privacy compliance in these complex environments.
Nonetheless, a pragmatic approach should always be considered and the impact on your business will strongly depend on the scope of your activities. With a risk-based approach, you will or should tackle the privacy requirements for your SAP environment in a different manner when your entire B2C customer database and financial records are controlled via SAP, to when your organization operates in a B2B environment where the personal data in SAP would be limited to the user accounts and your business partner contact details. Apply the 80/20-rule, and focus your initial efforts on a set of ‘quick wins’ and the less complex operations, while defining a clear action plan and roadmap to cover the entire scope and privacy requirements in an acceptable timeframe.
This is a question we will not be able to answer in just one article. No single option can be considered as a straightforward 'plug-and-play' solution, but rather will require extensive tailoring to your specific organizational environment, as well as collaboration with both internal and external stakeholders. Managing (personal) data is no different in SAP than in any other application or environment. The answer to this question lies in the correct and complete incorporation of the privacy principles into the data lifecycle stages of collection, storage, usage, retention, destruction and transfer.
As it currently stands - and given the complexity of the solution - SAP has resulted in an environment where no single user has a complete view of the scope and contents. Being built upon thousands of tables, transaction codes, programs and endless ABAP (Advanced Business Application Programming) - a high-level programming language created by SAP - customizing possibilities, in theory a straight-forward exercise, becomes an entire undertaking that impacts a large portion of the business. Given the age and breadth of your local SAP environment, and the modules on top of a default system such as Sales & Distribution, Human Capital Management, SAP BI or CRM, this exercise can rapidly become a nightmare for project managers and business stakeholders.
The initial goal of any privacy program in SAP should be to first understand your SAP environment, data, and processing activities. Once you have defined the basics, we can deep dive into the details, including how to find users that have access to your personal data, evaluate the effectiveness of implemented security controls, how to remove data from your IT environment, assess risks to data subjects on the basis of the information received, etc.
Before we can dive into the details, any business owner should understand their playing field and have a clear view of the ins-and-outs of the overall IT landscape. As an organization you will have to, and already should, understand where your (personal) data comes from and where it flows to.
As a part of this process, it is important to be able to answer the following questions: Is SAP your source system of the data, do you collect the data directly from the data subject or does it come from an external party? Are there other applications that SAP feeds into? This will be important to understand the impact any change to the data in SAP might have towards the overall application landscape.
Once you truly understand your internal landscape and environment, we can focus on the data and information within the systems. What data are you processing in SAP? HR and payroll data, customer records, vendor contact details, consumption data, user data and logs, etc.? Are you processing any special categories of data, including medical, judicial or racial records, social security numbers or information on children? Might you be processing data of a highly sensitive nature, such as credit card data, financial records or the social status information of vulnerable people? How is your SAP landscape defined? How many production environments do you have in place? It will also be likely that you have development and testing systems in place - would there be any personal data stored in these environments?
Once a clear view of your SAP landscape has been created, and ideally also documented (take this opportunity to document your processes and IT landscape, and also take the time to revise a number of aspects where required), it is time to focus on which data should be assessed, managed and reviewed. Personal data will be stored in tables and fields, and will be accessed through a series of transactions and programs.
The initial focus should be on the identification of personal data and performing an assessment of all users having access to this personal data - both in terms of display and maintenance rights. A first step will be to find all possible tables and transactions that potentially hold personal data. This exercise has to be initially performed by listing all activities that are performed in SAP, all possible categories of data subjects and documenting all possible data elements that could in theory be stored in SAP. Examples here can be found in ‘name’ which could potentially be found in 125 different fields, ‘email’ in 14 fields, or ‘gender’ in 7 different fields.
The completeness of this assessment is key, as we do not want to miss any possible (sensitive) data elements. Once a complete list of data elements (for instance, name, address, gender, birthdate, etc.) has been defined, these activities can be linked to transaction codes and tables in SAP.
This discovery assessment will be unique and tailored for each organization and based on a series of workshops, walkthroughs and sessions with key stakeholders. We can however kick-start the exercise based on a number of 'default' master data tables, Customers (KNA1, KNBK, KNVK), Vendors (LFA1, LFBK), Addresses (ADRC, ADR2, ADR3), Business partners (BP000, BP030), Users (USR01, USR03), Credit cards (VCNUM), or based on standard SAP HCM info types. By default a customer will have an address, with a street name and a city, some contact details, email and/or phone number, a first and last name. However, some organizations will store additional details such as a birth date, household composition, risk scorings, gender, etc. - all data elements that will often be unique to the organization and its business.
Given the limited set of ‘standard’ master data tables, the extensive exercise starts when trying to identify all ‘other’, less standard, relevant tables and fields. There are numerous tables that would potentially hold personal data (SAP will often hold over 100.000 different tables), and that is even without taking into account any customized tables. SAP has, by default, provided (limited) tools to aid in this assessment, including for instance the ‘Where-Used’ functionalities for domains/table fields related to personal data can be used. This functionality can be used and, based on basic keywords (gender, birthdate, etc.), it is possible to search for relevant column headers in tables that might hold relevant data. Given the width and depth of the potential scope, it quickly becomes clear that this is not a single day assessment, and that input from all involved business units and subject matter experts will be required.
Once a complete overview has been defined of all tables holding personal data and for each environment, it is only a short step to list all users who have access to these tables based on their current SAP authorizations. The information will then provide the input towards the access management exercises and aid your organization in limiting access to personal data to those users who require the information for their business purposes.
Given the correct and thorough execution of the above activities, the main deliverable of this partial exercise should be a complete overview of all personal data in all of your in-scope and relevant SAP systems, linked to their respective tables and locations in SAP. This information will then feed into the next steps of your SAP privacy compliance exercise, including any data retention and removal activities.
Do you have questions regarding how to manage personal data in SAP within your organisation? Please reach out to our experts for further advice via: email@example.com