Data Rentention in SAP why may it be needed? Not only for data security reasons or compliance with the GDPR.

What does it mean in SAP to manage data retention?

Why should I manage data retention in my systems?

For several reasons, not only related to regulatory aspects, for example:

• not all data need always reside in the system or otherwise be always available and online
  
  
• the size of one's database may have a high growth rate. This also involves having to adapt one's systems, often purchasing space or new infrastructure. In the transition to S/4HANA this could be an interesting point of attention
  
  
• performance in the activities of building new systems (e.g., system copies). Test systems management also has implications for data security, learn more about this here
  
  
• overall system performance. Accumulating a lot of data in general can lead to lower performance during data processing

Finally, regulatory aspects, for example:

• internal policies
• Adaptation to the European Data Protection Regulation (GDPR) for the management of personal data

Deletion/anonymization or archiving of data?

These are different approaches; we often use some terms as if they were synonymous. In reality they are not. Let's take a look at some cases regarding manufacturing environments.

• Data deletion. In this case for SAP we refer to the physical deletion of the data. Note that it is not present in all cases. Also, it is not always necessarily in compliance with regulations.
  
  
• Data anonymization. Here we mean making a certain piece of data unavailable or unrecoverable. So going to physically overwrite a certain data (there are specific solutions on the market, like the one from EPI-USE for example called Data Redact) or SAP's Masking solution (SAP UI Masking for ECC or S/4HANA systems). Where in this case the data are not modified at the database level, but are presented to the user masked by means of asterisks **** (somewhat like when a credit card number is partially hidden. In the latter case, those who are authorized may still be able to read the data. Whereas with solutions that physically modify the data, it is not possible to do so

• Data storage. In this case we have a different solution that partly overlaps with the others. That is, through the standard SAP data archiving mechanism (beware of custom processes, in this case archiving objects must be built to take advantage of this mechanism) it is possible to extract data from the system and archive it on some medium. In addition, through the SAP ILM (Information Lifecycle Management) suite, it is possible to determine who can and cannot read the data in the archive in a timely manner. Following a certain point in time (retention rule) one can delete the archived data. Thus, a direct deletion does not take place (see first case above) but the archived data is deleted once a certain period of time has elapsed.
  
  

While for NON-production environments (e.g., test or quality systems) we talk about data scrambling or, in this case, also deletion during copying. See the specific article on scrambling here.

5 points of attention

1. Check whether you already do data archiving or not
2. Check whether the archiving system you eventually have is compatible with the SAP ILM product 
3. Evaluate whether you can take advantage of the SAP archiving mechanism or whether you need to head for a different strategy
4. Define the purpose of your work. Are you doing this activity primarily for "operations" purposes or for "compliance" purposes? 
5. In each case do a risk assessment on the solution you want to implement, especially with regard to GDPR compliance. Keep non-production systems in mind as well

Topics: gdpr, sap ilm, sap data masking, data privacy, sap data obfuscation