SAP ILM and Simplified Blocking for GDPR

Data protection regulations are getting more specific around the globe. GDPR controls the way firms use data of EU citizens, in the same year California state passed CCPA to control consumer’s data, making organizations accountable.

By 2022 responsible enterprises demonstrated their commitment by completing the most burning immediate adjustments on the area of Telemarketing, Promotional emails and Video surveillance but compliance with the “Right to be forgotten” (Regulation A17) and “Destruction at end of purpose” gives massive headache to SAP system owners and can never be complete without proper data management.

• Right to be forgotten
  Upon request, corporations must delete or block the individual’s personal information from all systems based on legal process and related retention periods
• Destruction at end of purpose
  Corporation must stop processing an individual’s personal data once purpose of use is satisfied or consent is revoked. Personal data then needs to be automatically deleted or blocked once the transactional data is deleted based on legal retention period.

This blog introduces how the SAP ILM solution architecture is leveraged to comply with the above regulations and meant for otherwise experienced SAP system administrators as mini-bootcamp to understand the concept prior to technical enablement.

It is crucial to consider that privacy regulations are not on the highest level of compliance requirements. Country or state specific regulations on the area of banking, finance and taxing, all enjoy priority against the data protection rules. As data of business transactions shall be retained by law, companies are also obligated to preserve the related data of consumers beyond the end of business processing, despite the enforcement of “right to be forgotten”.  When the business purpose is due (marked with an orange circle on the chart below), personal data should be destroyed, but as the related transactional data must remain retained due to prioritized regulations, personal data retention is also enforced. Master data remains stored, blocked away from general access, available only for special purposes. This is summarized on chart: “Consumer and Transactional data Lifecycle”

Lifecycle of consumer data and transactional data

Let’s see how enterprises running SAP ERP systems can utilize the ILM framework for the above purpose.
The Business Functions to leverage retention management and master data blocking, are all at the SAP Switch Framework cockpit (t-code: SFW5):

• ILM (Information Lifecycle Management) – Activation of ILM Retention Management functions and
  ILM_BLOCKING (ILM Blocking Functionality) – Activation of Blocking access control
• ERP_CVP_ILM_1 (ILM Based Deletion of Customer and Supplier Master Data) – Activation of blocking consumer data
• BUPA_ILM_BF (ILM Based Deletion of Business Partner Data) – Activation of blocking consumer data on S/4 systems)

Business functions as grouped above may be separately activated with no relation or prerequisite of each other. Activation shall make a bunch of related transactions available, out of which we’re discussing the below few in this post:  IRMPOL (ILM Retention Policies) for configuring Retention Management and Blocking access to the transactional data, and  CVP_PRE_EOP (Block Customer & Vendor Master Data) for blocking access to the Master data regarding Customers and Vendors.  Let’s summarize the functional coverage of these SAP ILM related Business functions and Transactions below:

Functional coverage of SAP ILM related Business Functions and Transactions

Transactional data – Retention Management and Access blocking for business documents. (ILM Retention Policies)

The central point to establish the controls of data accessibility with SAP ILM is the Retention Policy framework. These configurations define how long the data shall be retained prior to final destruction, in compliance with taxing and audit regulations, as well as the time of blocking general access to fulfill GDPR or other, underlying regulations. While the technical setup of the Retention Policy framework was made relatively straight forward via the ILM Help portal articles, the key to understand the expected system behavior is to get familiar with the terminology used in the IRMPOL transaction.

• Residence Period (shown blue in my charts up above) – refers to an indicative period during which the transactional data is actively involved in business processing, subject to changes and updates therefore must reside in the main system database. Business documents are prevented against archiving, blocking or destruction during this period, regardless if processing has already been completed or if business transactions were open still.
• Retention Period (shown purple above) – stands for the validity of transactional data beyond which the data is to be retained prior to destruction. It may also be blocked from general access during this period.
• Time Reference – this parameter is to specify a table-field value, which the application could compare against further defined retention times. (example: Posting date of a financial document)
• Expiration Date (within the purple area on chart) – Minimum Retention Time value set in the ILM Retention Policy beyond which the access to the data is blocked if ILM_BLOCKING is enabled. Data exceeding the minimum retention time can also be destroyed.
• Mandatory Destruction Date (as of the red area on chart) – Maximum Retention Time value set in the ILM Retention Policy beyond which all access to the data is blocked. Data exceeding the maximum retention time must be destroyed, which is subject to a separate executed destruction job. To display such data while not yet destroyed needs a special procedure to issue a legal case to be invoked.

Below is an example of these configurations in transaction IRMPOL, using the above-mentioned evaluation of financial documents by posting date. The retention policy is comparing the posting date of every documents against the min – max retention time periods, which are 15 – 30 years after the posting date.

Financial documents falling within this date range are blocked from general access, the authorization required to display is S_IRM_BLOC / $DPP. There is no special S_IRM_BLOC authorization required to display them prior to the min. retention time is reached. Documents beyond the mandatory destruction date, are expected to be destroyed by the next execution of destruction job. Accessing them would require the establishment of legal hold and authorization S_IRM_BL_M.  Using the instruments of ILM Blocking and Retention management, SAP system owners can establish processes to comply with both legal and personal data related requirements concerning the business documents in their system. Let’s explore further in the next section the tools SAP delivered for blocking access to master data of Customers, Vendors, Business Partners.

Master Data – Access Blocking to Customers and Vendors. (Simplified Blocking)

As appears on chart “SAP ILM related Business functions and Transactions” above, the business function ERP_CVP_ILM_1 is leveraged2, which in practice means execution of report: CVP_PRE_EOP to block Customer / Vendor data. “Simple blocking” obviously aims to block access to all Customers or Vendors which are not actively involved in any open business processes at the time of execution. As shown below, the master data blocking scenario at several points interacts and eventually relies on the underlying Retention Management processes established for transactional data. Fulfilling such a complex criteria requires verification of several, various conditions including the status check of business documents related to the particular Customers / Vendors.

Integration of master and transactional data lifecycle management process

Verification considers:

• Residence period set in Policy framework is due.
  Assumes that the residence period setup at the prior introduced ILM Policy framework is complete, and the application is able to evaluate the End of Purpose status.
• Residence period set for related business document types.
  There is unfortunately no universal location to setup the duration of residence periods within the nowadays recent Netweaver versions and this customizing is identical to most business document types but a short study of SPRO options or a quick search in related SAP Help articles offer rich source of support to locate the appropriate settings. This configuration allows an additional control to the application owners by bounding the set of end of purpose status to a specific duration, regardless if processing has already been completed.
• Document type specific indicator for process completion is fulfilled. (for instance, a finance document cleansed or delivery document marked as delivered.. etc) – Provided the existence of more than a hundred different business processes within an ERP system the execution of such step would literally run forever unless the list of relevant application classes is maintained, which allows to exclude areas out of business use. The customizing is delivered via SPRO / Logistics – General > Business Partner > Deletion of Customer and Vendor Master Data > “Register Application Classes for EoP Check” (of course available only after the activation of the concerned Business function).
• Last but not least, most checks have to be carried out on remotely connected satellite systems, to ensure enterprise level coverage. This setup is enabled by the maintenance of RFC connections in the same group of SPRO settings, referred above.

Once successfully blocked a Customer or Vendor account, the prior introduced $DPP authorization value appears in the account control. The account is blocked for postings and marked for deletion. If changes for any reasons were still necessary, the reversing process is to be executed to unblock the account. (CVP_UNBLOCK_MD)

To close the circle between the blocked Customers / Vendors (master data) and the related business documents, the belonging line items also become unavailable for general access (withouth $DPP authorization) which delivers compliance with the multi level expectations prior introduced.

Despite it’s complex logic, the Customer and Vendor blocking scenario is not a difficult process. Understanding of the overall design and the awareness of each particular procedural step holds the main challenges for most administrators rather than the technical configuration, which is why I choose to focus on these areas mostly.

FAQ

Sharing below some of the most common questions around this topic.

Is it mandatory with SAP ILM to move transactional data beyond the business purpose to an external storage out of the SAP system?

Indeed it isn’t. As shown in my post, SAP ILM framework is leveraged only for Retention Management purposes, with no data management action assigned to the defined periods. Unless we assign the action of data archiving or HANA data aging to be carried out during the retention period, the data remains in the main database until destruction.

Is the setup of Retention Management for Transactional data, prerequisite of the use of Simplified blocking of Master data ?

While the completion of RM setup and creation of active retention policies is a prerequisite, the need to actually process data (and apply a data management action) is subject to the particular business objects which are associated with the Customers and Vendors in scope for blocking. In other words, the implementation of Retention Management rules are prerequisite of the use of Simple Blocking but not all business objects have to be processed by archiving, blocking or destruct prior to succeed with blocking of the related master data. Material management is typically an exception where the establishment of RM rules, would already satisfy the the technical needs to carry out successful blocking of the related master data.

What SAP NW version is required to use ILM Retention Management and Simplified Blocking ?

All functions concerned in this post were released a long time ago, as of SAP NW 740 SP13.