The right to erasure is sometimes also known as ‘the right to be forgotten’. It enables an individual to request the deletion or removal of personal data where there is no compelling reason for its continued processing. This right is contained in Article 17 of the GDPR that states that data subjects have the right to have their personal data removed from the systems of controllers and processors. These entities must comply, without “undue delay”, and at no cost to the requesting party.
Remember that the burden of compliance record keeping is on the organisation to show that it has considered the rights of data subjects. This includes being able to show in the best way possible that you recorded the fact that you erased certain information. To comply with GDPR, an erasure system must be auditable and having a business process that is triggered in to remove the data is part of this evidence.
Step 1 Does the data need to be erased?
The rules surrounding the right to erasure including when they apply and the circumstances under which it can be refused are not cut and dried in every case and for every business, so the first thing to do is to ascertain which rules apply in your situation. Further guidance on the rules are detailed here (UK ICO Guidelines)
Data subjects are also entitled to a copy of their own data under the data portability regulation and it should be checked whether a copy is required to be sent before erasure.
The business and the data protection officer should firstly review the regulations to assess the conditions under which this right applies.
Step 2 Work out where all personal data resides.
An assessment must be made of what can be, should be, can’t be, and is infeasible to be erased. Trace data movement that takes place, internally and externally, to help define the affected locations. Mapping this can include inputs system diagrams, database tables, business process and data flow diagrams.
Some personal data sets are impossible or infeasible to edit to remove individual records. This includes server backups, transaction logs or audit records. Whilst these non-editable data sets are in-scope of the erasure right, themselves they may be out-of-scope for erasure editing procedures due to their immutable nature.
Personal data that is encrypted also needs to be removed as part of this right. Under the GDPR there is a stronger case for using data encryption to protect privacy. When data is processed systems need to decrypt data, so having an erasure process will also simplify removal as only the source encrypted record needs to be removed to prevent processing.
The overall aim is to determine the scope of the erasure.
Step 3 Evaluate subject data in Transactional and online systems
Prioritise the removal of data from the primary online and publicly facing systems. This not only ensures that when data is removed it will be apparent, but the change will also be propagated to any replicated, failover and mirrored systems automatically.
Special attention should be paid to any Cloud based data stores and ensuring that the geo-replication features of such systems will replicate the deletions also.
Attention should also be paid to any applications that hold and actively cache the subject’s data to ensure that they are purged.
This ensures that the primary systems that hold the personal information are correctly changed and pass forward the changes to any dependent or contingency systems.
Step 4 Evaluate Source data, Reprocessed and Extracted Data systems
Some systems, most notably Business Intelligence (BI), Machine Learning (ML) and Artificial Intelligence (AI) systems rely on sources of data from primary collection systems, including bulk data extracts, custom SQL queries, help desk and customer support records. For BI systems it may be necessary to check the logic embedded in ETL data loading packages, and for ML and AI systems the logic for the extracts used to train the systems will be needed. If any of these extracts contain personal data, then they will also be within scope for record erasure.
Some Business Intelligence systems are reloaded fully each night. Ensure that the extracts and backups used to do this are up to date.
Other systems that rely on automated feeds from primary systems, for example CRM and marketing automation extracts will need to be cleansed, especially when the information that is passed to them is a delta update of previous extracts.
Check all contingent systems to ensure that erased records are not re-introduced as a result of the loading procedures.
Step 5 Evaluate Non-automated and Third Party systems
Some organisations rely on non-automated systems to process and utilise personal data. This includes, spreadsheets, word documents and shadow data stores. For example, if marketing information is being sent out from a spreadsheet then the logic underlying this information will need to be verified. The right of erasure also applies to scanned document systems that are utilised in processing. The relevant documents should be deleted or archived so that they are no longer actively in use.
The GDPR also reinforces the right to erasure by clarifying that organisations in the online environment who make personal data public should take ‘reasonable’ steps to inform other organisations who process the personal data to erase links to, copies or replication of the personal data in question. This includes third parties such as marketing firms, system suppliers and partner organizations.
A thorough assessment of data usage within and transfer beyond the organisation is needed to ascertain if personal data is being further processed.
Backups and Archives
It’s backed up, and therefore not processed, but remember that problems might occur if you restore from backup. Always perform full back ups as soon as possible after erasure to ensure the integrity of data. Archiving systems also fit into the not processed bracket, and so are generally excluded from the right to erasure, as long as you don’t try to keep backups for ever, or to archive everything.
Where there is a legal requirement to hold a certain number of years as a record (Banking regulations require 7 years for audit purposes.) the right of erasure does not apply to these systems.
Take a precise and measured approach to maintaining the integrity of your data. The technical challenges associated with right to erasure present an interesting problem for systems administrators and data professionals. Filling up databases and maintaining data integrity is part of the day job, but actively (and correctly) erasing from live databases can present particular headaches, especially in heterogeneous and interconnected systems.
If you have highly distributed personal data you may want to take a federated approach by architecting individual services that “sit on top of” the distributed data stores, providing erasure and auditing functionality compliant with GDPR. Master Data Management (MDM) tools can assist in this task.
Awareness training and education on the right to erasure for staff involved in maintaining data integrity and using it in external communications will also help to ensure that requests are propagated through the organisation.
For anyone interested in this subject, I’ve written up some more specific advice on web server logs and GDPR compliance, including how you can use the logrotate utility to easily implement log encryption and erasure .
LikeLiked by 1 person
Great post Daniel, web logs and other devices that store IP addresses need extra consideration. Thanks for contributing!