Support

Akeeba Backup for Joomla!

#29378 GDPR, Right to Erasure / be Forgotten & Data Backup Archives with Akeeba Backup Professional

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Saturday, 14 April 2018 17:17 CDT

PhoenixUK
Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

Hi There,

I am at this point just seeking Akeeba's input at present to a rather large headache, that not just I am having but no doubt anybody who is working towards EU General Data Protection Regulation (GDPR) compliance, whilst utilising Joomla for the website source and it's various 3rd party extension providers, such as Akeeba.

I am mindful that I don't want to waffle and make this opening ticket too long, so will presume that you guys have some / good knowledge of the impending GDPR from May 25th 2018.

One of the principles is the 'Right to Erasure' otherwise known as the 'Right to be Forgotten' and this has got me seriously concerned at present.

Of course, I utilise Akeeba Backup via CRON, that utilises the .JPS encrypted format and then the backup archive is transported to my Amazon S3 account for safekeeping, employing various Amazon S3 security features also, whilst the data is at rest with them.

So here is the problem and I can't be the only one but need to hear from Akeeba in as technical sense as possible, as I will likely need to include the answer into my site / company's GDPR Policy, dependant upon the answer of course.

[*] I receive a 'Right to be Forgotten' request from a 'Data Subject'.
[*] I implement this request on a given day and time and action it.
[*] This is quite easy to do with the couple of plugins that I'm utilising to facilitate various GDPR related functions, as nothing is built-in to Joomla core for this, as yet.
[*] My site continues to backup with Akeeba and on our schedule is every 30mins.
[*] Say 7 days have lapsed since the previous RTBF request was actioned and completed.
[*] Now my website suffers a malfunction and I need to restore from a previous backup.
[*] The backup is actually one that contains the previous 'Data Subject(s) Personal Data', who wished to no longer be identified in ANY of our systems or processes.
[*] If I restore this hypothetical website data backup and from this particular archive, it will of course also restore the previous RTBF Data Subject(s) and their data.
[*] I could consider trying to locate, dissect and ultimately delete this particular (or any others in the same time frame) Data Subject(s) data again but this is of course likely going to be a hugely tedious and time consuming process.
[*] The main technical issue with the above as I understand it, is that this could have a real negative effect on the underlying stability of my now restored website and data, that utilises the freely open source Joomla Content Management System (CMS), beyond the restore period.

Appreciating that this is very much a grey area at present, as there is still no official line from either the EU or our (UK) Information Commissioner's Office (ICO) on this very issue.

Therefore, would I be correct in assuming, that there is nothing built-in to Akeeba Backup Professional, that can actually make the above kind of use case much simpler and stable?

I look forward to your incredibly important clarification on this matter in due course.

Regards,
Rob

nicholas
Akeeba Staff
Manager
It's impossible to implement something like that in Akeeba Backup. Erasing an individual from your site does not only involve removing the core Joomla! data for that user i.e. the user record and user notes or even all the articles they may have created. It typically also involves removing information you have about them from third party extensions such as e-commerce*, comments, ticket systems, subscriptions* and so on. With thousands of extensions out there and dozens of versions for each extension it's impractical for us to develop a solution which lets you create data retention rules or you to set it up. This would be a massively expensive and complicated system.

* Note that GDPR has exceptions. You are supposed to remove personal information where removing this information is not against the law. For example, our obligation to retain sales information for 10 years (tax code) outweighs your right to be forgotten, therefore no action should be taken with this data. If this data is also linked to the user profile then the Joomla user profile must not be removed either BUT it can be anonymized / scrubbed.

The correct approach is to have an audit log of the GDPR actions you take and reply them when you are restoring a backup. In practice, this is much easier than it sounds. You will not be receiving hundreds of GDPR requests per day. It's more like a few dozen every year. This makes manual compliance on restored backups much cheaper than full automation.

Further to that, Akeeba Backup allows you to restore your site to a staging, development or local server. Therefore, if you have GDPR actions between the backup and the restoration you can restore on a non-live server, apply the GDPR-related actions, back it up and then restore it on top of the live site.

An alternative to that would be the development (by you) of a command line script which takes a source of user IDs and takes predefined actions. Maybe it'd be a bit more complicated e.g. you need a flag whether this is a client you need to retain information for other legal reasons or an individual who can be wiped clean off your site without any side effect. Your mileage may vary (the implementation is always specific to YOUR business). This means that you can replay the entire GDPR log automatically and that can be part of your restoration procedure either manually (when restoring a backup by hand) or automated (when restoring a backup with UNiTE). By using an anonymized source of information (numeric user IDs) you do not run afoul the GDPR regulations.

GDPR is not the end of the world. It merely codifies the existing right to be forgotten. The bottom line is that public information must be removed AND the information of the GPDR subject cannot be used for data processing. For example, when it comes to our site a valid GDPR implementation is: delete all tickets, scrub the username, name and email of the Joomla user record (e.g. username = User123, name = User 123, [email protected]) and lock the account. We still have to keep your invoices and sales records for a minimum of 10 years. Of course this means that if you come back later and tell us "hey, I have invoice 12345 from you" we won't be able to help you since you no longer exist for us. A tax record exists but it's immutable and can't be linked back to your scrubbed user account or your now deleted information.

Regarding keeping backups, I don't see anything in the GDPR which prevents you from storing backups containing personal information as long as you can ensure that this information will not see the light of day (unless it's legally required). GDPR is about blocking access to personal information when the subject requests so. So keeping backups is not a problem as far as I can tell. I am not a lawyer. Ask your lawyer if you're not sure.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!