Staying on top of customer information is crucial for system administrators. Like master and transactional information, customer data can grow stale and unhelpful for business activities.
In fact, there may even be a legal requirement to delete and forget personal data in accordance with data laws such as GDPR.
With SAP Information Lifecycle Management (SAP ILM), administrators can easily delete personal data to stay compliant with law.
Permanent Deletion
The final deletion—that is, the destruction of master and transactional data—is a separate field of expertise with which we assume you’re already familiar. Further information can be found on https://help.sap.com or in the SAP Training Course BIT665.
In short, if you want to permanently delete—that is, destroy—your data on the basis of IRM rules, you need to execute the following steps:
- Decide how many audit areas you want to use and which names these should have.
- For each audit area, define suitable, productive retention rules for the relevant SAP ILM objects.
- Install a certified SAP ILM storage for the archive files, which should be entered in the ILM Storage column of your policy, provided you want to archive the data before destruction.
Blocking and Deletion of Personal Data
We’ll now proceed to the main subject of this blog post and the special knowledge you need about SAP ILM in connection with the simplified blocking and deletion of personal data.
In this context, you need to pay attention to the Authorization Group column of your retention rules and its meaning when blocking data. This post provides information on how an archive file is protected by authorizations so that access to the data it contains is effectively blocked. Let’s illustrate this using the example of a delivery, as shown in the figure below.
As soon as you activate the business function ILM_BLOCKING, Transaction IRMPOL (ILM Policies) also provides the new Authorization Group column. In the example used in the following figure, you can see the value FIAU.
In addition to the S_ARCHIVE authorization object, a user must have rights for the authorization group specified in this column if he wants to access archived data.
As soon as you’ve archived the data, it’s protected by additional authorizations, so that access to that data is effectively blocked.
The check is performed for an archive file if a suitable, productive retention rule for the corresponding SAP ILM object exists.
Applicability
A few notes on this check are as follows:
- This check is independent of the archive file’s creation date.
- The check is even effective for archive files without a calculated retention period because the check can be run directly on the basis of the data from the data object of the archive file.
- Further information can be found in SAP Note 2167473.
The next figure shows authorization object S_IRM_BLOC, which allows you to set up the authorizations for the archived data in more detail by using the following:
- Audit area
- SAP ILM object
- Assigned authorization group
The logic behind this is based on the audit areas in SAP ILM; you can store authorization groups in their rules as described earlier. If the data is already in the archive, the system then determines the corresponding audit area and the retention periods stored there for the requested, archived data.
It also checks in the user master data of the user requesting the data regarding whether the stored authorization group has been assigned.
You can only use the blocking discussed here by means of archive files if you’ve configured the required settings in SAP ILM. See the following:
- SAP Note 2169333 (Blocking of Already Archived Data)
- SAP Note 2167473 (User-Specific Blocking of the Display of Archived, Personal Data)
Special Cases
We’ll close this post with some important information about special cases.
A special case is the constellation in which the user is authorized to view blocked data, but the data’s retention period has expired. The system will treat this case as if the user doesn’t have access rights to the data. The requested data won’t be displayed because it should have been destroyed already.
However, there is an exception. You might anticipate a case in which access to such data is mandatory; namely when the requested information is contained within a legal case. For this reason, you’re provided with a special authorization object—S_IRM_BL_M (expired resources grant access)—as shown in the final figure.
This means that you assign the authorization object to those users in your company who process the legal cases and therefore need to access this special category of data.
Conclusion
Blocking and deleting personal data is very important for businesses that do business in or with residents of the European Union. Regardless of your business’ location, however, keeping a tight leash on personal data can help keep customers happy. By utilizing the information laid out above, you’ll be able to feel confident in your data management landscape.
Learn more about SAP Information Lifecycle Management in this blog post.
Editor’s note: This post has been adapted from a section of the book GDPR and SAP: Data Privacy with SAP Business Suite and SAP S/4HANA by Volker Lehnert, Iwona Luther, Björn Christoph, Carsten Pluder, and Nicole Fernandes.
Comments