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;
    o
  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.
    o
  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!]

7 thoughts on “GDPR: Does the Right to Erasure Include Backups?

  1. Hi David

    Another good article and a very pragmatic approach, which i would definitely agree to.

    I thing one thing i would also highlight is around Req. 8 and the Supervisory Authority interaction (ICO in UK). The ICO is very good out of all the SA’s to give assistance and guidance to organisations that ask of it.

    Indeed, IF (and there is the often an issue here) the DPO appointment has been made correctly then they will be acting in the best interests of the organisations Data Subjects (customers and employees) and be taking steer from the SA – NOT the organisation that employs them. Then when performing your organisations DPIA’s, if there is ever an area where you are unsure of the basis of processing and the implications regarding compliance with those articles then these can be used as part of the interaction with the SA and the risk based justification and the DPO will be part of that process.

    It really is an area of compliance when interacting with the authority really does help.

    Dave Wylie
    CIPP/E

  2. Hi David
    What do you think it will be the impact of GDPR on all the Internet companies that make their business model and only purpose in life the selling of their mrktg data base ? Do you think it will come down to a more sophisticated legal defence to be put in place and that is it ?
    With all customers and not-so-customers having the right to be forgotten or evoking the right for data portability ( with or without backups ) come what may what will be their company’s worth ?
    There are quite a few out there and big ones too.
    Martim

    • Hi Martim,

      [Please note: I am NOT a privacy or GDPR ‘expert’, everything that follows is my opinion only.]

      I assume organisations like that cannot use consent, so will have to go with legitimate interest. Though quite how they will manage that when EVERYONE on those lists want off is beyond me. That said, no-where have I read that selling personal data equates to processing, so if their contracts are written well they could push the entire responsibility for GDPR onto the organisation buying the list.

      Does that still leave the market database owner as the data controller? I’m not sure, but I certainly hope so, someone has to provide the facility for me to erase / amend my data.

      Sorry I can’t be more help.

      David

      • “I assume organisations like that cannot use consent, so will have to go with legitimate interest.”

        It’ll be interesting to see. But I think (and hope) they’ll be hard-pressed to come up with any legitimate interest that’ll convince a judge.

        “That said, no-where have I read that selling personal data equates to processing …”

        Article 4 defines processing as “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 …”

        I would argue that selling data inevitably involves “disclosure by transmission, dissemination or otherwise making [the affected data] available.”

        Would you not agree?

        Regarding erasure/correction of data sold, I believe this is covered in Article 19.

  3. Interesting article. I think it is absolutely impossible to expect any organization, especially mid-sized ones, to go back and erase someone’s data from all their backups, assuming you know exactly where the various “components” of data are. However, should a previous image of say a customer database be recovered and put back in production (due to a disaster), it is clear that you would have to re-apply the amendments, deletions etc. You also need in parallel to have the right controls in place so that these older images can not be accessed or restore without a good reason or by authorized employees. Plus encryption of course.

Leave a Reply

Your email address will not be published. Required fields are marked *