The GDPR journey of a data process

July 01, 2021
Written by Paul Hammersley

As Senior Vice-President of the ALM Products at EPI-USE Labs, Paul Hammersley's portfolio includes test data management, landscape optimisation, and archiving. He has been a remarkable technical force in the SAP arena for over 20 years, and has extensive hands-on experience of implementing Data Sync Manager (DSM) and helping clients to manage data across the breadth of their SAP landscapes.

Mapa_blog_TOPBANNER-02

In the last blog in this series, I discussed the merits of redacting sensitive or identifying fields rather than trying to completely delete records in an ERP system, particularly SAP.

 

Now I’d like to explain how we leveraged that approach with one of our clients, MAPA GmbH. It's an interesting story because it brought to life several facets of the GDPR regulations; privacy by design, data minimisation and the role of a processor versus a controller.

Reacting to new (and existing but not well-known) rights

I first started working with MAPA before GDPR came into force. Along with a handful of other existing clients, we listened closely to their GDPR requirements in order to tailor our solutions to meet their needs and what we expected others would also need. The challenge, of course, being that GDPR is not prescriptive at all. It gives guiding principles, rather than firm, actionable items for an IT team. And so, we immediately saw different interpretations of what was needed around an SAP system for our different clients, and importantly, we saw those interpretations changing over time. While at first this was a little unnerving, I think it also helped all of us involved to realise that this really wasn’t a one-off exercise and then everything is done.

 

GDPR will be an ongoing commitment to data privacy and best practice. The first area of focus with all our clients was how to manage Subject Access Requests (SAR or DSAR if data is added as a prefix), and then what to do if that SAR led to a request to be forgotten. We developed technology for both, the latter leveraging redaction, of course. It was interesting to see that in building redaction policies, the idea of retention periods was already starting to surface. Many of our clients wanted to analyse requests from former employees and use the number of years since they left the company to determine what should be removed or redacted for them. In many cases, the identity was not being removed, it was specific parts of the data for which they no longer felt they had legal grounds to store.

 

Proactive retention rules

As the GDPR came into effect, most of the organisations using our GDPR software were still working in a reactionary manner. If someone asked to have some or all of their data removed, a redaction would occur. But the building blocks for retention rules were there. The business had been involved in discussions about what data to remove at what point in time. And, slowly but surely, the push came from legal or audit teams that a more proactive response was required. I blogged back in 2017 about retention rules meaning something different to an IT team compared to an audit or legal team. And I think this alignment of meaning or awareness of the actual status of the data that had passed the retention age, caused organisations like MAPA ‒ to start building retention rules into their periodic processes.

 

We started with the idea of 18 months for the customer order data which resides in SAP as an address and some text entries which may or may not be sensitive. We carried out a mass clean-up of the historical data, processing around 400,000 historic orders over a weekend. In the time it took to plan, test and carry out the historic clean-up, the instructions for ongoing retention came down to 12 months rather than 18 months. We designed a process to run monthly and were investigating how much of that process we would eventually want to automate. I’m a big believer in perfecting something manually before automating it and this was no exception, but we were also starting to think about exceptional cases. How many orders did we expect to be picked up each month? Should we alert or exit if more were found in a given month, or if the previous month’s orders hadn’t been processed yet? While wrestling with this, the situation changed dramatically.

 

Processor obligations compared to controller

Part of the ‘one-time order’ data actually comes from a specific partner marketplace rather than via MAPA’s own web-shop or other resale sites. When renewing the agreement with that marketplace provider, there is a questionnaire to complete on data privacy. The options for the data retention period ranges from very small through to the highest option of ‘greater than 180 days’. This meant that the new retention strategy in-place was in the same drop-down option as forever! For their own web-shop and other partner resale sites, the role played by MAPA was ‘data controller’. They were owning the relationship with the customer and setting out their policies for data privacy. However, for the marketplace, MAPA is acting purely as a data processor under GDPR.

 

Two recent high-profile data breaches and fines (British Airways and Marriott hotels) were both caused by errors made by a data processor, not the main organisation. But the fines and the damage reputation fell squarely at the controller’s feet. Which makes it clear why a partner that is acting as the data controller would insist on a much shorter retention period. They required MAPA to retain the data from their marketplace for only 30 days. And this meant a significant change to our project. With a 30-day retention period, we quickly realised that the process would have to run daily. Otherwise, the retention period would have to drop to 23 days to allow for weekly processing or zero days to continue with monthly processing! This is where MAPA wisely looked at the business process and realised that they could redesign some of the process to ensure that data never resides in the SAP system. The very temporary need to identify the customer by name and address for shipping could exist outside of SAP, meaning that our retention process could return to a more manageable monthly one. The data being processed on behalf of the marketplace would be minimised to only that required to perform the contract’s duties.

 

I think MAPA’s journey through this business process really helps to show that GDPR is actually incredibly well thought out, and that its principles have led to an improvement in data protection for all their customers.


New call-to-action

 

 

Explore Popular Tags

GDPR Data Privacy Data Security Data Secure GDPR compliance Data Redaction data scrambling General Data Protection Regulation Data Redact POPI Act POPIA SAP Data Security SAP GDPR Data Archiving Data Sync Manager SAP data privacy and compliance Right to be forgotten Data privacy compliance Data privacy regulations GDPR readiness GDPR deadline Personal data SAP SAP security GRC for SAP SAP systems Access Risk management Access risk controls Data minimisation Data security breaches Governance, Risk Management and Compliance (GRC) SAP data privacy and security compliance COVID-19 Data Privacy suite Data privacy by design Risk monitoring SAP data copying and masking SAR Soterion Subject Access Request anonymised data Australian Privacy Act 1988 CCPA Cenoti Client Sync Data Protection Day Data masking European operations Federal Law GDPR fine Guest order ICO May 2018 Object Sync One-time customer Privacy by Design Reducing risk Right to Erasure Risk minimisation S/4HANA Migrations SAP S/4HANA SAP data SAP data privacy & security Secure scrambled production data for testing Test Data Management security breach Backlog privacy debt Black Friday Black Friday hangover Black Friday sales Breach Notification Brexit Budget Canada data privacy legislation Cenoti, connecting SAP with Splunk Cloud migrations Confidentiality Consent DSM DSM Readiness Assessment Data Portability Data Removal Data Replication Data Sync Manager (DSM) Data integrity Data processor versus controller Data retention rules Documentation EPI-USE Labs’ solutions Employee data Europe Friday 25 May 2018 GDPR-type legislation GRC GRC for SAP tools General Data Protection HCM HR ILM Information Commissioner’s Office Information transfer Infotype 41 JSOX New Zealand Privacy Act Online shopping Penalties Phantom Proportional Data Protect personal employee data Removing data in SAP Right to Access Rise with SAP Risk management S4HANA SAP Cloud SAP Data Privacy Suite SAP RISE SAP SuccessFactors SAP access risk simulations SAP data encryption SIEM SOX Sarbanes-Oxley (SOX) legislation Security Security Information and Event Management Security for SAP. Live Sensitive HCM data South African data privacy legislation Splunk Splunk UBA Splunk’s Enterprise Security Success Factors Territorial Scope UK Government User Access Review Virtual conference What does the European GDPR mean for Australia? ebook masking rules quality of test data system copy uk sox
+ See More

Get Instant Updates


Leave a Comment: