GDPR and HR software - White paper

 
Designed to be of interest to small and medium sized companies, Jon Curtis analyses some of the issues that the General Data Protection Regulation (GDPR) brings for employers, HR Software companies and HR software users.

The GDPR have real teeth in the case of serious breach. Failure to comply may result in fines of up to EUR20 million or 4% of the organisation’s turnover (whoever is the higher) so it's worth taking seriously!

This report should be no substitute for legal advice – its purpose is to assist with your training and to highlight some of the key issues. With legislation as complex and meaty as the GDPR it is important to get specific legal advice on any questions you might have.

Some key terms

Before getting into the meat of the new Regulation, let is just remined ourselves of some the key terms – which actually have not changed very much under GDPR.

Data Protection Act 1998

Referred to as the DPA in this document.

Information Commissioner’s Office

Referred to here as the ICO, the Information Commissioner is the “data regulator.”

Personal Data

The GDPR, like the data Protection Act before it, defines personal data as any information related to a natural person (i.e. not a company (which is a legal person but not a natural person)) that can be used to directly or indirectly identify that person.
So, for example, “name” and “address” are clearly personal data. However, “holiday from and to dates” on their own are only personal data if they are connected with other identifying data (such as a name or unique job title).
HR software companies (and indeed any employer) can try to reduce the amount of personal data it holds on individuals by using a technique known as “pseudonymisation” which replaces obvious data from which people can be identified (such as “name”) and replaces them with “pseudonyms” which might be a unique number.
However, such data can still be personal data depending on how difficult it is to identify the individual from the data.

Special categories of data

Referred to as “sensitive personal data” under the Data Protection Act, this is a special class of personal data that covers specific areas deemed to require higher forms of consent – for example – details of illness, union membership etc. Under the DPA, criminal record data is “sensitive personal data”, but is dealt with separately under the GDPR.

Data controller

A controller is the entity that determines the purposes and means of processing personal data. In an HR cloud environment, the controller is the employer.

Data processor

A processor is responsible for processing data on behalf of a controller. When an employer uses HR software, the data processor is the software service provider.

Processing

This is very broadly defined as carrying out “any operation or set of operations” on the data. Almost any action – or even merely storage – is processing.

The data protection principles

Article 5 of GDPR requires that personal data shall be (much abbreviated) processed in accordance with the following six principles:
Processed lawfully, fairly and in a transparent manner;

The transparency aspect here is new compared to the DPA and rather important. Article 5.2 sets out the Accountability Principle which is that the data controller “must be able to demonstrate that personal data are processed in a transparent manner in relation to the data subject”. Merely doing it therefore is not good enough – you must be able to demonstrate it presumably with written policies setting out your approach in detail.

Collected for specified, explicit and legitimate purposes and not processed in a manner incompatible with those purposes;

This is largely the same commitment as currently, under the DPA

Adequate, relevant and limited to what is necessary;

The bar is higher now under the GDPR than previously. The DPA prohibited only processing that was excessive

Accurate and where necessary kept up to date, errors corrected quickly;

This is basically the same as the provision under the DPA

Kept for no longer than is necessary;

The detailed rules are slightly broader with some new exemptions, but for most employers the provision will be the same as under the DPA

Processed with adequate security.

This is basically the same as the provision under the DPA, but that does not mean that what was adequate security five year ago, is adequate now

The lawful basis for processing

Why “catch-all” consent clauses won’t wash under GDPR

For employers, this is probably the most important concept to grasp.

Under the DPA, employers (and many HR software companies) relied on consent to process employees’ data. It was an easy way to lawfully process data and was normally managed using a “catch all” data protection clause in the contract of employment.

The ICO has made clear for some time that they have felt that the catch-all basis for consent was not suitable for employers in any event because of the disparity in power between the employee and the employer.

Under the GDPR, the situation has now been clarified. Consent will rarely be a suitable lawful basis for processing. Some key related points:

• Consent can be withdrawn which would make employment impossible
• Any consent clause which hidden away in “standard terms” (including presumably contracts of employment) is unlawful under GDPR;
• Under the GDPR consent can be withdrawn at any time which makes it an unsuitable basis for processing;
• You will remember that the 2nd data protection principle states that data must be: “Collected for specified, explicit and legitimate purposes and not processed in a manner incompatible with those purposes.” Because of the variety of data that an employer may keep about employees, it is going to be all but impossible to rely on a “catch all” contractual provision.
• Furthermore, the GDPR ICO guidance clearly states: “…you won’t often need consent. If consent is difficult, look for a different lawful basis.”

This does not mean you will never use consent as a basis, you probably will, but for a specific purpose and not in a “catch-all” manner.
 

What is the correct basis for consent?

The GDPR (very similar to the DPA before it) Article 6 gives 6 lawful bases for processing data; and consent is only one possible option (again, the list is very paraphrased):

1. The data subject has given their clear consent for a specific purpose.
2. The processing is necessary for a contract with the data subject.
3. It is necessary for compliance with a legal obligation to which the data controller is subject (not including contractual obligations).
4. It is necessary to protect the vital interests (for example the life) of the data subject.
5. It is necessary for the performance of a task carried out in the public interest (public task) or for official functions
6. It is necessary for the purposes of legitimate interests pursued by the data controller or by a third party, except where these interests are overridden by the interests or the fundamental rights and freedoms of the data subject (taking into account the data subject’s reasonable expectations based on the relationship with the controller).

As can be seen from the above, there is lots of scope for processing employee data without consent. The key bases for private employers and HR companies will be numbers 2, 3 and 6.

You will note that the word “necessary” features quite highly in this list. The ICO’s Guide to the GDPR explains that saying the processing is “necessary” does not mean to say that it is “essential”. The ICO explains:

The guidance also makes clear that a party should not expect to use just one basis to cover all data points – so, for HR software providers and users it is important that data is broken down into categories and the relevant basis considered.

Consent should still be sought where it is appropriate and easy. However, an employer should be careful to explain which data is kept, and how it is processed. Clearly it is also important to make sure that the data collected is actually needed.

Check out this short paragraph found at page 12 of the ICO guidance:

It is possible that the warning explicit in this statement is not so much directed at employers as marketeers. However, a wise employer and certainly any HR Software company should ensure that a new GDPR privacy policy sets out a full list of data fields in writing, and provides that a lawful basis is allocated to each data field too. There seems to be no problem with allocating multiple bases, so that would seem a sensible thing to do.

However, be warned; the category you choose does have implications. As the ICO guidance points out:

1. The right to erasure does not apply to processing on the basis of legal obligation or public task 17(3)(b)
2. The right to portability only applies to processing on the basis of consent or contract;
3. The right to object only applies to processing on the basis of public task or legitimate interests.

As can be seen from above, “legal obligation” will likely become a favourite basis for employers as none of these rights apply. Employers clearly have legal obligations in respect of their employees which will cover much employee / employer data. For example: pay, holiday and working time, health and safety, and rules relating to discrimination to name but a few.
 

Legitimate interests

It is probably worth saying a few extra words about the “legitimate interests” basis as this is one of the more flexible bases. Firstly, there is a three-part test:

1. Is there a legitimate interest?
2. Is the processing necessary?
3. Do the individual’s interests override the legitimate interest?

The “legitimate interests” referred to can be yours, the employee’s or even a third party, as long as you pass the three-part test. They can even be trivial interests, but these would be more easily overridden by part three of the test.
You should not seek to rely on the legitimate interests basis if there is another reasonable way to achieve the same result.

The key element concerns “reasonable expectations”. Arguably, an employee will expect an employer to process information about performance (for example, appraisals) and there is clearly an interest in doing so. Finally, it is doubtful that the individual’s interests override the legitimate interest unless the appraisal is particularly intrusive.

If you rely on this basis, you must have some written evidence to prove you have properly considered the employees’ interests. The ICO guidance refers to this as a “legitimate interests assessment” which should be undertaken prior to the processing begins. The ICO guidance sets out a number of detailed factors to look at.

Note that the employee has the right to object to processing on the basis of legitimate interests (see below).
 

Special categories of personal data

This used to be called “sensitive personal data.” The GDPR set outs special rules about data concerning:

• Racial or ethnic origin.
• Political opinions.

Religious and philosophical beliefs.

• Trade union membership.
• Genetic data.
• Biometric data for the purpose of uniquely identifying a natural person.
• Data concerning health.
• Sex life and sexual orientation.

Such processing is only allowed where:

• The data subject has given explicit consent; or
• It is necessary for the purposes of carrying out the obligations and exercising specific rights of the controller or of the data subject in the field of employment and social security and social protection law, insofar as it is authorised by EU or member state law or a collective agreement pursuant to member state law providing for adequate safeguards for the fundamental rights and the interests of the data subject (Article 9(2)(b)).

Whilst we await the detail of the UK rules on this, it seems clear that the intention is that there is a carve-out intended to allow employers to process even sensitive personal data without needing express consent on each occasion.

Note that the processing of special category data is only lawful if you have both a lawful basis for processing and one of the special exemptions apply. So, for example, the process information concerning the dates of sickness absence the lawful basis might be “Lawful Obligation” (to process and pay SSP) and clearly such processing is necessary for the purpose of carrying out the obligations … of the controller … in the field of employment and social security law.
 

Criminal offence data

Criminal offence data is not special category data as set out above (however it was treated as sensitive personal data under the DPA, so that has changed). It has its own rules although it is dealt with in a similar way to the other special category data.
 

Individual rights

These rights apply to data controllers, not data processors, but data processors will have a required contractual obligation to assist where necessary.
 

The right to be informed

Employers will be well advised the set out detailed processing information in a written privacy statement to employees. The need for a comprehensive policy has already been noted. The GDPR sets out a lot of information that employers must provide to their employees concerning the data that is processed about them. The list is fairly comprehensive. Note that if an employer has data about employees on third party applications the employer (and the application provider) have the responsibility to be open about what is processed there. Normally this would be covered by the third party’s own privacy policy. It is therefore important to check that any data processor’s you retain have informed your employees / you (as appropriate) in the required detail.

In setting out a new GDPR privacy policy you could set out your employee data in a table as follows:

The right of access

The right of access is broadly similar to the Subject Access Request under the DPA, with some small changes:

• the former fee required under the DPA has been dropped unless:
  • the request is “manifestly unfounded or excessive” in which case controllers can refuse to comply or charge a fee; and
  • further copies are requested.
• People can make requests by email.
• The controller must inform the individual what information is held about them and what processing is being carried out.
• the data controller must now respond within a month (unless request is complex in which case an extension of two months can be agreed).

The right to rectification

Individuals can have their data rectified if it is incomplete or inaccurate by request and such requests should be dealt with within one month.
 

The right to erasure

Also known as the right to be forgotten, the Regulation set out various circumstances which the right applies – for example when the individual withdraws consent.
The GDPR also sets out the circumstances in which a request for erasure does not need to be complied with, for example: to comply with a legal obligation or the exercise or defence of legal claims.
 

The right to restrict processing

Under certain circumstances an employer or HR software company is required to restrict the processing of personal data, for example:

• If someone contests the accuracy of data, no processing should be undertaken until the data is checked
• If an individual has exercised the right to object (see below) and you are considering your legitimate grounds versus the rights of the employee.

The right to data portability

The right to data portability only applies:

• To personal data an individual has provided to a controller;
• Where the processing is based on the individual’s consent or for the performance of a contract; and
• When processing is carried out by automated means.

Data must be provided in a commonly used format, for example CSV and it must be provided free of charge. There is no necessity to provide systems that are compatible with other organisations.
 

The right to object

Individuals have the right to object to processing based on legitimate interests (and other grounds too, beyond the scope of this paper).

In such circumstances, the processing must cease unless the employer can demonstrate compelling legitimate grounds for the processing which overrides the interests of the individual or, the processing is for the establishment, exercise or defence of legal claims.

Individuals must be informed of their right to object in writing, and this will normally take place in the privacy statement.
 

Rights related to automated decision making

Automated decision making is where a decision is made solely using automated means without any human involvement. For example, if a pay calculation is made using a coded script of some kind, this is an automated decision-making process.

Profiling is where personal data is automatically processed to evaluate certain things about an individual. For example, a program may use demographic data, appraisal scores and salary information to identify high or low achievers.

You can only carry out automated decision making and profiling where the decision is:

• Necessary for the entry into or performance of a contract;
• Authorised by law applicable to the controller (normally local law)
• Based on the individual’s explicit consent.

You must:

• Give individuals information about the processing
• Allow requests for human intervention
• Carry out regular checks to make sure the systems are working.

Accountability and governance

The accountability principle at article 5(2) of GDPR means that you must demonstrate that you comply with the principles and states explicitly that this is your responsibility.
The ICO guidance sets out a list of actions which would evidence compliance including:

• Appropriate technical and organisational measures
• A data protection officer
• Data minimisation
• Pseudonymisation (see above)
• Transparency
• Security reviews

Controllers and processors

 
This is an area where the GDPR will have a big impact on software providers.

Under the GDPR, as with the DPA, employers will normally be “data controllers” and normally, HR software providers will “just” be data processors.

However, the rules concerning data processors are enhanced as are the consequences for breaches. As a data processor, the GDPR requires specific record keeping, certain contractual terms between you and your client, and there are also significantly increased fines for data breaches, as well as a requirement to “self-report” under certain circumstances.

Note also that the GDPR applies even if your HR software provider is situated outside the EU.

If you use a third party HR software application you need to ensure that you have in place contractual terms and conditions which comply with the GPDR – your provider should sort that, and if they do not, you need to be very wary. The HR software company should also have a GDPR compliant data protection policy, and some sort of data protection lead or ideally a Data Protection Officer.

You should also be asking which sub-processors your provider works with and ensure that you agree with those choices.

Your provider should also commit to assisting you with any of the individual employee rights – for example the right to access and for rectification described above (although often these will be in your own hands).

You will want to ensure that all of your data is properly deleted once your contract with the HR software company is concluded.

Finally, of course, you will want to ensure that the HR software company has given a commitment to ensuring that the data they hold on your behalf is held securely.