The impact of GDPR and data privacy regulations on employee data

16 November 2020
Written by James Watson

James is responsible for the global line of business for EPI-USE Labs' data privacy and SAP IS-* Solutions, supporting all regions and key accounts running Data Sync Manager (DSM) for these complex requirements. With a functional and business background of over 20 years, James provides the bridge between Development, Basis, Test/Competency Centres and leadership teams to provide guidance and advise on the route to data privacy compliance. His history includes SAP specialisms in non-production data management and anonymisation, Production data removal or redactions, System Landscape Optimisation (SLO) and SAP industry solutions.

blog_blog_-impact-of-GDPR-on-employee-data_header-image

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.

 

Making GDPR Compliance easier

 

 

Explore Popular Tags

GDPR Data Privacy Data Security Data Secure GDPR compliance Data Redaction data scrambling Data Redact General Data Protection Regulation POPI Act POPIA SAP Data Security SAP GDPR SAP data privacy and compliance Data Archiving Data Sync Manager Data privacy regulations Right to be forgotten Data privacy compliance GDPR readiness GDPR deadline Personal data SAP SAP security SAP systems GRC for SAP SAP data privacy and security Access Risk management Access risk controls Data Privacy suite Data minimisation Data security breaches Governance, Risk Management and Compliance (GRC) compliance COVID-19 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 EPI-USE Labs’ solutions 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 Diclose Data Portability Data Removal Data Replication Data Sync Manager (DSM) Data integrity Data privacy assessment Data processor versus controller Data retention rules Documentation 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 News Online shopping Penalties Personal Data Protection Law (PDPL) 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 Saudi Arabia 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: