Consent: Getting it right!

March 2021

Are you suffering from consent confusion? When must we rely on it? When is it not a good idea? And what must we do to make sure our consent is valid?

Here’s a short refresher to dispel the myths and a quick ‘consent checklist’ to make sure you are ticking all the right boxes!

For starters, one of the biggest myths surrounding GDPR (fuelled by news stories back in 2018) is that we need consent do almost anything with people’s personal data.

Simply not true.

Consent is one lawful basis, there are others

Consent is just one of six lawful basis. They are all equal, no one basis is better than another and you need to pick the right one for what you are doing.

Yes, sometimes consent is required by law for certain activities, but for many others a different lawful basis may be more appropriate.

But you do need to pick one. Data protection law across the EU and UK requires us have a lawful basis for processing personal data.

(By processing we mean doing anything with people’s personal information – from collecting, storing, sharing and even the action of deleting it).

GDPR raised the bar on what constitutes valid consent

GDPR defines consent and says it must be, “freely given, specific, informed and unambiguous” and  must be given by a “clear affirmative action by the data subject”.

This means you need to clearly tell people what they are consenting to and they need to take an action to give their consent. And consent shouldn’t be bundled up with providing another service or with T&Cs.

Just to be clear, the rules for consent under UK GDPR as the same as for EU GDPR. (See UK data protection and ePrivacy law post-Brexit).

When is consent the right lawful basis?

Consent is most appropriate to use when you can offer people a clear choice and give them control over how you use their data. If you can’t do this, you should look to rely on another lawful basis.

When is consent legally required?

There are some circumstances when the law tells us we must gain consent. Let’s take a look…

1. Marketing

In specific situations you need consent to send marketing emails or SMS messages under the UK’s Privacy and Electronic Communications Regulations (PECR).

This is where things can get a bit nuanced. Consent is not always legally required for all marketing emails/SMS. There are choices you can make.

For example, there’s a specific exemption for existing customers (known as the ‘soft opt-in’) and more relaxed rules for business-to-business marketing. For more detail see Understanding email marketing rules.

There are also circumstances in which you will need consent for telemarketing calls. See the ICO’s Guide to PECR.

2. Cookies

You need consent to place cookies or other online tracking methods on people’s devices (unless those cookies are ‘strictly necessary’). Or to install apps or software on people’s devices.

The ICO has confirmed such consent needs to meet the UK GDPR standard, and that cookies used for analytics, performance or marketing are NOT strictly necessary. See the ICO’s cookie guidance.

3. Special category data

If you are intending to handle special category data, for example health data on individuals, you may need to seek explicit consent to make sure this is lawful. This is unless you can rely on another specific legal condition.

GDPR requires you to have a lawful basis for processing special category data PLUS a specific condition under Article 9.

Special category data is information relating to someone’s health, race, ethnicity, political opinions, religious beliefs, trade union membership, sex life, sexual orientation and covers genetic and biometric data.

A word of caution here, if you’re using special category data for direct marketing or profiling purposes, you’ll need explicit consent.

4. If no other lawful basis applies

As you must have a lawful basis for each processing activity you undertake, if no other lawful basis obviously applies, you will need to obtain consent. Here are a couple of examples:

  • If someone would not expect you to be sharing their data with another organisation, it’s likely you would need to collect their consent to do so.
  • If you are planning to use someone’s data for a completely different purpose, which you didn’t tell them about when you collected their data, you are highly likely to need to collect their consent unless another lawful basis applies (e.g. its needed to meet a legal obligation).

Consent checklist

Consent checklist

You also need to consider other factors, such as if you are requesting consent for another organisation it must be separate and they should be named. Also consent doesn’t last for ever and should be refreshed (especially if anything changes).

If you offer online services which are likely to be accessed by children, you also need to consider whether you will need to seek parental consent and/or implement age verification measures. (Also see Children’s Code – deadline for conforming looms)

When is consent not a good option?

Consent will clearly not be the best approach if you will struggle to meet the requirements.

You should be careful about using consent where there’s likely to be an imbalance of power. In other words, where people might feel they have to give their consent.

This makes consent tricky if used by a business for purposes relating to their employees. Perhaps staff may feel a degree of pressure to give their consent, or feel they will be penalised in some way or treated differently if they refuse.

Saying this, sometimes there seems little option but to rely on an employee’s consent. I know a number of organisations using explicit consent for their diversity monitoring, which clearly entails special category data.

Consent isn’t easy

Collecting valid consent and meeting all the requirements may feel like a bit of a minefield. It does mean you need to take careful decisions. It’s worth double checking what risks may be lurking.

However, it is worth getting right, in the words of the ICO, “Genuine consent should put individuals in charge, build trust and engagement, and enhance your reputation.”

A final word of caution; be careful not to try and shoe-horn your activities into another lawful basis (such as legitimate interests), when consent really would be the most appropriate approach.

Getting your Supplier Contracts Right

A Guide to Controller-Processor contracts 

The GDPR sets out strict requirements for when an organisation decides to utilise the services of another company to process personal data. The most important aspect to establish first is whether you are both acting as controllers of the personal data being processed or whether the service provider is purely acting as a processor, acting at all times under instruction of the controller.

What is a controller?

A controller is person, or more commonly an organisation, which controls the ‘means and purposes of processing’. The controller makes the decisions about how this personal data is collected, used, stored, transferred, kept secure, destroyed etc. and among other matters is responsible for fulfilling individual rights requests, such as Subject Access Requests.

What is a processor?

To be recognised as a processor, a person or organisation, must processes personal data on behalf of a controller and not use this data for their own purposes. For example, a processor may be an external company utilised to provide payroll, printing, marketing or website services.

However, if an organisation determines the ‘means and purposes of processing’, i.e. uses the personal data for their own purposes, they become a controller. For example, if a marketing service provider uses the personal data it’s provided for its own internal analysis/profiling (which is not solely produced for the controller) it’s likely to be considered a controller for this activity.

It is worth noting that processors may be those who are offering hosted or cloud based services, which although not EU located are clearly caught by GDPR.

Establishing the relationship

It has proved very challenging for many organisations to clearly establish whether companies are acting as processors or controllers, with some organisations insisting they are a processor when actually they may be a controller. However, it is crucial for this to be established if you wish to ensure these relationships are compliant.

Where controllers are sharing personal data with another controller, this may under a joint-controller relationship or as separate autonomous controllers. In both circumstances, controllers have a duty to meet their data protection obligations as controllers. Therefore if they that act as joint controllers, they will have shared obligations.

What GDPR changed for Controller-Processor relationships

Prior to the GDPR, the accountability for compliance rested almost entirely with the controller, who was liable if things went wrong. Now, under the GDPR, the controller and processor could both be held accountable for compliance with the Regulation, and for compensating any damage (material or non-material) suffered by EU data subjects.

A controller or processor would only be exempted shall if they can prove they are ‘not in any way responsible’. And if the controller goes out of business, the processor carries the full burden.

Processors also have their own accountabilities, such as being responsible for their sub-processors, data transfers, staff training, fulfilling record of processing requirements (where necessary) and assisting the controller.

What does GDPR require for Controller-Processor agreements?

Article 28 sets out specific requirements for when a Controller utilises the services of a processor. Just to reiterate, Article 28 applies when the supplier/vendor is:

  • processing personal data on behalf of the controller (i.e. processing the controller’s own data)
    and
  • under the instruction of the Controller
    and
  • NOT using the controller’s personal data for its own purposes.

The law makes it very clear that this arrangement must be covered by a binding agreement (i.e. a live contract) and there are specific provisions that must be included in this agreement in order to comply with GDPR Article 28. Prior to GDPR written contracts were required, but GDPR requires more specific detail.

Core GDPR Contractual Requirements

1. Technical and Organisational Measures (TOMs)

The Controller must only use processors who have provided sufficient guarantees to implement appropriate technical and organisational measures to meet the requirements of GDPR and ensure the protection of data subjects’ rights.

It is therefore strongly advisable that organisations, as part of their due diligence process, conduct an information security impact assessment of any potential new processor and to document the outcomes. The aim of this is to provide assurance to the controller that personal data will be properly protected both in transit and when at rest in the processors’ systems. It is advisable to include reference to necessary security measures implemented by the processor in any contract, which may include for instance any requirement for encryption, access controls, and so on.

Controllers should also look for assurance by the processor on aspects such as adequate training of the staff handling their personal data and that access to data is restricted to those that require it to provide the service.

2. Appointment of sub-processors

The processor must not engage another processor (often referred to as ‘sub-processor’) to conduct processing of the controller’s personal data without the specific or general written authorisation of the controller.

Furthermore, the processor needs to inform the controller of any intended material changes concerning additional/replacement sub processors as the controller must be given the opportunity to object to such changes.

A contract should therefore provide details of any sub-processors which will be used to handle the controller’s data. Updates should be provided when this list changes.

Under the law processors need to be aware they are accountable and liable for the actions of their sub-processors. Article 28(4) specifically states that the same obligations as set out in the contract between the controller and processor shall be imposed on another processor by way of contract (or other legal act).

Where a sub-processor fails to fulfil its data protection obligations, the initial processor will be fully liable to the controller for the performance of the sub-processor’s obligations. Processors are therefore responsible to conducting due diligence of any sub-processors they use.

3. Further contractual requirements

A contract (or other legal act) between a controller and processor must set out the following:

  • Types of personal data the processor will be processing on behalf of the controller (e.g. name, email address, telephone number, bank account number, date of birth – including any special category data)
  • Categories of data subject (e.g. employees, patients, customers, students, minors)
  • Nature and purpose of processing
  • Duration of processing (i.e. the term of the contract)
  • Obligations and rights of the controller

Article 28 continues to provide other specific details that must be covered in a contract.

a) Rights and duties of each party (e.g. the processors commitment not to use the controller’s personal data for any other purpose than for providing the agreed service).

b) Instructions from the controller – The agreement should include details of what the processor is permitted to do with the personal data it is provided. In practice, this may often be set out by the supplier (processor), but the controller should check and agree that these accurately represent their instructions.

c) International transfers – If relevant, the agreement should include details and provisions for any transfer of personal data to a third country (i.e. outside the EEA) whether this be to the processor itself or any sub-processors used. Post-Brexit this will become a key aspect of contracts as the UK itself would become a third country.

d) Duty of confidentiality – There must be a confidentiality clause which commits the processor to ensuring that people who are authorised to access the controller’s personal data have committed themselves to a duty of confidentiality or are under a statutory obligation of confidentiality.

e) Data subject’s rights – the processor must commit to assist the controller, where applicable, with the fulfilment of data subject’s rights, such as Subject Access Request, the right to erasure, the right to object to processing, etc.

f) Assistance with controller’s compliance – the agreement should set out that, as and when required, the processor will assist the controller with:

i. Security of processing
ii. Notification of any Data breaches
iii. Conducting a Data Protection Impact Assessments (DPIA), should this be required

g) Return or destruction of the data – the agreement should stipulate what happens to the controller’s personal data at the end of the term of the contract. The law states that at the choice of the controller all personal data must be returned or destroyed. If the controller’s choice is for the data to be destroyed, it would be advisable to ensure that a contract stipulates that a data destruction certificate will be provided.

h) Audits and inspections – the agreement should set out that the processor agrees to make available all information necessary to demonstrate compliance with Article 28 and will allow for, and contribute towards audits, including inspections, by the controller or an authorised auditor.

What might be the consequences of getting data contracts wrong?

It’s crucial that contracts relating to data processing include all the appropriate terms to make sure that individuals are properly protected and also that the accountabilities and liabilities of each party are clearly agreed should a data breach or other infringement of data protection law occur.

As GDPR states:

‘Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered.

Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller.’ (Article 82)

It’s worth noting that a Ponemon Institute study revealed that 56% of companies experienced a 3rd-party breach in 2017, which represented an increase of 7% compared to previous year. In the event of a supplier suffering a breach, contractual arrangements are likely to come under scrutiny.