Right to Erasure

GDPR: The Right to Erasure Does Not Always Mean Forgotten

The title should actually be more in question form; Did you know that there’s even a difference between being erased and being forgotten?

Article 17 of the GDPR is “Right to erasure (‘right to be forgotten’)“, which suggests they are the same thing. They are not [quite], and I think the only reason the right to be forgotten was added in brackets is because everyone was already calling it that. But it’s just not accurate …enough.

Continue reading
Right to Erasure

GDPR: Does the Right to Erasure Include Backups?

I received what, to me, was an interesting question the other day (thank you Gareth), which was [paraphrased]; Does the GDPR’s Right to Erasure (a.k.a. The Right to be Forgotten) include every instance of the data, including those contained in backups?

The short answer is yes, it does, but that is simply not what is going to happen in the real world. I can see three possible arguments organisations could use to avoid making the potentially significant effort of erasing data subjects from backups:

  1. It’s backed up and therefore not processed – this is negated by Article 4, Definitions – (2) “‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;
  2. Interpretation of the phrase; “…taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures…” – While this phrase, and several similar equivalents, are not used directly in the context of backups (which doesn’t seem to be addressed at all outside the context of ‘storage periods’) it nevertheless suggests the the GDPR has wiggle room. However, to even think about using this argument, you’d better do a Hell of a lot more to make your argument. The word ‘reasonable’ in lawyers terms is built on precedent, in cybersecurity it’s built on your ability to demonstrate a credible and sustainable security program.
  3. Plead ignorance (i.e. We didn’t know we had it!) – This is no different from; “Sorry officer, I had no idea how fast I was going so the speeding ticket cannot apply!”. If I was the supervisory authority, these are the organisations who would be prevented from processing personal data, and/or receive the biggest fines. Not knowing you even had the data in the first place is either laziness, incompetence, or both.

There will absolutely be scenarios where the cost and level of effort necessary to remove a data subject from every system could rightly be deemed ‘unreasonable’. However, in this scenario, the difference between you saying it’s unreasonable and you demonstrating that it’s unreasonable will directly impact the egregiousness of your offence. And if you accept that the penalties associated with non-compliance with the GDPR will be based on the egregiousness of the offence, it follows that the more you do pro-actively the better off you will be.

From my perspective, the only way to do this is to perform what follows below. While this may seem like a lot, not one of these steps is something you shouldn’t either be doing already, or doing in preparation for May 25th 2018.

How to Justify Non-Compliance with Article 17 (for Backups)

Caveat 1: I am in NO way suggesting that this is ‘officially approved’ mitigation, this is based solely on my experience and a little common sense.

Caveat 2: This assumes that Article 17(3)(a-e) does not apply.

Req. 1: Run a Risk Assessment (RA), a Business Impact Analysis (BIA), and a Privacy Impact Analysis (PIA) – Put simply, you cannot decide whether or not fix the problem until you have run these three fundamentals. The RA and the PIA would be the first things I would ask for if I was an auditor, and the BIA would be the first thing I would ask if I was on the BoD.

Req. 2: Get your Policies, Standards and Procedures in order – These represent your culture, your operational baselines and your corporate knowledge respectively. Unless you know exactly what to do, what NOT to do, how to do what you do, and what you’re doing it with, you cannot demonstrate appropriate controls. Ever.

Req. 3: Education: Unlike PCI, where trying to educate most organisations is utterly pointless, privacy is everyone’s problem. Your entire organisation must be made aware of their responsibilities for the protection of personal data, as well as trained on how to report suspected loss or manipulation. Education is by far the best and cheapest way to reduce risk.

Req. 4: Map business processes and data stores – You must know how data is handled in order to understand how and what get stored at the end of the processing. Also, if you cannot show that your current processes enable the enforcement of future data subject requests, then you will not be able to justify keeping the old stuff. You must stop the bleeding.

Req. 5: Determine if current data stores match data retention policies – Part of Req. 2 includes compiling a record of all data retention justifications and timelines for all data types (most notably ‘special categories’). Should your processes for data storage not include a robust methodology for removing old data this will not look good.

Req. 6: Document your plan to remove data over the course of a specific time frame – Not much point trying to explain why you can’t delete something if you NEVER plan to do so. Even if the plan is over the course of 7 years, have one, as it will likely be a negotiation at this point.

Req. 7: Obtain Board of Director’s acceptance of residual risk – If this issue has not made it to the BoD level, I would have significant reservations as to just how seriously you are taking it. If you get audited by the supervisory authority it will not be the IT admins they are talking to.

Req. 8: Tell the supervisory authority – Wait! What!? TELL the supervisory authority, are you stupid!! Perhaps, and I’m not saying this is the right approach in every scenario, but the GDPR is not there to put you out of business, and supervisory authorities are not dictators. Everyone is in the same boat here, we’re ALL learning, so take advantage of the confusion.

As things stand right now, you’ve already had over a year to fix this issue, and you have just under another year before you are, quite literally, breaking the law. I understand the difficulty, but after May 25th 2018 you still have to explain why you wasted the previous 2 years. Every requirement above fits very neatly into 1 or several of Article 83’s ‘regards’ given to individual circumstances;  Negligence, actions taken, degree or cooperation, even HOW the infringement became known to the supervisory authority, all have bearing. The more you can pre-empt, the less the negative impact.

Finally, if you fall for ambulance chasers, or are terrified of the impact the GDPR will have on your business, you clearly aren’t doing what you should be doing. Bite the bullet, hire a lawyer, and get moving on this.

[If you liked this article, please share! Want more like it, subscribe!]