[GDPR] Where to start with your compliance (and evidencing it)

GDPR – Where to start with your compliance (and how to start evidencing it)

This part 1 of a series of articles on ‘Where to start with your compliance (and evidencing it)’. 

So let’s start with the good news. If you’re already complying with the prior Data Protection Act (1998-2018) then while there is work to do you can alter most of it quite easily and the overhead isn’t that bad.

Oh, I hear you say – I uhh, Can’t find any of the documentation or policy I had for the DPA other than this rather generic privacy terms and conditions that I copied 20 years ago from somewhere. Firstly, don’t worry – you’re not alone and most of the SMEs that I’ve dealt with in the last three years about conforming to the GDPR is in the same place. Data Protection has always been taken seriously as a concept by most businesses, especially the security of the data (normally more about keeping trade secrets than customer data) but nearly all of them haven’t got a policy, procedure or staff training to speak or evidence of – they were far more concerned with evidencing for the taxman then they were for the ICO.

Starting from the ground up.

So let’s start from a fresh standpoint and review your organisation from top to tail to see what you might need to do to give yourself GDPR compliance, I’m afraid I’ve never been good at writing brief details – I assume that if you’re here you’ll want more than titles! – this list isn’t in any particular order.

  1. You need to nominate someone in your company to be responsible for data protection. This doesn’t need to be something as formal as a Data Protection Officer but someone in your business needs to ‘own’ it. I’ve found that companies that make it shared ownership or give it no strict owner always fail to get anywhere near compliant let alone keep that compliance on-going. Obviously, you should then let this person read-up and train-up on all the things GDPR and data protection (including reading the guides I post), let them attend seminars or allow them to buy some books (there are quite a few I could recommend).
  2. Review Internal systems and processes
    1. Create a data map to show where all of the gateways for personal data are in your company (e.g. Sign-up forms, new staff contracts, why they’re collected, then where they’re stored (including country) and who has access to them).
      1. categorise business processes into those that are in GDPR scope and those that aren’t (they may fall under confidential business processes)
    2. Do you already have to conform to another standard such as the ISO27001 or the PCI DSS? – See what overlaps with the GDPR and see what frameworks can help you keep both in check at the same time.
    3. Break this data map down into a more legal basis – Under what legal basis (as defined by GDPR) do you collect and store this data
      1. If it’s Consent – you need to start questioning how they consented and if that meets the GDPR (e.g. Opt-in) and if you need to put in place the processes for if they remove that consent.
      2. Is any of the data you hold already expired in your legal basis for using, or worse is it a tad
      3. questionable such as purchased contact lists for cold calling?
      4. Is all of your data held in the European Economic Area or within a country that is considered safe (Such as the US where the EU-US Privacy Shield safeguards such standards)? International data transfers come under more strict controls under the GDPR  and where you’re transferring data protected under the GDPR to certain untrusted countries you need to provide a lot of evidence and risk controls to safeguard it.
      5. What third-party’s processors do you share the personal data with? This could be any Sas systems you pay for and access online like Zendesk (Support desk), Salesforce (CRM), your email provider such as Office 365 or Google Apps for Business. This also extends to your website – Is it run and hosted by a third party?, Do you have Google Analytics or heatmap software installed like Hotjar? Add it to the list!
        1. For each of these processors, you should get an agreement in place (a data processing agreement) which contractually tells that processor what they are responsible for int he eyes of GDPR, including how to pause data, who they can share it with and any policy around what to do if there is a data breach – It also allows you to put SLAs in place to make sure that you get everything you want within a decent time. two years after GDPR most Sas providers or data processors by nature already have generic agreements at this point for you to agree to when you sign up (For example you can see Hotjars Data Processing Agreement here)
    4. Time for a DPIA – A Data Protection Impact assessment – For each of the processes you’ve identified as part of your data map it’s time to review any that have a high risk to the data subject (or to be honest if it’s your first time and there aren’t that many do all of them). The idea of a DPIA is for you to weigh up the risks and benefits of any processing activity and list out the controls you have in place to mitigate that risk or allow you to understand/evidence that the risk is too high and no longer continue that processing (and to find an alternative).
    5. What steps do you currently have in place to protect the personal data in your care?  This could be;
      1. Physical security of that data (e.g. it’s behind locked doors)
      2. Training, Have you given your staff training on What GDPR is, The importance of keeping data secure and how they should treat the sensitive data they come in contact with on a daily basis?
        1. Covering the new rights of GDPR, in particular, is important and you’ll need to create policy/procedure/training for how and when to erase data, to understand what a breach is and generally how they should practise a privacy-first approach going forward (e.g. only collect what is needed clearly, rather than everything to decide later).
      3. Is the access to the personal data in your care limited to only those who need it? is it available to everyone with trust policy and training? (The more people who have access who don’t need it – if you trust them or not – The bigger the risk and harder to explain if something bad happens).
      4. Does your IT team run regular anti-virus scans on your network, does it perform any penetration testing on your system or any of the applications that you use (e.g. If you store personal information on your website does is it tested)? If they don’t – they probably should.
    6. Start to write and put-together different policies and procedures as you work through the above, even if you make a basis title checklist of what you may need e.g.
      1. Privacy Policy for the website (covering sign-up to Marketing, Product Information and Sales)
      2. Cookie Policy for the website as well as a Cookie Bar that allows visitors to opt-in to different cookies use.
      3. Employee Contract update to reference GDPR obligations (of both organisation and employee).
      4. Third-party data processing agreement.
      5. Privacy Notice for a website for use with any information gathered through the legal basis of Consent  (Then remember to store and evidence that consent)
      6. Data Destruction Policy (How long is your data kept, how is it then destroyed – How do you protect the GDPR right to erasure (The right to be forgotten))
      7. Incident Response Policy/Procedure – IN the event of a data breach what procedure will your team follow to ensure they protect the rights and freedoms from being breached any further, to prevent any other breaches and to assist those whose data has become available (including alerting controllers, processors, the ICO, data subjects and authorities where needed) – This also should cover ‘near misses’ that is where a data breach did not occur only for the sake of luck (A laptop left on a train unlocked but no one goes near it, a file goes missing but is recovered in a secure environment. A website vulnerability is discovered but personal data had yet to be uploaded).
      8. Data Back-up Policy (How do you currently backup your data, How long is kept for, is it encrypted? who is responsible)
      9. General Information Security Policy (Lead by your IT team) covering off password complexity (access control), How you classify information (secure, public etc), How you will transfer information to third parties where needed, Anti-virus and firewall sub-policies (how does someone add a new rule), Sub Policy for Vulnerability management (how quickly are your computers updated when a vulnerability is discovered, how is this handled), Is any cryptography used?, How are communications and emails stored – is two-factor authentication enforced for cloud email and drive documents etc.
      10. Data Portability Policy (How do you ensure that the personal data in your company is portable, how will you do it if a client requests – more so how is it not portable, get your procedure and defence for Nos in place at the start).
      11. Personal Device Policy (You may have trained your team on GDPR but what is your policy about their personal devices, Mobiles, laptops – Is personal data allowed on them? Are those devices are allowed on the general company wifi? – If they are and it is, What standards do you need in place? Device encryption, access to remotely wipe etc).
      12. Removable Device Policy – Even more physical security! What’s your policy around data sticks, CDs, or general removable hard drives. Remember that if you don’t have a policy and you never tell staff as such then you’re just opening the door to potential trouble.
      13. Remote Working Access Policy – What access do your staff have when working remotely – Is it all done so online through cloud portals? Are they allowed to copy data to their local remote machine? Are they allowed to connect on public wifi? – I wrote one of these in 2018 and it’s fair to say when Covid-19 hit I had to throw it out the window, What I wrote was far too limiting and protective which was fine when it was one person every 6 months for a day but when it’s a large team all day every day… you need to make sure you balance it just right!
      14. Subject Access Request Policy – A Procedure on what your request staff should handle SAR as well as how your DPO and sub-teams will put the data together.
      15. Sub-processors list and policy – What are the minimum requirements you have for a sub-processor, How often do you check-in with them to make sure that they still comply to the policy and are still secure (Doing it once at the beginning of the relationship just isn’t enough!).
      16. New Starters policy – What access do new starters get? What information will you collect? What training do they need to undertake before they’re allowed access? How is this tested or monitored?
      17. Staff Exit Policy – When a staff member is leaving your organisation what is the policy for removing access, ensuring they don’t have any copies of data. Evidence each of the checks that you perform to make sure that the leaving staff member doesn’t still have access and can potentially cause damage – The Implications of a rogue staff member have already been tested under the DPA and in turn reviewed under GDPR when a displeased former member of Morisions years after leaving released data that they had kept.
      18. GDPR on-going compliance Policy – How will you make sure you keep compliance – How often do you check all policies and general compliance – GDPR is a journey, not a destination.

Verifying the requesters identify.

When you’re going to be providing personal data to someone who has requested it, potentially very sensitive information you better be damn sure that the person requesting it has the right to do so. The most likely scenario is that it’s someone requesting information about themselves or a parent about a child. The GDPR requires you to seek enough information (but not excessive) from the requester that you believe is sufficient to verify their identity (or their right to request on behalf of someone else).

This means that if one of your employees makes a request about themselves then it’s unlikely you’ll need to make any verification checks – You should know your employee and be able to verify them on the spot. However, if the person making the request is one of 100,000 customers on your database that you will only ever have known as a statistic in a meeting then you’re team are going to want to verify specific bits of information about them (such as secret questions and responses) or even requesting documentation such as photographic identification, utility bills (The same evidence that you’re likely to need if opening a bank account or requesting a mortgage).  It’s important to remember that you cannot store the information provided to you for verification – It needs to be destroyed no matter if they pass or fail the verification. It’s also possible to verify a user by asking them to sign-in their account area held with you (say if an Energy provider) and submit a DSAR verification request or through a multi-factor system (such as those used by online banking). As long as you as an organisation the person is who they say they are (and you can evidence the logic in that decision) then you can authenticate them. 

While Data Subjects must receive their answered DSAR within 30 days, you can in theory pause this counter when you request the customer verify themselves and only continue it once you are happy. 

Writing Policy and Procedures

Writing good policy, or having one written for you (or one you’ve purchased as part of a kit) and applying it to the workplace and your processes are two very different things. This is why it’s best to have someone responsible in your business, and that you give that person the power and resources they need to deliver it.

Good policy and procedures need to be clear to follow and explain every aspect. they should be able to be picked up by someone brand new to your company and understood. All of these policies should be accessible by your team at any point they need them.

Good policies and procedures also need to be possible. There is no point writing that all of your data will spend it’s live encrypted and pseudonymised (When the processing of personal data is done in such a manner that the personal data can no longer be attributed to a specific person without the use of additional information that is kept and processed separately) and then actually it’s only possible to have 10% of it. As soon as you allow one part of the policy to be ignored, how can the rest of it be trusted or other policies be followed?

Good policies aren’t about Data Protection stopping everything. Bad policy and DPO says no to everything a good policy/procedure and DPO will find a way to balance the commercials of a processing activity with the protections and rights of the data subject (especially when they’re involved from the start)

Policies should always be enforceable (so there are repercussions for any reaches to teams or staff members), and that for everything within the policy someone or team is responsible for it taking place (e.g. it’s one thing to say the company will use Antivirus, it’s another to say that The Head of IT through their team are responsible for Anti-virus being installed and up-to-date on each workstation).

The Importance of training

I drum on about this a lot, but the most important part of bringing GDPR to your company is training. I know of several other data protection professionals in similar positions to me (or who have managed to go full time as consultants) who say that DPIAs are the most important aspect and I can’t deny that a DPIA is how you find risk for data in the first place and certainly, they’re a close second place for important but to me it’s training.

Your staff will need an array of training depends on how much access to data they are allowed. This may range from the basics of what the GDPR principles are, or understanding the administrative fines, or understanding the risk analysis to learning the entire GDPR from top to tail (If you have a designated data protection lead or Data Protection Officer (or even a C-Suite level officer it’s always good to have a deputy who has a very good working knowledge in case your main post holder is incapacitated or unavailable – such as maternity/paternity leave or annual leave).

When we try and work out how we can best prevent the potential data breaches under GDPR as well as work in a transparent way that mixes commercialism and privacy then training is the obvious winner. The more you train your staff the more on a day to day basis they’re looking out for data subjects freedoms – the more they understand the risks involved naturally (With or without a DPIA) and generally the more protective they will be. Human error occurs but you can mitigate and minimise this by regular training – and allowing those responsible the external training they may need to stay at the top of their game.