July 27, 2017,
EU General Data Protection Regulation, Legal update, News, Thought Leadership 
No comments
One of the most important and fundamental principles of data protection under Regulation 2016/679 (GDPR) is the Principle of Minimisation. Arguably, it’s the one principle can help satisfy the need to manage security, data protection and privacy objectives, especially with respect to the Internet of Things (IoT).
Under Art.5(1)(c), GDPR, the Data Controller must ensure that ‘processing of personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.’ This is about ensuring that staff are only processing personal data in accordance with the purposes and once these have been satisfied, it’s safest to delete this personal data unless other legal grounds exist to hang on to it.
But the Principle of Minimisation is getting overlooked as organisations struggle to cope with implementing other organisational and technical measures under the GDPR.
Part of the problem is the legacy of the past 20 years. Organisations are great hoarders of data and love to create big ‘data lakes’ based on the idea that more data, once analysed, will unlock countless new revenue opportunities never dreamt of before.
Yet the stark reality is that a feeble 13% of all UK companies feel they have mastered the knowledge in how to leverage the value of this stuff. But that hasn’t dampened their enthusiasm to hoard vast amounts of personal identifiable information.
In the forthcoming Journal of Data Protection & Privacy, technologist and co-founder of Krowdthink, Geoff Revill writes: “Data Minimisation underpins the principles of both Privacy by Design and Security by Design. As the GDPR calls for greater attention to both implementation processes then it makes sense to focus on this common aspect of both. This is risk mitigation in action. The less personal data to manage, the simpler the consent process will be and the more readily PII risk to the business can be quantified.”
One of the fundamental rights of the Data Subject is Art.17, GDPR – the Right to Erasure (Right to be Forgotten).
In the explanation notes, Recital 65 explains: “A Data Subject should have the right to have personal data concerning him or her rectified and a ‘right to be forgotten’ where the retention of such data infringes this Regulation or Union or Member State law to which the Data Controller is subject. In particular, a Data Subject should have the right to have his or her personal data erased and no longer processed where the personal data are no longer necessary in relation to the purposes for which they are collected or otherwise processed, where a Data Subject has withdrawn his or her consent or objects to the processing of personal data concerning him or her, or where the processing of his or her personal data does not otherwise comply with this Regulation.”
The right to have personal data deleted creates significant challenges for the Data Controller. For example, ‘delete’ in cloud storage and in most database management implementation doesn’t actually mean delete. Rather it’s interpreted as ‘hide’.
Since 2011, it’s been cheaper for cloud services to sustain personal data in storage than to get rid of it. This is because a real delete includes two key steps:
- an eventual re-indexing of the database that can be an enormously time consuming exercise and a service off-line issue
- a purge capability of backups to ensure that deleted personal data isn’t restored in a database recovery situation.
Conscious of their new legal responsibilities under the GDPR, Data Processors (cloud service providers) are beginning to offer real delete, but the default is to hide. Additional steps are required to achieve a real delete, argues Revill.
“If your designers build their own database management architecture, then they tend to default to hide, not least because when an exec says delete and something then changes his mind, they expect techie magic to happen and for the data to be recovered.”
At the heart of the issue is organisational culture that in most cases is pretty hard to change but must shift in order to create an environment of compliance with the new rights and freedoms of Data Subjects under the GDPR.
This means both Data Controllers and Data Processors must re-boot their thinking about data protection and privacy.
It’s about the Data Controller and the Data Processor learning to be the custodian of personal data and trusted to process it and this privilege can be withdrawn at will of the Data Subject in accordance with conditions set out in the GDPR.
Amazon, Facebook, and Google will have their work cut out as they’ll have to change their business models and organisational culture in order to be compliant with the GDPR. Or suffer the consequences.
The IoT adds a new dimension to this issue, if personal data is collated or cached at the edge. How is this going to be deleted?
This must be addressed at the design stage but it also needs to be explicitly considered and addressed at an early stage of development.
It can’t be an afterthought as it can’t be easily addressed later and will also infringe Art.25 Data Protection by Design and by Default, another part of the GDPR that’s important to factor into the workflow over the next 200 working days before the GDPR becomes fully enforceable across 28 EU Member States.
For information about the GDPR Transition Programme at Henley Business School, click here.
Recent Comments