What should the Data Protection Officer do in SAP systems?
The Data Protection Officer (DPO) is a figure that was introduced by the GDPR (the European Data Protection Regulation).
It is a figure who independently supports the data controller to protect and manage personal data. Articles 37, 38 and 39 of the European Regulation define this figure.
One of the goals of the DPO position is to conduct periodic audits to verify that personal data are being handled properly.
But what to do within SAP to carry out this audit? Here is a list of activities to perform.
It can be very easy to export data from SAP. One of the verification aspects might be understanding how much the SAP system does or does not allow or how it is protected with respect to exporting data.
We talked about this topic in the following article: How to export data from SAP?
The use of tools like SAP DAM Dynamic Authorization Management di NextLabs possono essere un ulteriore aiuto.
Remember that you can also see who downloaded what from SAP using the SAP Security Audit Log.
A new functionality introced by SAP is the UCON meaning Unified Connectivity.
This tool enables you to think about the management of calls towards SAP from a third party system in a way that wasn't possible until today.
In fact, by default, the services exposed by SAP are callable, but only after authenticating and following the authorization check phase it's possible to execute a specific functionality like exporting data (by using the function recall or BAPI).
Thanks to this tool, included in the SAP suite, it's possible to activate a log which is used to identify the calls made and, as a result, creating a whitelist of functions that can be recalled and by whom.
Over the security aspects and secure development, read here the 10 basic rules for secure development in SAP, also the minimization of personal data is important.
In other words, reports should expose only personal data closely related to the use of the feature.
All the personal data possibly present but not strictly necessary should be removed.
This principle is called Data Minimization.
It is certainly a key aspect of ensuring that only people formally authorized to access certain data (in this case personal data) are allowed to do so.
In this case, even reading alone can be critical.
Through a tool called SAP Field Masking it's possible to use two functionalities:
The first lets you mask or hide with * (asterisks) a certain field and the second lets you trace who has seen a certain information by indicating the transactions and the fields
Usually in SAP landscapes there are at least three environments, which are divided in development, test and production environments.
More or less frequently the production system is copied in the test or pre-production system.
In these last two systems the profiling can be less stringent than in the production system, making the segregation in the production system useless if a user has more permissions in the test environment rather than in the production environment.
This is why it's necessary to evaluate if it's necessary to create a logic of data copying which takes into consideration:
In the production system my user is called "Massimo Manara" in the test system, but once copied I will be called Renato Rossi. Beware, not by chance, I will always be male, this is to ensure for example the consistency of the data and population (in case we are talking about people).