A warm welcome to the fourth blog in the series 10 Steps to GDPR Compliance. In each post, we cover two Steps to help you to become GDPR compliant. By following along and completing these 10 Steps, you’ll be building out the Privacy Framework that will power your ongoing Privacy Governance.
This series is brought to you by Keepabl, named to the RegTech100 for 2021 as one of the world’s most innovative RegTech companies that every financial institution needs to know about in 2021.
Last week, in Steps 5 and 6, we started bringing the Privacy Framework together and reviewed Security, preparing for a breach. The two Steps we’re covering today continue building out your Privacy Framework:
- Step 7: Data Subject Rights, and
- Step 8: Processors
By the end of this post you will understand what Data Subject Rights are and what a Processor is and how to ensure that your dealings with both are GDPR-compliant. (We’ll use ‘GDPR’ for both the UK and EU GDPRs as the obligations here are almost identical.)
Step 7: Data Subject Rights (or DSRs)
GDPR not only strengthened DSRs but, as we’ll see, it also increased public awareness of their rights and the number of times individuals actually exercise them.
There’s no doubt the rate of DSRs, and public awareness, has been growing since by GDPR:
- even just a few months after GDPR took effect in 2018, Deloittes’ report on GDPR and Financial Services stated that 60% of respondents had seen an increase in DSRs, and
- DSRs counted for over half of complaints to the UK ICO in 2019/20, with access requests (or DSARs) by far the most common reason at 46% and complaints about the right to prevent processing counting for another 8%.
The maturity of your DSR processes may well be driven by how many DSRs you receive. In our experience with Financial Services customers, DSRs qualitatively looks like a binary topic depending on whether you’re:
- B2B – in which case you likely get hardly any at all, but the ones you do get are the thorny, difficult ones from ex-employees, or
- B2C – in which case you’ll get a steady number from customers as well as those few ex-employees!
However, the complexity, pain and cost of even a single DSR can be surprising given the sheer volume of personal data you may have, and where it’s hiding.
You’ve a LOT more personal data than you think!
Back in the innocent days of 2012, IBM reported that an astonishing 90% of the data in the world in 2012 had been created in the previous two years.
More recently, IDC and Seagate reported that the ‘global datasphere’ will grow from 45 zettabytes in 2019 to 175 zettabytes by 2025. Statista reports similar growth from just two zettabytes in 2010 to 15.5 in 2015, 59 in 2020 and predicts 149 zettabytes in 2024.
That’s massive growth in anyone’s language and a chunk of that data is personal data. As well as all your employees’ financial data, review data, health, wellness and other data, you’ve likely lots of data on website visitors, service users, banking customers, investors, partners, suppliers … the list goes on.
Can you find the data if someone asks?
How many DSRs are there?
The two major DSRs are the right of access and the right to erasure, with 71% and 62% of organisations receiving them respectively, roughly 2.5 times the size of the next category, according to the IAPP – FTI Consulting Privacy Governance Report 2020.
These two types dominate the DSR discussion. But as you can see in this handy infographic, there are actually 10 DSRs in GDPR!
Some of these rights are absolute, such as the right to withdraw consent and object to marketing, meaning you have to comply with them no matter what.
However, most are qualified, meaning they come with particular conditions, for example they only apply to certain personal data but not others, or only apply depending on the legal basis that applies to the processing.
Preparation is key
We’re focussing on GDPR here, but there are other laws in Europe and around the world that include individual rights. So it’s vital, regardless of how many DSRs you receive and how you manage them, that you’re prepared for when someone exercises their rights.
If you’re not, it will be incredibly difficult for your organisation to handle any requests it receives.
This means establishing:
- the people you need to manage and help with DSRs,
- the policies, procedures and records you’ll follow,
- where your personal data is (another reason to be grateful for your excellent Data Map!),
- how you’ll respond to the individual and fulfil the request within the one month set by GDPR (which can be extended in certain circumstances),
- the technology you’ll use to find and redact the data at scale, and
- if you’re going to refuse it, the grounds on which you can do so.
Step 8: Processors
Processors are simply your suppliers who process personal data on your behalf. Typical examples are CRM tools like Salesforce.com or HubSpot, or a group member who does payroll for all group companies.
Remember GDPR only cares about personal data so, if your supplier doesn’t process personal data for you, they’re not a processor for GDPR.
A word of caution – if personal data is processed, some suppliers you think are a processor may turn out to be a joint controller. GDPR formalised this category of player, which is still causing a fair degree of uncertainty, and it’s not unusual for different parties in the same roles to take varying views on their GDPR status.
Your Data Map again!
You’ll need to identify all your processors, then prioritise that list so you can carry out due diligence, and put in place GDPR-compliant wording, starting with the highest risk first.
This is where your Data Map, that we looked at in Step 3, again comes into its own and you’ll be glad you flushed out all the processors used by each part of the organisation.
You should have a set procedure for vetting processors so that you reduce your risk and ensure you’re complying with GDPR – which requires controllers to:
‘use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of [the GDPR] and ensure the protection of the rights of the data subject’.
At a minimum, you’ll need to:
- identify what personal data is processed and why (carrying out an impact assessment is always recommended and you must carry out a Data Protection Impact Assessment if there’s a likely high risk to the rights and freedoms of the data subjects),
- confirm whether a ‘transfer’ is involved which, for GDPR, means the personal data is provided or made available to a person from a third country or to an international organisation (think the Red Cross and WHO, not Coca Cola),
- check the processor’s Privacy and Security policies and procedures meet your requirements and let you satisfy your legal obligations,
- confirm any sub-processors, and
- put in place a GDPR-compliant Data Processing Agreement or DPA.
Data Processing Agreements
Often called a Data Processing Addendum because they were added to contracts as an addendum when GDPR came in, these contain the required legal wording when you use a processor.
Before GDPR, processor wording was just a short paragraph in a contract and the required due diligence wasn’t so specific. GDPR clarifies what that due diligence should cover, and it’s a bit more involved. And the contract wording has now become a three to six page ‘DPA’.
Thankfully, these are now pretty common. And Keepabl has a great checklist for you on each of the due diligence and the agreement.
Make sure there is a transfer – if the personal data isn’t going outside the UK (for UK GDPR) or the EEA (for EU GDPR) then you don’t need to worry about this part.
Essentially, you need to identify when a transfer takes place (there’s your Data Map to the rescue again!) and establish the correct safeguard for the transfer. If you can’t – the transfer can’t take place.
These safeguards must be put into place before the transfer of personal data to a third country or organisation so that legal remedies are available for data subjects under GDPR.
If there is a transfer, there’s a strict pecking order for safeguards:
- First look for an adequacy decision that applies to the third country, under Article 45. There are only 12 (there were 13 before the EU-US Privacy Shield fell in Schrems II). We’re hoping there’ll be an EU GDPR adequacy decision in favour of the UK, to help keep data flowing post-Brexit, but that’s a whole other story!
- Second, if there’s no adequacy decision, you look to implement one of the safeguards in Article 46, which usually comes down to Standard Contractual Clauses or SCCs. The existing SCCs are being updated shortly. (Binding Corporate Rules are in there too, although there have been fewer than 200 approved to date so they’re unlikely to apply but if they do, they fit in here.)
- After that, you’re likely looking at one of the derogations, but these aren’t meant to be strategic solutions, more irregular, tactical solutions.
Article 28 of GDPR contains most of the rules for using processors that have to go into a DPA, including that they have to obtain written approval from the controller to appoint sub-processors and reflect their DPA with the controller in their contracts with sub-processors.
Other rules include that processors must make sure that anyone authorised to process the personal data does so under confidentiality. And they have to support the controller in reacting to DSRs.
We’re here to help!
As you can see, there’s a lot to unpack with Data Subject Rights and Processors, so it is important you get to grips with them. We’re here to help!
Next week – Steps 9 and 10!
You now know about Data Subject Rights and Processors! Next time, we’ll be covering our final 2 steps in the series, Step 9: Privacy Notices and Step 10: Training and Awareness.