GDPR: Myths and Unusual Consequences
by Rafael Bloom, Business Development Director, Arkivum
Rafael Bloom, business development director at Arkivum, writes on Data Economy’s end of year special about GDPR set to come into force in 2018.
Over the last few months there has been a proliferation of blogs and articles concerning the General Data Protection Regulation, GDPR. Most have echoed the same points as the others, and so while it is interesting to hear via Symantec that 96% of companies still do not understand the GDPR, it would seem that the deluge of content is not causing any changes on the ground.
I would like to discuss some of the more interesting or unusual aspects which have been revealed and which urgently demand attention.
Clearly there has not yet been a compelling event worthy of consideration by the bulk of businesses as a definitive trigger for change.
Because the time limit for adopting new practices is by May 2018, the fact that the GDPR represents a clear model for best practice is irrelevant until things start to hurt – i.e. until some unfortunate institution is fined a significant sum, and named in public for having taken such poor care over the personal data in its possession.
When considering the practical consequences of GDPR, there are many aspects under the spotlight, including the way in which data is collected, stored and managed; the control of access permissioning, guaranteeing data portability and much more besides.
Businesses and institutions will need to demonstrate effective governance over all data they retain on their systems. One of the top-level requirements of the GDPR concerns the use of a contact database to trigger email marketing.
Unambiguous, opted-in permission from the individuals concerned is obligatory, which is a headache of course, but speaking as an individual under these regulations I would agree this step is overdue and will be a major long-term benefit to all parties, except those wishing to abuse personal data, such as email spammers.
Another angle to consider, and one which isn’t highlighted as often, is the individual’s ‘right to be forgotten’. To take an example from the emerging field of genomics, what more personal data could there be than a record of ones genome?
Under the right to be forgotten, someone could ask for their personal data to be purged from the records. Normally that would mean anonymising the genome file so it can no longer be associated with that individual.
Erasing the genomic data itself may not be an option, for example if it is being used in a study. So while the personal details of the person concerned are purged, there remains a possibility of the genomic sequence itself being used to identify people, using genetic factors which might even be private under the normal definition of the term.
Clearly there are limits to the ability to protect individual rights, and this also needs to be taken into consideration.
Where the most time will be spent related to GDPR is likely to be the ongoing management of the growing volume of personal data being generated.
Once the GDPR is in force, data audit trails will become obligatory, encompassing all personal data from when the data was first retrieved, the permission that was gained for businesses to hold the data, when it was entered on to the system and accessed, and by whom, and with whom it is shared.
If a person then unsubscribes, the audit trail will need to show that request being made, received, and implemented within the document management system, and adhered to.
It is a given that the use of software packages is an integral part of today’s workflows. What is not a given is the approach of software publishers towards the longevity and support for the data outputted by the software in question.
In terms of recordkeeping, this could mean anything from an Excel spreadsheet to a metadata database of bespoke design, or an audio file of a recorded conversation. If the individual data subject wishes to exercise their rights over their personal data, this could create problems.
Some software publishers take the approach of deliberately creating data output formats which cannot be read outside of that company’s software ecosystem, measures intended to generate ‘stickiness’ for their products.
In addition, they might charge exorbitant rates for the use of the proprietary API or data extraction tools which are needed to exploit the data to its full extent. What is to be done if software providers effectively hold private data to ransom, meaning the data cannot be extracted, exported and understood by others unless the keys to the data are paid for at great cost?
Built-in restrictions like these prevent companies from doing what they wish with the data that they own, and therefore this constitutes a significant business or institutional risk when it comes to compliance with GDPR and other regulatory pieces like MiFID II.
Data Sovereignty in the Cloud
Where the data is stored is also a key factor. Matthew Addis, Arkivum CTO, commented “If you are storing data with a cloud software provider, there are a number of things to consider.
Firstly, from the moment your data goes into the cloud you typically allow the provider to take responsibility for how the data is stored, protected and accessed.
The risk is that you now have to trust the provider and their infrastructure, staff, policies and procedures. Often, there is little or no visibility of where the data is, who could potentially have access to it and how secure it is. This is not to say that cloud providers aren’t trustworthy – in most cases they do a great job.
It is rather that there are now new risks that need to be managed, due diligence to be put in place, and GDPR requirements on data processing to be met.”
As far as big data is concerned, there are plenty of other compliance and regulatory needs that institutions must to be aware of per industry sector. As a result of this growing compliance and regulatory pressure, some organisations are starting to appoint Data Protection Officers (DPOs) whose role it is to protect the organisation against unexpected data risks.
They make sure that when data is being shared that it is either pseudonymised or anonymised. They also need to understand the long-term technical and organisational requirements to enforce the specific actions that the firm needs to exercise over data. In the end, checking data to make sure that it is compliant should become part of the overall lifecycle management of the data and should therefore be carried out as an ongoing process within an organisation’s DNA.
The GDPR Brexit Myth
Any debate over whether or not GDPR will affect the UK is a waste of time. When Prime Minister Theresa May announced that she would commence the Brexit process by the end of Q1 2017, it means that the UK is likely to leave the EU only in mid-2019, which is after the GDPR comes fully into force.
It is abundantly clear that GDPR will be part of UK law until such point that the government decides to repeal some of the EU laws which apply in the UK, which will take yet more time.
‘Brexit means Brexit’, but it is unthinkable that when it happens, bilateral trade and the cross-border marketing of goods and services with the EU block will cease at that precise moment.
Whilst the decision to leave the EU has long-term implications for the legislative framework in the UK, these will not affect the need for organisations to adopt the General Data Protection Regulation (GDPR).
The fact remains that the UK is going to continue to do business with Europe, and vice versa. In order for British businesses to share information and provide services for EU consumers, the law has to be equivalent.
Therefore even if the EU’s GDPR code no longer applies directly to UK institutions, the state of affairs will be maintained by making the relevant articles of UK law a virtual mirror of the EU’s.
 Symantec, State of Privacy Report 2015