How widely will companies provide the Right to be Forgotten? Will this be commonplace in SAP systems? Will companies decide to delete data in SAP anyway, simply to lessen their liability?
This is clearly a story still unfolding. SAP by its very nature doesn’t make deletion of data easy. The data and processes of different departments are so intertwined that there are dependencies everywhere.
It was of course the strength of SAP in the first place - the sales department couldn’t create an order unless there would be stock in the warehouse when it would need to be delivered. What happened to that order and that stock would be visible in Finance automatically. So in most cases, SAP lets you ‘mark for deletion’ and then you must run an archiving project which looks at all those dependencies and enforces the rule that documents referencing master data are archived first. Once all dependencies are archived, you can then archive the master data. And of course you can then delete the archive files if you choose to.
This doesn’t sound promising if customers do decide they wish to delete data to help with GDPR compliance. A whole archiving project for one customer master or business partner? Taking the customer master as an example: there are over 100 tables which could store data for one customer master. And some of those tables can have more than one entry per customer. How much of that data is personal? Probably about 20 fields across three or four tables. So isn’t archiving (deleting in the database) hundreds of table entries overkill? A seasoned consultant once told me “many people start archiving projects but not many finish them”.
We’re about to start ramping up a product called Data Redact that can clear fields or replace values with REDACTED, such that the rest of the record is no longer an issue, because it cannot be identified as a natural person. Which fields to clear or redact will vary between data objects and organisations, but this can be handled easily in our implementation. The underlying technology is our data secure engine, but we’re using Fiori apps to control the usage, and then a locked secure policy which is the only one that can run against a production system. We use encryption on the policy, and if anything has changed since it was activated the redaction functionality is blocked. So deliberate tampering or inadvertent errors are prevented.
There may still be a place for archiving if the data is less integrated with other processes, or there are wider performance or volume issues which archiving would also help with. But in many cases, archiving would be picked - and would be the wrong tool for the job. As the saying goes, ‘if you only have a hammer, you tend to see every problem as a nail’.
Customers may have concerns about updating production data with a third-party add-on, but every day of the week they have Z-programs updating production. Like those Z-programs, the implementation of our app Data Redact should be tested before it’s moved through to production.
Some people might want to redact periodically based on rules - we’ll cover that option next time….
Leave a Comment: