Imagine this scenario: An ex-employee comes to your organization and demands that you delete certain sensitive information from the company database. The head of HR politely explains that, due to certain laws in the U.S., those records need to be kept for three years. The ex-employee threatens to take legal action to have the records deleted, citing current data privacy laws.

This is not a far-fetched scenario at all. There has always been a tension in the law between requirements for data retention—that is, how long records need to be kept to stay within compliance—and data privacy.

But the tension has been on people’s minds recently because of “The Great Resignation.” More workers now are leaving their current jobs than at any other time over the past two decades. The U.S. Department of Labor, for example, has been reporting record-high resignation numbers for months, with the latest record of a 3.0% quit rate happening in September 2021.

Let’s leave aside, for the moment, why people are quitting and how companies are responding. The glaring issue here is that companies now have record numbers of ex-employees. And this is bringing the issue of retaining sensitive employee information to the fore. Combine this with stricter privacy laws and penalties for over-retention, and it’s no wonder data retention has become one of the biggest topics when it comes to data security and data privacy.

Here at Mage, we are not legal experts and do not pretend to give legal advice. But we can say something about the ways in which data should be protected, and how access should be carefully controlled, to satisfy both data retention needs and privacy concerns.

What Counts as Private Employee Data?

The first thing to be clear on is that there is no one universal definition, legal or otherwise, for what counts as private or sensitive employee data. But there are clearly some things that everyone agrees fall under this category:

• Employee addresses/places of residence
• Social Security numbers
• Dates of birth
• Salary information
• Insurance information
• Medical records
• Bank account information

In general, sensitive data includes anything that an employee would have a “reasonable expectation” would be kept confidential and used only for the employee’s benefit. Thus, it includes the types of information that are regularly gathered by employers to process payroll, manage employee benefit plans, etc.

The Tension Between Data Privacy and Records Keeping

Data privacy runs into an issue when it comes to data retention and records keeping. For example, under the U.S. Fair Labor Standards Act (FLSA), employers above a certain size must keep payroll records for at least three years, even after an employee has subsequently left a company.

Now imagine what needs to happen for a company to be in compliance with, say, the European Union’s GDPR (which is any company doing business in the EU, regardless of whether they have an EU location). Under the GDPR, employees must be informed about:

• What data of theirs is collected
• Who owns or controls that data
• Any third parties that receive their data (such as payroll providers or benefits providers)
• Their rights and protections under the GDPR

Because records must be kept for three years, some companies will have a significant amount of sensitive data relating to ex-employees. Thus, these ex-employees will have to be informed about their data and its use, too.

The GDPR also comes with something called “The Right to Be Forgotten.” In plain English, this amounts to the right to request that personal information be removed from a system. Thus, a former employee can request of a company that any personal data collected during their employment tenure be removed.

It gets worse. What happens if a company wants to run analytics on, say, benefits use? This will require company data on current and past employees. But the company may very well want to outsource these analytics to a third party. Passing the actual data to an analytics company would trigger a series of steps to stay in compliance with privacy laws—and never mind the hornet’s nest that data stirs up crossing international borders.

Best Practices for Data Privacy of Ex-Employees

So can an employee really come and demand that you erase their data? Yes and no.

The GDPR, for example, clearly states that there are circumstances where an employer can refuse to comply with a request to be forgotten—for example, where that data or its processing is required to be retained by law, or is needed for an ongoing legal case. So, if there is a clear law requiring data retention, this should be followed.

Things get trickier if the data is beyond the window where retention is required by law. For this reason, many companies are turning to automated solutions for destroying data records according to a pre-ordained schedule (such as our own Data Minimization, part of the Mage Data Minimization suite).

And for data that is within the retention window, care still needs to be taken. Take the analytics example given above. The transfer of data to third parties is a sensitive undertaking, and the risk of a data breach is much higher. Instead of transmitting sensitive data, it makes more sense to send masked data using a tool that preserves the relationships between data items. This allows third parties to provide useful analytics without having direct access to personal information.

Finally, it pays to do a regular audit of your data to discover where sensitive employee data lives. Chances are good that a significant amount of employee data “lives” in places that might be missed by routine records deletion. This can create a problem in terms of data privacy. By doing sensitive data discovery, an organization can “plug the holes” when it comes to data privacy laws, either deleting the information or masking it (if it is part of current business processes).

For more on how Mage can help strike a balance between data retention and data privacy, see:

 

Dynamic Data Masking with Mage

Sensitive Data Discovery with Mage

Data Minimization with Mage

3 things you might be doing wrong in your data protection program

BLOG LIBRARY >