Podcast Episode 6 – Hot Topics in GDPR – Part One

Hot Topics in GDPR – Part One. I discuss some of the hot topics being discussed inside GDPR projects and amongst us Data Protection geeks. Topics include the right to erasure and backups, the need for lawyers to lead your GDPR programme and the thorny topic of what happens if a Government department is breached. I also give a run down of the big UK news of the new Data protection Bill.

Resources:

Rubrik.com

Data Protection Bill

Episode Transcript:

In THIS episode I’m going to talk about some of the hot topics being discussed inside GDPR projects and amongst us Data Protection geeks. This will include the right to erasure and backups, the need for lawyers to lead your GDPR programme and the thorny topic of what happens if a Government department is breached. I’ll also give a run down of the big UK news of the new Data protection Bill.

But let’s start with the right to be forgotten, or as it’s technically know the right to erasure. Everyone understands the right to erasure pretty much. I did a whole podcast on the topic in episode 3 of The GDPR Guy, but for those of you wanting a quick summary, it’s a right within the GDPR that means if an organisation has some of your personal data then you may be able to request they delete it. There’s lots of nuance to this, and many reasons why some data will have to be retained, for example for legal reasons, but the big gap is what happens with data that technically can’t be deleted, such as that on physical media.

Imagine a full server or disk backup or a physical piece of microfilm containing a dataset, the backup media is locked, in that you can’t technically edit the data to erase particular records. So how would you comply with a demand to erase all traces of a person’s data, including backups?

The first thing to say is that this is a common problem in that pretty much every organisation will have this problem, so you’re not alone. Secondly, remember that the GDPR is 100% risk based and wants you to do the best you can to protect data subjects and their data, to a point. It doesn’t expect you to invest in technologies or implement data protection strategies that you cannot afford or are infeasible for your organisation. So it’s all about complying as best you can, but not using this as an excuse to do nothing.

One strategy that everyone will likely utilise is for those backups that can’t be edited, a log is kept of what data should be deleted, such that if a backup is restored you can quickly make the deletions on the restored system before it gets live.

Now. I like this strategy, and there isn’t much alternative for those of you with uneditable backups, but making this strategy work is very very difficult at scale. In large organisations there is a massive disconnect between backup engineers and data protection personnel. Server and backup engineers are usually tasked with providing rapid restoration of service after an incident, and not pausing the process to work with application people to edit live system data. There is also a huge issue of the disconnect between server backups and logical applications and datasets. I may know that a disk on a physical server is backed up but it is very unlikely I will know exactly what transient data, serverless processes or virtual environments are currently residing on it.

The real answer is to move to hot data backup solutions that copy data and not whole systems which therefore allow for editing of backups. But there aren’t many of these.

The related issue of backups is simply knowing what data you have on what backups. This is a gap for most people, especially those using physical tape backups. If you want to know exactly what data exists in what backups you need a backup solution that’s intelligent, fast and scalable, such as Rubrik.

So ultimately, backups are an area where you have to do your very best, to erase as much data as you need to, but be pragmatic and focus on protecting the data subject’s rights as much as possible.

 

Another topic I see discussed a lot is whether you need lawyers to run your GDPR programme. This comes up for two reasons, one – GDPR is law and therefore people default to thinking that only a lawyer is qualified to give advice, and two – lawyers are keen to promote this idea to win business.

The simple answer is YOU DO NOT ALWAYS NEED A LAWYER for your GDPR advice. We comply with laws every day of the week, whether it be in our personal or professional life and we don’t need a lawyer then, and we don’t need a lawyer for GDPR. So whether you’re looking at your Data Protection Officer role or your GDPR programme lead, it doesn’t NEED to be a lawyer.

However there will be times when you will need a lawyer, or at the very least should use one, and these are where the extreme complexities of the regulation are such that you need clarity and precedent or you need legal documentation such as a contract amended.

If you’re looking for the ideal person for a particular role, such as the DPO or the programme lead then focus on their abilities and what value they will bring, rather than job titles. For example a lawyer that is highly risk averse in nature would be terrible as a DPO, constantly driving the business away from opportunity fearing the worst. Whereas a lawyer with a strong understanding of business, marketing and Information Security would be a great choice for a DPO and could give a balanced perspective to help all parties.

It’s worth remembering that the Data Protection Officer role under the GDPR is a pure adviser/auditor role and can’t be a “doer” of data protection. So this will suit a more compliance minded head. A GDPR project can have several different lead figures such as an executive sponsor, a DPO, an external consultant and a project manager with each role requiring a different focus.

So if someone tells you that any role outside of your legal counsel needs to be a lawyer, please ignore them and just find the best person for the job, whatever their background.

 

Now an interesting discussion point that is doing the rounds is what should happen when a Government department has a data breach. Do they get fined and if so, who do the fines go to?

This is quite an easy one to answer in that the GDPR allows for EU member state governments to derogate, that is create an exemption, for themselves when it comes to fines. Yes, Governments can make themselves immune to fines. This might sound outrageous, especially with the relatively common occurrence of Government data sets being breached, such as recently exposed breach at the Swedish Transport Agency in 2015. But remember that GDPR fines are paid to the Government, and in the UK the fines go direct to the Central Treasury, rather than the UK’s Supervisory Authority the ICO. So fining a Government department only for the fine to go back to the Government doesn’t really provide much of a penalty. This derogation against Government fines is up to each country to enact, and I think it’s a sensible move. But personally I would like to see other forms of penalties for Government and charity sector workers in the case of Data Protection incidents, such as sackings, public shaming or even criminal prosecutions. If it’s not fines, then there needs to be something else dissuasive that pushes people to care about our data.

And finally, the big UK news this week was the announcement on Monday by the UK Government’s Minister of State for Digital, Matt Hancock MP, that the Government will be introducing a new Data Protection Bill. In UK speak, a bill is a draft law and if it gets approved by the House of Commons, the House of Lords and receives the Queen’s approval, which we call Royal Assent, then it officially becomes an Act of Parliament, which is a UK law. The Data Protection Bill sounds interesting but it’s really just the Government setting out the GDPR, and the EU Data Protection Law Enforcement Directive, being implemented in the UK. Helpfully, they’ve detailed some of the derogations and how the UK will adopt it. For instance, the GDPR allows for countries to decide on the digital age of consent, being between the ages of 13 and 16, with the default being 16. Previously Ireland, and now the UK have chosen this to be 13, which is generally accepted as a sensible move.

Another inclusion that I’m pleased with is additional authority for the ICO to impose greater sanctions, such as it being a criminal offence to reidentify individuals from anonymised data. So for instance, if you had an anonymised piece of research data, you wouldn’t be allowed to merge it with another data set and mine it for identifiable personal data. It’ll also be an offence to alter records with the intent to prevent disclosure following a subject access request. Both of these offences would carry an unlimited fine and have the potential for being what’s known as a recordable offence. That’s an offence that gets recorded on the UK’s Police National Computer database which can be disclosed as part of previous conviction or criminality checks.

The Bill also states that companies will continue to be able to perform criminal records checks should they wish to. The GDPR denies this by default, so it’s good to see the UK has chosen to override this. And another useful inclusion is the ability to require social media platforms to, on request, delete information held about them at the age of 18.

And of course, this Bill will repeal the existing Data Protection Act from 1998.

So the Bill is nothing too unexpected, but still great to see a few very sensible choices being made by the Government.