GDPR – in principle

privacy data protection
GDPR is being instantiated into UK law and will come into effect on 25th May 2018. Will you be ready? Do you understand what not being ready could mean?

The Principles and Practicalities of the GDPR

The General Data Protection Regulation is currently being adopted into UK Law and will become enforceable from May 25th 2018.  GDPR aims to harmonise and toughen minimum standards for protecting personal information across the European Union and the countries with which Member States do business.  Brexit, whether hard, soft or any other variant, will not affect the introduction of these regulations. Any state that wishes its businesses, public sector or third sector organisations to be able to share personal information with counterparts within the EU must have laws “at least as stringent” as the GDPR.

Trying to assess how businesses and other organisations need to approach the task of ensuring that they are compliant with this new law before it becomes enforceable has generated a huge amount of debate across the privacy and information security communities.  Personally and professionally, I am concerned at the volume of negative and doom-laden material being circulated under the cover of “advice and guidance”. So here, I presume to offer a  few practical insights into how you might interpret the key principles of the GDPR and create an achievable action plan for delivering compliance.

  • Principle I: Personal Data must be processed fairly, lawfully and in a transparent manner in relation to the data subject.
  • Principle II: Personal Data must be collected for specified, explicit and legitimate purposes and not processed in a manner which is incompatible with those purposes
  • Principle III: Personal Data must be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed
  • Principle IV: Personal Data must be adequate and where necessary kept up to date
  • Principle V: Personal Data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed
  • Principle VI: Personal Data must be processed in a manner that ensures appropriate security of the personal data including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage using appropriate technical or organisational measures

Lawfulness

The first principle is simply expressed and looks easy to interpret.  Article 6 of the GDPR specifies the conditions which much be satisfied in order for processing to be lawful and the definitions could not be clearer:

  • The data subject MUST have given prior consent.  Taking Principle II into account, that consent must relate not only to the information you hold but the processing you perform on that information;
  • Processing must be NECESSARY for the performance of a contract between the data subject and the data controller;
  • Processing is NECESSARY for compliance with the data controller’s legal or regulatory obligations;
  • Processing is NECESSARY in order to protect the vital interests of the data subject or another natural person;
  • Processing is NECESSARY for the performance of a task carried out in the public interest when exercising an official authority vested in the data controller;
  • Processing is NECESSARY for the purposes of legitimate interests pursued by the data controller, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.

The term NECESSARY is emphasised because we need to differentiate between processing of personal information that we must do and processing (e.g. profiling or analysis) that we would LIKE TO DO.  Where you cannot fulfil your contractual obligations or other conditions without processing personal data, then you are permitted to do so, but in all cases you MUST have consent.

Consent

Consent has been a hot topic of discussion for Chief Information Security Officers and Data Protection Officers, especially when it comes to using personal contact information for sales and marketing purposes.  So, an additional element of the GDPR relates to the question of whether a data subject must be asked to “opt in” to receiving communications.  Simply put data subjects must provide prior, explicit consent to receive SMS or email communications for sales and marketing purposes. They must also have the ability to “opt out” of receiving telephone calls or hard copy letters through the post.

So, if your job is in business development and you have collected a contact list of potential prospects, you are permitted to write letters to them or telephone them without breaching the GDPR, as that would be a legitimate interest for your company.  There are ongoing discussions across the industry about the business of purchasing contact lists, and the collators of such lists will need to ensure that they have obtained the proper consents from all data subjects.  As a purchaser of a contact list, you wold not be well advised to assume that such consents have been sought or obtained before you use them.

A further consideration is that the data subject must have the ability to withdraw consent at any time (with constraints of course) and so as a data controller, you have the obligation to maintain auditable records of what data subjects have consented to historically as well as currently.  This means that after a data subject has withdrawn consent you must still be able to prove that at the time you communicated with them, you had their consent to do so even though that consent has been subsequently withdrawn.

Acceptable Use of Personal Data

Principles II-IV elaborate on the boundaries of what is acceptable in terms of the personal information data controllers hold on data subjects.  We must ensure that we only hold and process the minimum set of information required for the purposes for which we have consent.   We must have explicit consent from each data subject for each form of processing for each piece of personal information.  Data subjects must be able to view and, where appropriate, correct the information we hold about them and we must absolutely not perform any processing, which includes analysis, even anonymised analysis, of personal information for which we do not have consent.

Time Limits

Principle V requires us to establish the maximum time we need to hold personal data in a form which allows the identification of the data subject for each form of processing we perform.  When that period has elapsed, we are required to either securely delete the personal data set completely or ensure that the information we retain cannot be linked to the actual data subject.  This allows data controllers to retain raw data for long-term trend analysis and so on, just so long as the information retained is anonymous.

Just in case that wasn’t entirely clear: it is your responsibility to ensure that you (a) have the data subject’s consent to hold their anonymised data for future analysis and (b) to ensure that there it it not possible for the anonymised data to be linked back to the data subject.  Failure to make either provision would be a clear infringement of GDPR.

Principle VI reinforces existing data protection law and effectively gives legal strength to good information security practice, requiring data controllers to ensure that personal information is adequately and appropriately protected from misuse, loss, destruction or damage.

Applying the Principles in Practice

Where do you start?  As with asking for directions in Ireland, the chances are you would not wish to be starting from wherever you currently are.  But as every programme manager and consultant will gladly remind you, we are where we are so we best get on with it.

In the interests of starting with the end game in mind, envision if you will a situation where you have the ability to consult a database (preferably with visualisation capabilities) which would show you where your repositories of personal data were physically located and which systems/applications made use of them.  This should also be able to show you, in some meaningful way) what technical and managerial security measures protect each such store and what processing the systems and applications perform.

It would also be useful to be able to call up details of who has access to these applications and systems and whether the information can be accessed any other way. Naturally, and given what went before you won’t be surprised by this, I would hope to be able to identify which data subjects have provided current and/or historical consent for us to process their personal data – including the explicit details of the consent provided.

An Example – based on a true story

Step One

Taking the example of a data controller with a medium- to long-range roadmap, a few in flight programmes and a number of legacy systems, where would you start.

I recommend starting by embedding the GDPR requirements into the roadmap for future systems and applications.  The reason for this being that Article 83 states that in the event of a personal data breach, “fines should be effective, proportionate and dissuasive” and stipulates that due consideration should be given to (amongst other factors) the “nature, gravity and duration of the infringement” and the “intentional or negligent character of the infringement”.  My interpretation of these last strictures is that if, knowing of the existence of GDPR and the data of enforcement a data controller knowingly commissions a new data processing application, system or service without incorporating the requirements of GDPR, that data controller would most likely to be found to have been negligent

What will the ICO’s Stance be?

Expect opinions vary as to whether the Information Commissioner’s Office will take a hard or soft line when it comes to imposing fines for infringement. Whichever is the case, data controllers need to be aware not only of the potential for fines, but also of the fact that all affected data subjects will be eligible for compensation, regardless of whether they have been materially damaged by the infringement.

Step Two

Secondly, I would seek to include, retroactively, those requirements into the in-flight programmes to the greatest extent possible.  For programmes in the early stages of analysis and design, full incorporation of the GDPR requirements should be a priority.  Where significant process has already been made, requirements should be built into the roadmap for future releases and where specific requirements cannot be incorporated into the deliverable, additional management controls should be considered as essential to ensure you avoid the accusation of negligence.

That brings us to the legacy estate, which in all cases of new legislation, regulation or just new business requirements is the biggest concern.  The older a system or application is, the less easy it will be to retrofit new requirements, especially requirements as broad and deep as those of the GDPR.  Sadly, I cannot offer a panacea or magic bullet solution to this, each system will need to be reviewed and a cost/risk/benefit case developed to determine the most appropriate course of action for the data controller to take.  In many cases, additional organisational and access control measures may be sufficient to reduce the GDPR infringement risk until a legacy system is retired or replaced, in other cases, re-engineering may be required.

Questions to ask yourself

When reviewing your existing information security controls beyond the specific data protection and privacy measures discussed above, I would recommend posing four questions:

  1. Are all personal data adequately protected against risks liable to result in an infringement?
  2. If an infringement was to occur, could we identify that it had happened and identify affected data subjects in a timely manner?
  3. Do we have a proven response capability to manage the impact of a breach of personal data security arising from an infringement, including notifying affected data subjects and the Supervisory Authority?
  4. Do we have a proven capability to recover from a breach of personal data security such that the long-term viability of the organisation is not compromised?

The Rights of the Data Subject

One of the key features of the GDPR is the clarity it brings to data ownership – that being that the data subject owns their data, as data controllers and data processors, we are custodians of that data and need to act accordingly.  The terminology, a rarity for legislation, in this regard is very clear and unambiguous, namely that the data subject has the right to:

  1. be informed of what information you hold and why
  2. access to that information in its entirety (with some exceptions in the cases of protection of vulnerable individuals, crime prevention, law enforcement and national security)
  3. rectification of any errors or inaccuracies
  4. erasure of some or all of the information you hold
  5. restrict processing to that to which they specifically and explicitly agree
  6. control data portability outside of the EU
  7. object to any or all of the uses to which you put their data
  8. be excluded from automated decision making and profiling

The UK Information Commissioner’s Office has issued guidelines to the effect that if you cannot demonstrate that these rights are fully embedded in your systems and management controls, you should either stop or not start processing of the personal data you hold.

Where to start?

Whether you act as a Data Controller or a Data Processor, the GDPR applies to you and all of the personal data you capture, store, process and disseminate, regardless of whether the data exist in electronic form or any other medium.  Any information that falls within the definition of sensitive personal data needs additional protection, but more of that in due course.

The following activities will need to be carried out in order to determine what you have, why you have it, how you use it and whether you are compliant with the GDPR legislation.  The scale of each activity will, of course, vary according to the scale and complexity of your organisation and business processes.  In all cases, you need to ensure that the scope includes personal and sensitive personal data relating to staff, suppliers and customers as each individual is a data subject with rights.

  1. Identify all instances of Personal and Sensitive Personal data being captured, stored, and processed, including purpose
  2. Identify all instances of Personal and Sensitive Personal data being transmitted internally or externally, including recipient and purpose
  3. Identify processes for data subjects to verify, update and/or request deletion of Personal or Sensitive Personal data
  4. Assess GDPR compliance status of each identified instance of Personal and Sensitive Personal data being captured, stored, processed and transmitted
  5. Assess information security management controls and processes against the GDPR principles
  6. Identify opportunities for data rationalisation & process improvements

If you are unsure if how to proceed, I am here to help, so get in touch with us today.

Versions of this article have also appeared on the Perspective Risk and TrackBack websites.

 

Leave a Reply