GDPR: When is the Right to be Forgotten applicable?

25 May 2017
Written by Paul Hammersley

As Senior Vice-President of the ALM Products at EPI-USE Labs, Paul Hammersley's portfolio includes test data management, landscape optimisation, and archiving. He has been a remarkable technical force in the SAP arena for over 20 years, and has extensive hands-on experience of implementing Data Sync Manager (DSM) and helping clients to manage data across the breadth of their SAP landscapes.

I’m watching a wonderful programme at the moment where the opening credits state ‘This is a true story’; then the word ‘true’ disappears a few seconds before the others. Then it follows with something along the lines of ‘the story not being changed to honour the victims, but the names have been changed to protect the innocent’. Strange how the core subject of my days at the moment has morphed into my evenings as well.

My awareness of GDPR started well over a year ago now, with Article 17 – the Right to Erasure (‘Right to be Forgotten’) – although at the time I didn’t know that was exactly what it was. Reading the Article in more detail (by the way, if you didn’t read my previous blog - I am not qualified to give legal advice, and this should not be construed as such), it seems very difficult to pin down exactly when it is applicable.

There are six grounds where it can apply. To me, the two most powerful seem to be:
‘the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed’
and
‘the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2)’.

The first one isn’t clear to me; could that mean any historical data? I mean, a delivery address is not needed after you’ve delivered something. If you’re talking about something delivered 20 years ago, we’d probably all agree that that should count. But 20 mins ago, it should not. So when does it go from not applying to applying?

The second one falls off a cliff after four words. In order to know whether the data subject can object, you need to check Article 21 (Right to Object), which then in turn refers you to Article 6 (e) and (f) (Lawfulness of Processing). The wording of Article 6 (f) is:-

‘processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child’.

Which to me sounds like the Right to Erasure is there if someone has the Right to Object (and does object), because the Right to Object is based on the lawfulness of processing; one grounds of which is overridden by the rights of the data subject, such as the Right to Erasure….

I think we can all agree that this clearly isn’t legal advice I’m dispensing...that much I am sure of. What I have fathomed is that a company must be able to indicate lawful grounds from the options in Article 6, and based on which one they go for, someone could look to exercise their Right to be Forgotten.

So how liberally will companies give the Right to be Forgotten? This still isn’t clear. I guess it will depend on analysis and qualified legal advice.

Don't know where to start with GDPR and SAP? We do!

 

 

Explore Popular Tags

GDPR Data Privacy Data Security Data Secure GDPR compliance Data Redaction data scrambling Data Redact General Data Protection Regulation POPI Act POPIA SAP Data Security SAP GDPR SAP data privacy and compliance Data Archiving Data Sync Manager Data privacy regulations Right to be forgotten Data privacy compliance GDPR readiness GDPR deadline Personal data SAP SAP security SAP systems GRC for SAP SAP data privacy and security Access Risk management Access risk controls Data Privacy suite Data minimisation Data security breaches Governance, Risk Management and Compliance (GRC) compliance COVID-19 Data privacy by design Risk monitoring SAP data copying and masking SAR Soterion Subject Access Request anonymised data Australian Privacy Act 1988 CCPA Cenoti Client Sync Data Protection Day Data masking EPI-USE Labs’ solutions European operations Federal Law GDPR fine Guest order ICO May 2018 Object Sync One-time customer Privacy by Design Reducing risk Right to Erasure Risk minimisation S/4HANA Migrations SAP S/4HANA SAP data SAP data privacy & security Secure scrambled production data for testing Test Data Management security breach Backlog privacy debt Black Friday Black Friday hangover Black Friday sales Breach Notification Brexit Budget Canada data privacy legislation Cenoti, connecting SAP with Splunk Cloud migrations Confidentiality Consent DSM DSM Readiness Assessment Data Diclose Data Portability Data Removal Data Replication Data Sync Manager (DSM) Data integrity Data privacy assessment Data processor versus controller Data retention rules Documentation Employee data Europe Friday 25 May 2018 GDPR-type legislation GRC GRC for SAP tools General Data Protection HCM HR ILM Information Commissioner’s Office Information transfer Infotype 41 JSOX New Zealand Privacy Act News Online shopping Penalties Personal Data Protection Law (PDPL) Phantom Proportional Data Protect personal employee data Removing data in SAP Right to Access Rise with SAP Risk management S4HANA SAP Cloud SAP Data Privacy Suite SAP RISE SAP SuccessFactors SAP access risk simulations SAP data encryption SIEM SOX Sarbanes-Oxley (SOX) legislation Saudi Arabia Security Security Information and Event Management Security for SAP. Live Sensitive HCM data South African data privacy legislation Splunk Splunk UBA Splunk’s Enterprise Security Success Factors Territorial Scope UK Government User Access Review Virtual conference What does the European GDPR mean for Australia? ebook masking rules quality of test data system copy uk sox
+ See More

Get Instant Updates


Leave a Comment: