According to GDPR data subjects may request e.g. information (right of access) about personal data, correction (alteration) or deletion (erasure) of such data.
The question arises, if these rights are applicable only on current data sets, active data repositories or whether backup and offline data is affected also.
For example, after correction or deletion has been executed on active data repositories, would not result the need to apply the according modifications in backups also? Otherwise the requested changes would stay incomplete.
Such procedure may possibly impact safety of IT operations: backups must not be modified otherwise rendered worthless by impacting the main aim of backups: data protection.
We describe how BDSG as well as independently GDPR are covering this issue.
Restore issue
As a result of unmodified backups and archives, a new issue arises: when a restore is performed from a backup that was created before the requested data corrections or deletions had been executed, exactly this undeleted or uncorrected personal data surfaces again as part of active data – clearly violating intentions of the according GDPR articles.
We are proposing a TOM to solve the restore issue.
Overview backups and GDPR & BDSG
Data subjects’ rights are defined in
GDPR Articles 15-18,
We provide analysis based on
BDSG Sections 34 & 35 (German Federal Data Protection Act),
and investigate an independent alternative using only
GDPR Articles 4 & 32
As remedy for the restore problem we describe a
TOM: GDPR compliant restore
GDPR Articles 15-18
According to GDPR the data subject has the right to request
- (Article 15) right of access by the data subject
- (Article 16) right to rectification
- (Article 17) right to erasure
- (Article 18) right to restriction of processing
For example when the data subject requests erasure of his or her personal data, the data controller will execute such deletion (citation:) without undue delay.
BDSG Section 34 & 35
The BDSG (German Federal Data Protection Act) dated 30. June 2017, implements the European-wide GDPR for Germany, adding some interpretations where GDPR allows room for manoeuvre.
Reference for BDSG English translation, link for PDF.
Note: all the predecessor versions were called BDSG also. Therefore, the version from 2017 is sometimes called “BDSG-neu” (neu=new).
Relevant for our discussion are
Section 34 BDSG “Right of access by the data subject”
Section 35 BDSG “Right to erasure”
Here BDSG defines that backups are not considered as data source or modification target when such action would “require a disproportionate effort”. Since backups, once created, are handled by “non-automated data processing”, so performing “erasure would be impossible or would involve a disproportionate effort”. In such case, “restriction of processing” (article 18 GDPR) replaces “erasure”.
The advantage of Europe wide GDPR
While BDSG gives clear advice on backups, it lacks European harmonization. Every member state will have implemented national privacy legislation – but it comes tedious to follow up all of them only to find out about subtle differences.
BDSG rules German companies even when customers are international. It becomes less simple when such company establishes offices in multiple countries – getting impacted by multiple national regulations with potentially fuzzy overlap or contradictions.
GDPR comes for help: a closer look reveals that the backup issue can be solved by GDPR alone.
GDPR Articles 4 & 32
According to GDPR Article 32, “…the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk…”.
In other words: GDPR requests risk adequate IT security and operations.
Important elements in such best practice IT operations are backup and archiving. Backup to restore damaged data near time and archiving e.g. to revert data corruption that went under the radar for the backup period.
Contradicting requirements?
GDPR Article 32 requests risk adequate IT security and operations while data subjects rights require modifying data, thus ripping apart backups and archives?
A closer look at “Article 4 Definitions” may be helpful to prevent damaging backups:
- Paragraph 2 of Article 4 lists alteration and erasure among other actions on data in the definition of data processing.
- Paragraph 3 defines “ ‘restriction of processing’ means the marking of stored personal data with the aim of limiting their processing in the future;…”
Paragraph 2 extends data processing to a comprehensive list including retrieval (of information), erasure, and alteration.
The combination of Article 4, paragraphs 2 and 3 results in requests according to Article 15-18 impacting future processing only, not backups and archives.
TOM: GDPR compliant restore
In case of a restore on backups “old” data could surface, when the backups was originally created before a data deletion request, thus counteracting data subjects’ requests.
TOM (technical and organisational measure)
The solution approach is based on the fact, that a list with all deletions and alteration is available without much additional costs. Such list allows execution of deletions and alterations on the freshly build restore before it is turned into “active” state and so fulfills GDPR requirements.
When alteration or deletion of person related data is requested, a detailed process assures identity and authentication of the requester. It must be guaranteed that the right and rightful person, e.g. the one and only John Allan Smith, is allowed to request deletion of his data – not data of his accidental neighbor John Andrew Smith. Since this process step is to be documented in full detail anyway to proof due diligence, there is no extra effort triggered to create a list of deletions respectively alterations.
This list is made available for restoring a backup and applied on the freshly restored content by executing according deletions and alterations. Only after this step, restored data is made available for intended use.
SME perspective: A sophisticated solution would create maintenance and update effort also during the time it is not needed.
Requests according to Article 15-18 are (still) rare.
Also restores are comparably rare.
The technical implementation could be designed – appropriately to the frequency of restores – in a cost-optimized way: most likely the sysadmin who controls the restore may use tools at hand (e.g. scripts) to apply the deletions. Such procedure would be tested and documented in all necessary detail and added to the description of the TOM.
Enterprises and those companies where - due to the type of business - customer requests based on GDPR articles 15-18 are frequent, cannot avoid to implement application of deletion and corrections to restored backups as a (semi-/fully-)automated process.
Links
[1]: Article 15: Right of access by the data subject
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2513-1-1
[2]: Article 16: Right to rectification
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2599-1-1
[3]: Article 17: Right to erasure
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2606-1-1
[4]: Article 18: Right to restriction of processing
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e2700-1-1
[5]: BDSG-English-translation HTML
http://www.gesetze-im-internet.de/englisch_bdsg/englisch_bdsg.html
[6]: BDSG English PDF
https://www.gesetze-im-internet.de/englisch_bdsg/englisch_bdsg.pdf
[7]: Section 34 BDSG
http://www.gesetze-im-internet.de/englisch_bdsg/englisch_bdsg.html#p0294
[8]: Section 35 BDSG
http://www.gesetze-im-internet.de/englisch_bdsg/englisch_bdsg.html#p0304
[9]: Article 32: Security of processing
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e3383-1-1
[10]: Article 4: definitions
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#d1e1489-1-1