GDPR: it's not too late
Although the GDPR took effect in May 2018 — almost two years ago now — decoded.legal gets approached a lot by companies which have heard of it but done nothing or very little.
Should they have done something? Absolutely!
Is it the end of the world that they hadn't? Probably not. At least they're thinking about it now.
If you too are in that position — if you should have been thinking about data protection but haven't done so yet — this post is for you.
Get a handle on what data you are processing
If you don’t know what personal data you are processing, stop before you go any further.
Get the right people together (or, if it's just you, make yourself a coffee), and identify each part of your business, and work out what personal data you process for that. Think HR, marketing / business development, customer management, service delivery, and whatever else you might do.
Once you know what data you have, document it. This document is usually known as a "record of processing activity" or an "Article 30 record".
I'd suggest downloading one of the Information Commissioner's Office's templates, and using that. It's not mandatory to use the ICO's template but, in the event of a problem / investigation by the ICO, using their template means they would be hard-pressed to complain about how you had approached this.
If you haven't thought about the GDPR yet, this could be a bit painful initially, but it needs to be done. It's not a "once-off" exercise so, when you've done it, make sure you review it regularly. This could mean tying it in with your project delivery process, if you are sophisticated enough to have one, or else just making a note to check every couple of months.
Work out if you are a controller or a processor (or both)
There are two main categories of actor in the GDPR: people who determine the purpose and means of processing, known as "controllers", and people who follow the instructions of a controller, known as "processors". You might even be a "joint controller", if you are working closely on a project with another controller.
You need to know when you are acting as a controller, and when you are a processor, so you know what obligations the GDPR places on you, and what you need to expect from customers and suppliers.
Some times it's easy, other times it's less straightforward.
The regulator, the Information Commissioner's Office, has published some handy checklists.
Determine your "lawful bases for processing"
Processing of personal data is only lawful if each act of processing meets one of the six "lawful bases" set out in the GDPR.
Although consent is mentioned regularly, consent is just one of the six bases; while it may be the best fit (or the only choice) in some situations, there's a good chance that one of the others will be a better fit.
Other bases include:
- that your processing is necessary to perform a contract with the data subject
- that you are required to carry out the processing to comply with a legal obligation
- that the processing is necessary for a legitimate interest (of yours or someone else), and that your / their interests are not overridden by the rights of the data subject. If you are going to rely on this, you really should be carrying out a proper assessment, both to ensure that you can, correctly, rely on it, and also to give you a paper trail, should you need one, that you have thought it through properly.
Remember, you need to have a lawful basis for each and every act of processing you listed in your record of processing activity.
Check you have a valid registration with the Information Commissioner’s Office / you have paid your fee
Many organisations processing personal data will need to be registered with the regulator, and pay their annual fee. If you do need to register but haven't, it's a criminal offence.
It's cheap if you are a small or medium-sized organisation, and rather more expensive if you're bigger.
There are some exemptions from the requirement to register, and the easiest thing to do is go through the ICO's online form.
Tell people about your processing
If you are a controller, one of the requirements of the GDPR is that you tell people about how you process their data at the point you collect it If you've got the data from someone else, you've got to tell the data subject:
- no later than one month after you get it
- if you are going to use it to communicate with the data subject, in or before your first communication, or
- if you are going to disclose the data to someone else, at the time of, or before, you disclose it.
There's a long list of things you have to tell people about, but it really boils down to telling them who you are, what you are doing and which bit of the GDPR lets you do it, what data are involved, any sharing or disclosures, and information about their rights and how to complain.
Most companies try to comply with their transparency obligations through a "privacy notice" on their website. You can see decoded.legal's privacy notice here, and it is a good example of a layered notice, with high level information up front, and more detailed information available for anyone who wants to dig down. It's also in clear, simple language, and gives only the relevant information. We also make a point of highlight key things, and signposting the notice, just before you give us personal data.
You need to keep your notice up to date, so tie it in with whatever process you have for keeping your record of processing accurate.
Document your internal policies and processes
One of the new principles of the GDPR is "accountability". In essence, that means not just complying with the rules, but being able to show how you comply. And that means having your policies and processes documented.
What you need will depend on what you are doing, and the more risky, intrusive, or expansive your processing, the more the regulator is likely to expect. Topics you most likely need to cover are:
- Overarching data protection policy
- Maintenance of a record of processing
- Data subject rights
- Data processors and other third parties
- Security of personal data
- Detecting, investigating, and handling personal data breaches
- Data protection impact assessments
- Privacy by design and by default
- Data protection officer
- Transfers of personal data
There's plenty of guidance on the ICO's website if you want to do it from scratch, or else decoded.legal can help you put together a suite of policies and processes to give you a starting point.
Review, and document, your security arrangements
Security and data protection are not the same, but they are definitely complementary, and ensuring you have appropriate security controls in place is one of the requirements of the GDPR.
Proportionality is the key to understanding your security obligations, and that essentially means that you need to put security measures in place which are appropriate to the risks you face. If you process relatively little data, none of which is particularly sensitive, your security measures will not need to be the same as someone who processes a lot of data, or else more sensitive data.
Write down your security policy, so you can use it as the basis for training staff, and so you can show the regulator if needed.
Identify contracts with suppliers which are processing personal data for you, and make sure the appropriate clauses are in place
If you have a third party processing personal data on your behalf, or if you are processing on behalf of someone else, your contract will need to have appropriate data protection provisions in it, along with all the other usual commercial / legal bits and pieces (like details of what you have to do, how you pay / get paid, what happens if things go wrong, and so on).
This bit of the contract is known as a "data processing agreement". The GDPR requires you to have specific things in it, so there should be a degree of commonality across all agreements but, of the many I've seen — 100s now, I expect — they are often quite different, and some are more reasonable than others.
Note that, if you are required to have a processing agreement in place and do not, it is an automatic breach of the GDPR.
Decide if you need to appoint a data protection officer and, if you do, appoint one
Some organisations need to appoint a data protection officer. This is person (or company, if you want to outsource it) has what is effectively an advisory, oversight and audit role, telling you what you need to do, and checking that you are meeting your obligations. They're not responsible for compliance, but rather for checking that what you are doing is correct.
If you do have to appoint a DPO, you don't necessarily need to hire someone, if there is someone already in your business who could do the job — the main requirements are they they have an "expert" knowledge of data protection law, and that they are independent of the business's processing activities. (You probably can't appoint the head of marketing, or a data scientist, as a data protection officer, for example, as they'd be marking their own homework.)
You must appoint a data protection officer if your core activities require:
- require regular and systematic monitoring of data subjects on a large scale
- processing on a large scale of what is known as "special category data" (including health-related data, or data relating to religion, politics, or sex), or data relating to criminal convictions and offences.
There's often a judgment call to be made as to whether you need to appoint a DPO or not, as the qualifying criteria are not particularly clear.
This is all a bit overwhelming...
If you've read through this, hopefully you'll have a reasonable handle on where to start.
But if it's all a bit overwhelming, don't worry: by reading this, you've taken the first step, and that's usually the hardest thing to do. If you don't want to do this on your own, we're happy to walk you through it, and do as much of the heavy lifting as we can, so that you can focus on doing whatever you do to make money.
If you're ready to crack on alone, excellent — get on it with it! Make a plan, document it, and follow it through. We're here if you need ad hoc advice.
See here for more about decoded.legal's privacy services.