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.
Leave a Comment: