Top 10 Data Protection Tips for SMEs

January 2023

Is it onerous for SMEs to become compliant?

One of the stated aims of the UK Government’s Data Protection and Digital Information Bill is to support small businesses and remove unnecessary bureaucracy. 

As context, there are 5.6m businesses in UK of which SMEs (less than 250 employees) represents 99% of the total. According to IAPP research approximately 32,000 organisations in UK have a registered DPO. It’s right, therefore, to focus on SMEs. 

But how onerous is small business data protection now? Arguably, the answer is, not as onerous as you might think. We’ve created a top 10 checklist for start-ups and small businesses to help you decide what you should be concerned with: 

1.     Do I need to worry about data protection regulation? 

Yes. Pretty much any business processing personal data for commercial purposes need to worry about data protection. (It does not apply to purely ‘personal or household activity’). Having said that, the law and regulatory advice focuses on taking a ‘proportionate’ approach. There’s no one size fits all and it will depend on the risk appetite of your organisation. 

2.     Do I need a DPO?

Probably not. If the answer to these three questions is no, you don’t need a DPO…

  • Are you a public authority or body?
  • Do your core business activities require regular and systematic monitoring of individuals on a large scale?
  • Do your core business activities involve processing on a large scale ‘special category data’, or criminal convictions or offences data?

Even if you don’t need a DPO, it’s wise to nominate someone in your organisation as a data protection lead. This does not need to be a full-time role. Alternatively, you can outsource this activity to someone/a company who can provide the support on a part-time basis. 

3.     Do I need a RoPA (Record of Processing Activity)

Maybe. There’s no escaping the fact RoPAs are challenging documents to complete and can absorb a huge amount of time. Companies with more than 250 employees must always keep a RoPA – that’s just under 8,000 businesses in UK.

If you have less than 250 employees, you don’t need a RoPA if the following applies:

  • Processing does not pose a risk to the rights and freedoms of the data subject 
  • No special category data is being processed
  • If the processing is only done occasionally

The debate start when you consider what constitutes a ‘risk to the rights and freedom of the data subject’. It’s worth considering the type of data you handle rather than the volumes to help you decide whether to complete a RoPA. As a start up, you may not need a RoPA as defined in the legislation. However, having a record of what information is processed, for what purpose and under what lawful basis is a good idea even if the ICO RoPA form is not. 

There are changes afoot with regards to the RoPA under UK data reform plans, but a record of your activities may still be necessary, just not as current prescribed.

4.     Do I need to register with ICO?

Almost certainly YES. The ICO asks all businesses that process personal data to pay the Data Protection Fee. This is used to fund the ICO and its activities. This isn’t onerous. In fact, most small businesses will only have to pay £40 (or £35 with a direct debit). And that’s before you’ve considered whether you’re exempt. Not for profit status is a possible example. 

 5.     Do I need a privacy notice (policy)?

Yes. A privacy notice is a foundational piece of your data protection work. Any organisation which processes personal data needs to set out what data they are processing and how they are processing it as well as the data subject’s rights. The ICO’s checklist provides very clear guidance for what must be in a notice and what might be in a notice.

6.     How about a cookie notice?

Yes again. If you have a website, assume you need a cookie notice. Even if all you’re doing is using cookies to manage the performance of your website, a cookie notice is required. This does not need to cost money. You can get free software from the major privacy software providers. They have simple step by step set up guides. There is really no excuse not to have a cookie notice. 

7.     What about accountability?

Yes, but make it proportionate. In a nutshell, accountability means ‘evidencing your activities’. Keep a record of what you do, why you’re doing it and your decision-making. It also means making sure you have appropriate technical and organisational measures in place to protect personal data. Have staff been adequately trained in data protection? Do we have clear guidelines and/or policies to help them? 

8.     What about Individual Rights? 

Yes. Every individual has clear rights and irrespective of the size of the organisation you need to fulfil these requests. 

These rights include right of access, the right to rectification, the right to erasure, the right to restrict processing, the right to data portability, the right to object and the right not to be subject to a decision based solely on automated processing.

Not all of these might apply to a small business but it’s important to decide how to recognise and respond to these requests from individuals. 

9.    Don’t forget information security

Yes. Cyber Essentials was designed for SMEs. Arguably it’s the absolute minimum for any business. It does cost money but not a lot. Gaining the Cyber Essentials certification (if self-certified) costs £300. The five technical controls are: 

  • Boundary firewalls and internet gateways
  • Secure configuration.
  • Access control.
  • Malware protection.
  • Patch management.

10.  What about International Data Transfers? 

Hopefully no! If you and your suppliers are only operating in UK and Europe stop reading now. However, if any data is exported to a third country (such as USA, South Africa or India), there’s no escaping the fact that international data transfers can be painful to work through. 

When EU-US Privacy Shield was invalidated in 2020 this caused significant problems for data transfers between US and EU/UK. At the time, Max Schrems’ advice was to only work with companies based in UK or Europe who are not exporting data to third countries. However, this isn’t always possible – just consider how many people use Google, Microsoft or Mailchimp. 

Many, if not most, businesses will have dealings with these three and the reality is that you must accept they’re not going to change anything for you, or choose not to use them. 

Conclusion

Many small and start-up businesses can get ready relatively quickly. The trick for small business data protection is to review your arrangements on a regular basis and be aware if any more complicated processing emerges. For instance, anything involving automated processing, special category data, AI or children’s data carries significant risk and should be treated with care. 

There’s more helpful information available on the ICO’s Small Business Hub.

Julia is an experienced data protection consultant and has been advising businesses since 2016. She regularly delivers GDPR training as well as developing bespoke GDPR guidance for our clients.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Data Protection Basics: The 6 lawful bases

November 2022

A quick guide to the six lawful bases for processing personal data

One of the fundamental data protection principles is that our handling of personal data must be ‘lawful, fair and transparent’. To be lawful, clearly, we shouldn’t do anything illegal in general terms. But what else does it mean to be lawful?

We’re given six lawful bases to choose from under UK/EU GDPR. For each purpose we use personal data for, we need to match it with an appropriate lawful basis.

For example a purpose might be:

  • Sending marketing emails to our customers
  • Profiling our audience to better target our marketing
  • Handing staff payroll data to pay salaries
  • Handling customer enquiries about our services
  • Delivering a product a customer has requested
  • Implementing measures to prevent fraud

We need to select the most appropriate lawful basis and meet its own specific requirements. Each basis is equally valid, but one may be more appropriate than others for any specific task. We’re legally obliged to set out the lawful bases we rely on in our privacy notices.

If none of them seem to work, you may want to question whether you should be doing what you’re planning to do.

Quick guide to the 6 lawful bases

(This is not intended to be exhaustive, do check the ICO’s Lawful Basis Guidance)

1. Contract

This lawful basis will be appropriate if you need to process an individual’s personal information to deliver a service to them. Or you need collect certain details to take necessary steps before entering into a contract or agreement.

Example 1: An individual purchases a product from you and you need to handle specific personal information about them in order to deliver that product, including when you acknowledge their order, provide essential information, and so on.

Example 2: Someone asks you to give them a quote for your services, and you need certain information about them in order to provide that quote.

Contract tips:

  • It doesn’t apply to other purposes you may use the data for which are not essential.
  • It’s most likely to be used when people are agreeing to T&Cs, although it can also be used where a verbal agreement or request for information is made.
  • The person whose data you’re processing must be party to the contract or agreement with you. It doesn’t apply if you want to process someone’s details, but the contract is with someone else, or with another business.

2. Legal obligation

There may be circumstances where you are legally obliged to conduct certain activities, which will involve processing personal data. This could be to comply with common law or to undertake a statutory obligation.

Example 1: You are offering a job to someone outside the EU. You need to check they have a visa to work in the UK, as this is a legal obligation.

Example 2: Airlines and tour operator collect and process Advance Passenger Information (API) as this is a legal requirement for international air travel.

Legal obligation tips

  • Legal obligation shouldn’t be confused with contractual obligations
  • Document your decision. You should be able to either:
    a) identify the specific legal provision you are relying on
    or
    b) the source of advice/guidance which sets out your obligation.

3. Vital interests

You can collect, use or share personal data in emergency situations, to protect someone’s life.

Example: A colleague collapses at work, is unable to talk, and you need to tell a paramedic they have a medical condition. Common sense should prevail.

Vital interest tips

  • It’s very limited in scope, and should generally only apply in life and death situations.
  • It should only be used when you manifestly can’t rely on another basis. For example, if you could seek consent, you can’t rely on vital interests.

4. Public task

You can process personal data if necessary for public functions and powers that are set out in law, or to perform a specific task in the public interest.

Most often this basis will be relied upon by public authorities and bodies, but it can apply in the private sector where organisations exercise official authority, or carry out tasks in the public interest.

Public task tips

  • If you could reasonably perform your tasks or exercise powers in a less intrusive way this basis won’t be appropriate. The processing must be necessary.
  • Document your decisions, specify the task, function or power, and identify the statutory or common law basis.

5. Legitimate Interests

This is the most flexible lawful basis, but don’t just assume what you’re doing is legit. It’s most likely to be appropriate when you use people’s data in a way they’d reasonably expect. Where there is minimal impact on them, or where you have a compelling justification.

Legitimate interests must be balanced. You must balance the organisation’s interests against the interests, rights and freedoms of individuals. If your activities are beyond people’s reasonable expectations or would cause unjustified harm, their rights and interests are likely to override yours. Legitimate interests – when it isn’t legit

Legitimate Interests tips

  • Conduct and document a Legitimate Interests Assessment (LIA). This may be relatively simple and straight-forward, or more complex.
  • Consider whether you can provide people with an easy way to object. This is not essential in all situations (e.g. fraud protection).
  • Be open about where you rely on legitimate interests so its likely to be in people’s reasonable expectations.
  • Remember to include what your legitimate interests are in your privacy notice.
  • Check the ICO’s guidance on when legitimate interests can be relied upon for marketing activities.

6. Consent

This is when you choose to give individuals a clear choice to use their personal details for a specific purpose and they give their clear consent for you to go ahead. The law tells us consent must be a ‘freely given, specific, informed and unambiguous’ indication of someone’s wishes given by a ‘clear affirmative action’.

Consent is all about giving people a genuine choice and putting them in control. They must be able to withdraw their consent at any time, without a detrimental impact on them.  Consent, getting it right.

Consent tips:

  • It should be clear what people are consenting to
  • Consent shouldn’t be bundled together for different purposes, each purpose should be distinct
  • It must not be conditional – people shouldn’t be ‘forced’ to consent to an activity as part of signing up to a service.
  • Consent is unlikely to be appropriate where there may be an imbalance of power. For example, if an employee would feel they have no option but to give consent to their employer (or might feel they could be penalised for not giving it).
  • The law sometimes requires consent. For example, under the electronic marketing rules consent is sometimes a requirement.

In summary, consider all the purposes you have for processing personal data. Assign a lawful basis to each purpose and check you’re meeting the specific requirements for each basis. Tell people in your privacy notice the lawful bases you rely on, and specifically explain your legitimate interests.

Finally, don’t forget, if you’re processing special category data (for example data revealing racial or ethnic origin, health data or biometric data) you’ll need a lawful basis, plus you’ll need to meet one of the conditions under UK GDPR Article 9.  For criminal convictions data you’ll need a lawful basis, plus one of the conditions under UK GDPR Article 10.

As a data protection consultant since 2015, Philippa advises a broad range of clients and delivers data protection training. She regularly writes GDPR guidance to support privacy teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Data Protection Basics: The 7 data protection principles

November 2022

Understanding the key principles of data protection

Let’s get back to basics. There are seven core principles which form the foundation of data protection law. Understanding and applying these principles is the cornerstone for good practice and key to complying with UK / EU GDPR.

Here’s our quick guide to the data protection principles.

1. Lawfulness, fairness and transparency

This principle covers 3 key areas.

a) Lawfulness – We must identify an appropriate ‘lawful basis’ for collecting and using personal data. In fact, we need to decide on a lawful basis for each task we use personal data for, and make sure we fulfil the specific conditions for that lawful basis. There are 6 lawful bases to choose from.

We need to take special care and look to meet additional requirements when using what’s termed ‘special category’ data or data which relates to minors or vulnerable people.

We should also be sure not do anything which is likely to contravene any other laws.

b) Fairness – We must only use people’s data only in ways that are fair. Don’t process data in a way which might be unexpected, discriminatory or misleading. This means evaluating any adverse affects on individuals.

c) Transparency – We must be clear, open and honest with people about how we use their personal information. Tell people what we’re going to do with their personal information. Routinely this is achieved by providing relevant privacy information at the point data is collected, and by publishing a complete and up to date privacy notice and making this easy to find. Transparency requirements apply right from the start, when we collect or receive people’s data.

2. Purpose limitation

This is all about only using personal details in the ways we told people they’d be used for. We must be clear about what our purposes for processing are and specify them in the privacy information we provide to individuals.

Sometimes we might want to use personal data for a new purpose. We may have a clear legal obligation to do it, but if not we should check the new purpose is compatible with the original purpose(s) we had for that data. If not, then we may need to secure the individual’s consent before going ahead.

Remember, if we surprise people, they ‘ll be more likely to complain.

3. Data minimisation

We must make sure the personal data we collect and use is:

  • Adequate – necessary for our stated purposes. Only collect the data we really need. Don’t collect and keep certain personal information ‘just in case’ it might be useful in future.
  • Relevant – relevant to that purpose; and
  • Limited to what is necessary – don’t use more data than we need for each specific purpose.

4. Accuracy

We should take ‘all reasonable steps’ to make sure the personal data we gather and hold is accurate, up-to-date and not misleading.

It’s good practice to use data validation tools when data is captured or re-used. For example, validate email addresses are in the right format, or verify postal addresses when these are captured online.

If we identify any of the personal information we hold is incorrect or misleading, we should take steps to correct or delete it promptly.

Data accuracy can decline over time. For example, people change their email address, move house, get married or divorced, their needs and interests change. And of course some people on your database may pass away. So we need to consider ways to keep our data updated and cleansed.

Perhaps find ways to give people the opportunity to check and update their personal details?

5. Storage limitation

Don’t be a hoarder! We must not keep personal data longer than necessary for the purposes we have specified.

Certain records need to be kept for a statutory length of time, such as employment data. But not all data processing has a statutory period. Where the retention period is not set by law, the organisation must set an appropriate data retention period for each purpose, which it can justify.

The ICO would expect us to have a data retention policy in place, with a schedule which states the standard retention period for each processing task. This is key step to making sure you can comply with this principle.

When the data is no longer necessary, we must destroy or anonymise it, unless there’s a compelling reason for us to keep it for longer. For example, when legal hold applies. For more information see our Data Retention Guidance.

6. Security

This is the ‘integrity and confidentiality’ principle of the GDPR – often known as the security principle. This requires organisations to make sure we have appropriate security measures in place to protect the personal data we hold.

UK / EU GDPR talks about ‘appropriate technical and organisational measures’ (known as TOMs). These includes things like physical and technical security measures, conducting information security risk analyses, having information security policies & standards in place to guide our staff.

Our approach to security should be proportionate to the risks involves. The ICO advises us to consider available technology and the costs of implementation when deciding what measures to take.

Some of the basics include transferring data securely, storing it securely, restricting access to only those who need it and authenticating approved data users.

Cyber Essentials or Cyber Plus can be helpful as an assurance framework to carry out a review of your data security arrangements.

Controllers should consider information security standards when appointing and managing relationships with processors, i.e. service providers handling personal data on your behalf to provide their services. Are your processors securely handling their processing of the data you control? Carry out appropriate due diligence to make sure.

7. Accountability

The accountability principle makes organisations responsible for complying with the UK / EU GDPR and says they must be able to evidence how they comply with the above principles.

This requires data governance across the organisation. Think of accountability as a collective responsibility, flowing from the Executive team and down through to the teams that process personal data.

To demonstrate how we comply, we need to have records in place. For many organisations this will include a Record of Processing Activities (RoPA).

The ICO provides a useful ‘Accountability Framework’ we can use to benchmark performance against their expectations.

In summary, identify the lawful bases you’re relying on and be fair and be open about what you do. Minimise the data you collect and make sure it remains accurate over time. Always keep it secure and don’t keep it for longer than you need it. Take care if you want to use personal data for a new purpose. Keep records and be ready to justify your approach.  The ICO has published more detailed guidance on the seven principles.

After a successful career in publishing Simon moved into data protection consultancy in 2015. Simon advises businesses of all sizes across a wide range of sectors. He held the role of Director of Information Governance at Royal Mail Group in the run up to GDPR enforcement. He regularly delivers data protection courses for clients and the Institute of Data & Marketing (IDM).

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Controller or processor? What are we?

November 2022

Are you a service provider acting as a processor? Or a controller engaging a service provider? Is the relationship clear?

There are a few regulatory cases which remind us why it’s important to establish whether we’re acting as a controller or a processor, and to clearly define the relationship in contractual terms.

On paper the definitions may seem straight-forward, but deciding whether you’re acting as a controller, joint-controller or processor can be a contentious area.

Two regulator rulings to note

  • The ICO has taken action against a company providing email data, cleansing and marketing services. In the enforcement notice, it’s made clear the marketing company had classified itself as a processor. The ICO disagreed.
  • The Spanish data protection authority (AEPD) has ruled a global courier service was acting as a controller for the deliveries it was making. Why? Largely due to insufficient contractual arrangements setting out the relationship and the nature of the processing.

Many a debate has been had between DPOs, lawyers and other privacy professionals when trying to classify the relationship between different parties.

It’s not unusual for it to be automatically assumed all suppliers providing a service are acting as processors, but this isn’t always the case. Sometimes joint controllership, or separate distinct controllers, is more appropriate.

Organisations more often than not act as both, acting as controller and processor for specific processing tasks. Few companies will solely be a processor, for example, most will be a controller for at least their own employment data, and often for their own marketing activities too.

What the law says about controllers and processors

The GDPR tells us a controller means ‘the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data’.

A processor means ‘a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller’.

How to decide which we are

There are some key questions to ask which will help organisations reach a conclusion.

  • Do we decide how and what personal data is collected?
  • Are we responsible for deciding the purposes for which the personal data is processed?
  • Do we use personal data received from a third party for our own business purposes?
  • Do we decide the lawful basis for the processing tasks we are carrying out?
  • Are we responsible for making sure people are informed about the processing? (Is it our privacy notice people should see?)
  • Are we responsible for handling individual privacy rights, such as data subject access requests?
  • Is it us who’ll notify the regulator and/or affected individuals in the event of a significant data breach?

If you’re answering ‘yes’, to some or all of these questions, it’s highly likely you’re a controller.

And the ICO makes it clear it doesn’t matter if a contract describes you as a processor; “organisations that determine the purposes and means of processing will be controllers regardless of how they are described in any contract about processing services”.

Controller or processor? why it’s important to confirm your status

Controllers have a higher level of accountability to comply with all data protection principles, and are also responsible for the compliance of their processors.

If you are a processor, you must only handle the controller’s data under their instructions.

This means if you’re doing anything else with this data, for your own purposes, you can’t be a processor for those purposes. You will be acting as a controller when the processing is for your own purposes.

Let’s be clear though, this doesn’t mean a processor can’t make some technical decisions about how personal data is processed.
Data protection law does not prevent processors providing added value services for their clients. But as a processor you must always process data in accordance with the controller’s instructions.

Processors also have a number of direct obligations under UK GDPR – such as the technical and organisation measures it uses to protect personal data. A processor is responsible for ensuring the compliance of any sub-processors it may use to fulfil their services to a controller.

Controller-Processor data processing agreements

If the relationship is controller to processor, you must make sure you have a suitable agreement in place. The specific requirements for what must be included in contractual terms between a controller and processor are set out in Article 28 of EU / UK GDPR.

Often overlooked is the need to have clear documented instructions from the controller. These instructions are often provided as an annex to the main contract (or master services agreement), so they can be updated if the processing changes.

There will be times where you’re looking to engage the services of a household name, a well-known and well-used processor. There may be limited or no flexibility to negotiate contractual terms. In such cases, it pays to check the terms and, if necessary, take a risk-based view on whether you wish to proceed.

What’s clear from the Spanish courier case is how important it is to have contracts in place defining the relationship. The ICO ruling demonstrates even if your contract says you’re a processor, if you are in fact in control of the processing, this will be overturned, and you’d be expected to meet your obligations as a controller.

As a data protection consultant since 2015, Philippa advises a broad range of clients and delivers data protection training. She regularly writes GDPR guidance to support privacy teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Privacy Management Programme – what does one look like?

October 2021

The concept is nothing new, but the term Privacy Management Programme (PMP) has been flung into the spotlight by the UK Government’s plans to reform data laws.

In a nutshell, the Government plans to revise the current accountability framework, replacing existing obligations (some of which are mandatory) with a requirement to implement a PMP.

It’s argued the current legislative framework ‘may be generating a significant and disproportionate administrative burden’ because it sets out detailed requirements organisations need to satisfy in order to demonstrate compliance.

The idea is a new ‘risked-based accountability framework’ will be introduced, requiring organisations to implement a PMP, but allow flexibility to internally tailor the programme to suit the organisation’s specific processing activities.

What is a Privacy Management Programme?

A PMP is a structured framework which supports organisations to meet their legal compliance obligations, the expectations of customers and clients, fulfil privacy rights, mitigate the risks of a data breach – and so forth.

Such a programme should recognise the value in taking an all-encompassing, holistic approach to data protection and privacy; embedding data protection principles and the concept of privacy by design and default.

Core components of a Privacy Management Programme

There are a number of PMP approaches and frameworks in existence. The UK Government has not yet elaborated on what they would expect a PMP to look like.

This top-level summary is broadly based on the IAPP’s Privacy Programme Management approach.

  • Governance

Organisations should develop and implement a suitable framework of management practices which make sure data is used properly and in line with organisational aims, laws and best practice. This should include adopting a privacy by design and by default approach; ensuring appropriate measures are in place to prevent unnecessary risks.

  • Assessments

Achieving clear oversight of the data held and processed, including any suppliers used to support business activities. Developing risk assessment tools which help to identify privacy risks and manage them effectively (e.g. Privacy Impact Assessments / Data Protection Impact Assessments).

  • Record-keeping

Mapping and maintaining an inventory of where personal data is, its purpose, how it is used and who it’s shared with.

  • Policies

Developing and implementing clear policies and procedures to guide staff and give them clear instructions about how personal data should be collected, used, stored, shared, protected and so on.

  • Training and awareness

Making sure adequate and appropriate training is conducted to give staff the knowledge and understanding they need to protect and handle data lawfully and in line with organisational expectations in their day-to-day roles. Making sure people are aware of how their organisation expects them to behave.

  • Privacy rights

Putting in place appropriate procedures to effectively and efficiently fulfil individual privacy rights requests, such as the right of access, erasure or objection.

  • Protecting personal information

Crucial to any PMP is protecting personal information. Working in conjunction with information security, a data protection by design approach would be expected – a proactive rather than reactive approach.

  • Data incident planning

Creating and developing data incident procedures and plans. Having appropriate methods to assess risk and potential impact, as well as understanding breach notification requirements.

  • Monitoring and auditing

Last, but by no means least no PMP would be complete without a methodology for tracking and benchmarking the programme’s performance.

What might change?

To many who’ve endeavoured to comply with the GDPR, all of the above will sound very familiar.

So, the Government isn’t proposing we do away with all the hard work already done. It’s planning a relaxation to some of the mandatory requirements; giving organisations more flexibility and control over how they implement certain elements of their programme.

On the one hand, this could be seen as a welcome move away from a ‘one-size fits all’ approach under UK GDPR, giving organisations more flexibility around how implement their privacy programmes to achieve desired outcomes.

On the other hand, there are fears the removal of mandatory requirements will lead to a watering down of the fundamental principle of accountability (a principle significantly bolstered under GDPR).

As a data protection consultant since 2015, Philippa advises a broad range of clients and delivers data protection training. She regularly writes GDPR guidance to support privacy teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

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.

As a data protection consultant since 2015, Philippa advises a broad range of clients and delivers data protection training. She regularly writes GDPR guidance to support privacy teams in their day-to-day work.

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

Getting your Supplier Contracts Right

May 2019

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.

After a successful career in publishing Simon moved into data protection consultancy in 2015. Simon advises businesses of all sizes across a wide range of sectors. He held the role of Director of Information Governance at Royal Mail Group in the run up to GDPR enforcement. He regularly delivers data protection courses for clients and the Institute of Data & Marketing (IDM).

Copyright DPN
The information provided and opinions expressed in our content represent the views of the Data Protection Network and our contributors. They do not constitute legal advice.

SIGN UP FOR OUR NEWSLETTER

Get DPN updates direct to your inbox. Insight, free resources, guides, events & services from DPN Associates (publishers of DPN). All our emails have an opt-out. For more information see our Privacy Statement.