The impact of GDPR and data privacy regulations on employee data

H&M’s GDPR fine recently made news headlines with an eye-watering fine of €35.2 million for excessive employee surveillance. This has been the first large fine that pertains to employee data under the General Data Protection Regulation (GDPR). Read the full details about the fine.

A quick summary: In 2019, H&M’s Service Centre in Nuremberg had a data breach via a configuration error that revealed the extent of the data the company had collected about the private lives of its employees since at least 2014. This breach included collecting and storing large amounts of data about holiday experiences, family issues, religious beliefs and symptoms (and diagnoses) of illnesses. Prof Dr Johannes Casper, the Hamburg Commissioner, stated that the case “…documents a serious disregard for employee data protection at the H&M site in Nuremberg.” With the size of the fine, the German protector wanted to make sure companies understand the importance of employee privacy.

H&M has taken full responsibility, and apologised to its Nuremberg employees. They are also adapting their procedures to avoid this happening again.

How much data is excessive? How much data is enough?

As part of the GDPR, the principle of Data Minimisation focuses on having adequate and relevant data relating to the purpose, but also ensuring that data is limited to only what is necessary. Storing and processing excess data goes against this principle. This can be a grey area, but clearly the message is less is more.

To start with, ask yourself: “When am I next going to get data from Production and what projects do I have to test in between?”. This determines the data you need, so some key questions:

• Do you need your employee data for testing in this period? If yes, can you split this to another client with increased controls/segregation, or does it need to be in one place?
• Do you need data change history? Can you exclude your HR audit trail, change documents, workflows, IDOCs, all of which contain personal data?
• How much transactional history do you need? If you’re going to refresh again in six months’ time and no year-end processes are being tested before then, why not only copy three to four months of data?
• Outside of the data itself, also check if the accesses are appropriate per user. Everyone has increased access outside of production; the greater the access, the greater the risk.
• Finally, does any test actually require real customer/employee PII, i.e. if the data was changed or shuffled so no real data remained connected, would this impact your testing?

I have found that following an honest review, typically, for the majority of data a copy back of six to nine months’ transactional data, with no Change document/Workflow or IDOC history, is sufficient for a full year's worth of testing. Also, the majority of testing and interfaces are reliant on the key information, not the PII values of names, addresses and telephone numbers. Under audit, anything above this ‘need’ could be considered as excessive.

How can you minimise your data?

In the H&M case, someone clearly meant to take data they had no right to store even at the time. But for most companies, the challenge is knowing when personal data goes from being relevant for the products and services being delivered, or employment terms engaged in, to something the company can no longer justify holding. For example, a year after leaving a company I would understand them keeping my phone number, but ten years later, I would not.

At what point does it switch? And how can we retroactively clean up data past the point at which we feel we should be retaining it in a complex and interlinked ERP system like SAP?

There is, of course, software on the market purpose-built to slice your data during data copies (EPI-USE Labs would be happy to discuss this with you). However, there are also methods through which you can control this risk within normal processing:

1. Archiving and clean up: I have found some client organisations find this difficult and expensive, but it is necessary. In Production, this causes concerns about continuing business, but in non-production this can be more easily executed which reduces the risk and simplifies the decisions.
2. Standard SAP programs: SAP has provided programs which remove unwanted data, deleting Workflows and IDOCs. You could study what can be done as standard, and modify as needed, such as build DB deletion scripts to instantly remove all data if this would be acceptable.
3. Authorisations: No one wants to limit DevOps and be more inefficient, but there can still be control on table accesses, SQVI queries etc to limit the risk of large-scale breaches.
4. Production processes: Update your procedures to limit recording data to what is needed for work performance. Don't carry more risk than you have to.

The final question above about scrambling or changing the personal details in your system can be one of the most challenging issues to address. You want production data quality, but none of the risk. This is where external expertise will really help. In my experience, I have found improvised solutions will work, but not efficiently. I find EPI-USE Labs’ approach much more efficient, as we bring software along with the experience of helping a great number of companies across many industries, which is invaluable to our clients.

What other types of data examples should you look out for?

When it comes to GDPR, everyone is thinking about client data and how organisations are working with their clients and prospective clients. But this H&M fine puts more focus on employees and their personal data.

Now, of course you need to keep your employee data even after they have left your employment, but for how long? And all of it? Consider the following examples:

• Family member details held in PA0021 – as soon as your employee has left your company, what legal entitlement do you have to hold their spouse’s personal details?
• Bank details – once the final payroll run has been settled, what legal justification do you hold to maintain the person's bank details? Should any adjustment be needed, I’m sure they will contact you to arrange it.
• Addresses – you will wish to maintain the latest address on record, but the one they lived in three years ago, is that your information after they leave?

A few clients I have recently worked with have stated during our first meeting, “We already have retention rules for employee data.” But one simple question often confuses the team: “What about their linked Vendor?”. Or another common point is “We use auth controls to protect our data.” Unfortunately, this doesn’t help if a data breach occurs, so it is always more secure to actually remove the data.

Finally, even your transactional SAP data isn’t safe. A large proportion of clients I speak to have configured the Expense Account documents to include in them a text field which summarises the name of the person being paid along with other details.

We have learned a lot of lessons over the last two and a half years since GDPR has been in effect. But it can be a daunting prospect to understand the breadth of data kept in your SAP system and the amount of GDPR risk this can provide. EPI-USE Labs is able to help you to gain more insight into this area.