Fulfill GDPR Art.17 (“Right to Erasure”): SAP ILM Simplified Blocking and Deletion

Only 8% of Italian companies declares a lack of knowledge in the new European Regulation for Personal Data Protection (the well-known GDPR acronym), which has become effective as of May 25th, 2018. (Source: Osservatori Digital Innovation Milan Polytechnic).

This means that almost everybody is now familiar with the many GDPR implications on different business departments (legal, admin, IT, etc.)

And when it comes to IT “arena” – for many of the best run businesses – to ensure the SAP system compliance to GDPR is the key topic.

It must be clear that there is no single solution able to achieve GDPR compliance in full.

However, the combination of multiple SAP and non-SAP products can address the numerous requirements from GDPR articles.

In this blog I’ll focus on how to deal with Art.17 (“The Right to erasure”) by means of a specific SAP Solution called SAP ILM Simplified Blocking and Deletion.

Art. 17 of Regulation (EU) 2016/679 (General Data Protection Regulation or GDPR in short) is known as Right to erasure or “Right to be forgotten”.

It basically states that you should not keep personal information for a time longer than its business or legal requirements:

“The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:

• (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
• (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
• (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
• (d) the personal data have been unlawfully processed;
• (e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
• (f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).”

We are mainly interested to point (a) and (e) of the above-mentioned article, which outline the standard process of a piece of information in an SAP ERP system: when I agree on a contract with a customer or vendor, and I trace it in my ERP system, I’m initiating a business process that is supported by specific chunks of information distributed in my system.

This information has a lifecycle, and – in the context of GDPR – I should access it only when the business purpose is valid; and I should keep this info stored in my system no longer than the retention legal requirements of my EU Member State.

SAP provides its SAP ILM (Information Lifecycle Management) solution to support data information maintenance within SAP systems.

SAP ILM – historically- has been designed and conceived for two main targets:

1. To manage the retention policies for the information stored in the Database.
2. To decommission one or more SAP and legacy systems, while keeping some critical data available (on-demand) for auditing purposes.

In the more recent context of GDPR compliance, the retention management feature of SAP ILM perfectly fits for addressing Art.17 (right to be forgotten) of the EU regulation.

SAP has recently included in the SAP NetWeaver license the usage of SAP ILM for managing the retention of Personal Information.

So, if you haven’t done it yet, this is the right time to evaluate the leverage of SAP ILM capabilities for achieving GDPR compliance.

Before we go into the technical details of SAP ILM, I want to clarify some main concepts on which SAP ILM is based:

• End of Purposes (EoP) – It is basically the condition (a) of the GDPR article and identifies the limit until when I can process Personal Data, in connection with the need to fulfill a business agreement;
• Residence Time – It is a time frame, after the end of a business process, in which I should be able to access personal data for business reasons. E.g. if close a sales cycle (sales order, delivery, billing document and customer item clearing) today, very likely I’ll still need this information for a certain amount time (for providing customer support, for product warranty assurance and of course for closing the fiscal year…).
• Retention Time – It is the time I am obliged by the law to keep some fiscal relevant data (e.g. retention time for billing document in Italy is 10 years).

With those three concepts in mind, we can analyze how ILM can help us to manage the lifecycle of the information.

ILM was originally developed by SAP to help customers reduce the total cost of ownership (TCO) of a running SAP system. The main target was to shrink the storage size of an SAP system by moving obsolete data ( = no more business relevant ) into a separate – and cheaper – storage system.

You might argue that this is exactly the same driver for a standard data archiving project in an SAP system.

What ILM added (on top of the standard SAP archiving functionality) is the possibility to define some retention rules for triggering automatic destruction of data, as soon as the retention time is over.

The following picture describes the ILM standard process:

ILM-Aware Store is a special type of attached storage that supports the WebDAV protocol to enhance the stored data with some metadata that defines the retention policies of the archived data. In this way, when we archive some data with the help of the ILM, we can automatically delete the data when the retention policies are expired.

ILM supports two kinds of storage:

• WebDAV servers for ILM Store or ILM Aware Store – a list of certified storage providers that support the ILM WebDAV interface, you can find the list of certified providers in, by filtering with BC-ILM SAP Certified Solutions Directory
• ILM Store based on SAP IQ or SAP HANA – In this case we are not using a third-party server that supports WebDAV interface, but we are connecting another SAP Database as sidecar database for storing data with the ILM retention policy. Recently, with the data protection requirements related to numerous legal regulations, SAP has decided to extend the ILM Retention engine to cover also data protection requirements.

Anyhow, SAP probably realized that the main limitation to a wide adoption of the ILM solution was the complexity required by the need to set-up and connect an external storage system.

Therefore, and more recently, SAP has released a new solution – called Simplified Blocking and Deletion – to manage the block and removal of Business Partners, Customers and Vendor master data, whose business purpose has expired.

Simplified Blocking and Deletion does not require an external storage system, as the master data is blocked directly on the online database, and it reuses the same retention and residence policies of the ILM retention engine.

Naturally the Simplified Blocking and Deletion Scenario has some restrictions to take into account:

• It is available only with following SAP release:
  • SAP ERP 6.0 EHP7 SP12
  • SAP Supplier Relationship Management 7.03 EHP3 SP05
  • SAP Customer Relationship Management 7.0 EHP3 SP05
  • IS-UT EHP7
  • SAP ERP Human Capital Management 6.0 EHP6 SP16
• It supports blocking of master data only (Business Partner, Customer, Vendors for ERP and additional master data for the other applications, like SCM Locations). In the next chapter of this blog we will see the main steps for the implementation of a Simplified Blocking and Deletion for Customer Master with the support of ILM.

Simplified Blocking and Deletion for Customer Master

The main SAP note for Simplified Blocking and Deletion is the following one:

• 2007926 – Simplified Blocking and Deletion of Customer / Vendor Master Data

Installation of ILM is based on the activation of business functions (transaction SFW5), please remember that ILM Business Functions will remain active (you cannot switch them off if you decide to not use ILM), so activate them only when you have verified all license aspects and, if you want to test ILM, use a sandbox system.

We must activate these functions:

Activation of those functions will make available the transactions and reports we need to execute ILM Simplified Blocking and Deletion, here the list of the most important transactions:

• ILMARA – Audit Area Processing
• IRMPOL – ILM Policies
• IRM_CUST_CSS – IRM: Customer-Specific Settings
• CVP_PRE_EOP – Block Customer & Vendor Master Data
• SD_EOP_INDEX_REBUILD – Rebuild Index Tables f. SD EOP Check

ILMARA, IRMPOL and IRM_CUST_CSS are ILM specific transactions where you can configure the Residence and Retention policies used to block and delete customer data.

CVP_PRE_EOP and SD_EOP_INDEX_REBUILD are transactions specific for the Simplified Blocking and Deletion of the customers (or vendors) where you can execute the blocking of Customer or Vendor data.

Before we introduce those transactions, it is important to define following main concepts of ILM:

• ILM Object: You can think to an ILM Object like an archiving object, so it is a logical aggregation of connected data structures (like all data related to a Customer master). ILM defines the retention rules customizing using the ILM Object as logical aggregation (e.g. I define retention rules for Customer Master and these rules apply to all tables where Customer Master data is stored).
• Object Categories: In ILM you can have two kinds of ILM objects: related to structured data (SAP Business Object – OT_FOR_BS) or ILM Object related to unstructured data (Paper Documents – OT_FOR_PD).
• ILM Audit Area: An Audit Area groups a set of ILM objects that are related from a business point of view, e.g. you can group all ILM objects related to Tax retention rules in the same Audit Area.
• ILM Policy: At ILM Policy level, you define the retention or residence rules for an object within a specific Audit Area.
• Policy Category: There are two categories available for defining ILM Policies: Retention Rules and Residence rules.
• Policy rule: Here is where you define the retention or residence values (e.g. max and min retention value, residence time and some conditions, like company code values or country id, for which the rule is valid).

This picture, taken from the SAP Help Online, explains the configuration levels of ILM customizing:

Basically, we are saying that for ILM Object SFLIGHT, that belongs to Object category SAP Business Suites, for policy category Retention rules in Audit area SFLIGHT_A1 we are defining a policy that retains the data according to the rule values.

At the end, ILM Objects aggregated the data on which we want to apply the retention and residence rules and Audit area, Policy and Rules define how we want to mange this data from a residence and retention point of view.

Let’s analyze now the transaction we have seen before and see the customizing we must implement if we want to block Customer Master with ILM Simplified Blocking and Deletion.

In ILMARA you activate the ILM objects on a specific ILM Area. For Simplified Blocking and Deletion, you should activate following ILM objects (it depends on which Blocking scenario you want to use) in Audit Area BUPA_DP, that is pre-delivered by SAP:

• FI_ACCRECV – Customer Master Data
• FI_ACCPAYB – Vendor Master Data
• FI_ACCKNVK – Contact (Data destruction)

In our case, since we want to block only Customer Master, it is enough to activate FI_ACCRECV object:

After having assigned object FI_ACCRECV, we can define the residence period for this ILM objects, transaction IRMPOL is used for residence and retention rules definition.

In this example we are defining a residence time of 12 months:

As we have seen before, rules are defined for Audit area, Policy and ILM Object and Object Category.

In transaction IRM_CUST_CSS – IRM: Customer-Specific Settings – it is possible to define some Rule Groups for which we define the default residence and retention values (e.g. in an ILM standard scenario, we can activate many ILM objects that use the same retention values, to keep this consistent we can define the standard values for the residence and retention time in a rule group):

For Simplified Blocking and Deletion, start time for residence and retention rules must be defined with value START_RET_DATE (Start of Retention Date). We will see later how each application analyzed by the Simplified Blocking and deletion will check if the business process is complete to set this Start of Retention Date.

As soon as we have completed the ILM retention management customizing, we can execute the transaction for blocking a customer. But we should first understand how the Customer Blocking transaction works. For doing this we can use following picture taken from SAP Help Online that explains the process:

As we can see, on the left we have the different steps of a business process, as soon as the process is complete, the system identifies the date from which the retention time can start (Start of Retention Time, we have already seen this threshold in the ILM customizing). After the Residence Period we defined in ILM Policy is complete –End of Purpose – we can block the customer with the Simplified Blocking and Deletion Transaction. At the end of the Retention Period, we can remove Personal Data with ILM destruction functions.

The main transaction for blocking Mater Data is CVP_PRE_EOP – Block Customer & Vendor Master Data:

This transaction can be used either to block Customer Master data and Vendor master data and the main tasks of this transaction are:

1. Verify that all business process for a customer or vendor are complete and identify the very last Start of Retention date;
2. Calculate the Residence Period defined in ILM customizing;
3. If the Residence Period is complete, that means the End of Purpose is reached, block the master data.

We can have many different business processes that use a Customer master data, SAP provides already the functions for validate the completeness of more 120 different business processes, but it is also possible to define our own ABAP classes for crosscheck the completeness of a custom business process.

This can be done in following customizing activity:

Logistics – General >> Business Partner >> Deletion of Customer and Vendor Master Data >> Register Application Classes for EoP Check

SAP provides some API for the definition of End of Purpose checks, but it is quite a complex topic, if you need some support, please contact us!

Execution of Customer/Vendor blocking can be done either in an Interim Check (Local) way or in Overall Check. The idea here is that we can have a central master data system (SAP MDM) that distributes the master data in many satellite systems and, before blocking the data we must check the business process status in all connected systems and only when the End of Purpose is complete in all the systems, block the master data.

This transaction saves the status of a blocking run in table CVP_SORT and for each master data and application that identifies a business process, we can have one of following statuses:

1. n/a (no Business made with partner at all)

2. No (Business is ongoing with partner)

3. Yes (Business is complete and Residence time is over)

Only when all applications have status 1 or 3 the master data is blocked.

Conclusions

As we have seen, at a first sight the process for Blocking and Deleting a Customer or a Vendor Master data may appear quite complex and cumbersome to implement.

However, implementing a thorough strategy for managing it will pay back shortly.

Not only a reduced TCO and smooth-and -lean SAP system will be accomplished, but also the desired compliance to GDPR Art.17 can be achieved by means of the “ILM Simplified Blocking and Deletion” scenario.