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!]

15 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.

      • Hi.

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

        For sellers of databases for marketing they MUST process it in order to work out who to sell it to, it needs processing to be categorised by age, location etc….

      • I agree, I think the description of processing in Article 4, which includes “disclosure by transmission, dissemination or otherwise making available” FULLY covers the sale of data, but unless it’s spelled out you know some organisations will plead ignorance.

  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.

  4. “it is clear that you would have to re-apply the amendments, deletions etc”

    But how would you know what to delete, unless you keep a record of it, which is exactly what you are NOT allowed to do. I fail to understand how this could ever would with backups. The idea of a backup is that you freeze a system/data state at a specific time. The idea that you mutate this information (to delete something) doesn’t make much sense to me. The concept of deleting something after a restore is more viable, but that would mean that you store what to delete (which is about the same thing)

    • I think you’re missing the point a bit. Having a record saying NOT to process my personal data is not the same as HAVING all the personal data. In the end, if an organisation cannot stop processing my data because they keep restoring it from back-ups, they have not met the intent.

      I am far less concerned with organisations having my data on backups than with how they use it, but there is still a risk of loss. If you don’t need it, don’t keep it.

      There is no way organisations are going to get this right in the short term, but that is no excuse for no revamping old backup processes.

    • Our thoughts on dealing with this issue is to keep a list of “ids” that want to be forgotten and then re-apply those after you’ve restored things.

      I think for many systems, depending on how things have been architected anonymising them will be enough compared to actually deleting the record from the system. If I have something that says “Contact ID 2342342” and literally no way of knowing who that person is because all the information about them includes things like “Went to event X on date Y” “Paid for Product X on date Y” etc. Then I’m guessing that would be fine.

      It does mean though that in theory I could restore a backup and I have a list of all the IDs of people who wanted to be forgotten so I could use that list to recover the information. Which goes back to the core of the issue in this article.

      However the specific issue you mention here “But how would you know what to delete, unless you keep a record of it, which is exactly what you are NOT allowed to do” I think can be worked around.

  5. Hi, this is actually not what has been published elsewhere i.e. you do not have to delete backup sets:

    “The GDPR is open to interpretation, so we asked an EU Member State supervisory authority (CNIL in France) for clarification. CNIL confirmed that you’ll have one month to answer to a removal request, and that you don’t need to delete a backup set in order to remove an individual from it. Organizations will have to clearly explain to the data subject (using clear and plain language) that his or her personal data has been removed from production systems, but a backup copy may remain, but will expire after a certain amount of time (indicate the retention time in your communication with the data subject). Backups should only be used for restoring a technical environment, and data subject personal data should not be processed again after restore (and deleted again). While this adds some complexity, it allows organizations to have some time to re-engineer their data protection processes.”

    http://blog.quantum.com/backup-administrators-the-1-advice-to-deal-with-gdpr-and-the-right-of-erasure/#.Wvd604gvzIU

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.