The Principles and Practicalities of the General Data Protection Regulation

The Principles and Practicalities of the General Data Protection Regulation

Taking a Pragmatic Approach to the GDPR

Want to check how good your organisation’s security is? Click here.

The General Data Protection Regulation aims to harmonise and toughen minimum standards for protecting the personal information of EU citizens. It applies to any organisation doing business with EU member states, regardless of where it’s headquartered.
Brexit, whether hard, soft or any other variant, will not affect the introduction of the regulations.
Establishing how commercial, public and third sector organisations approach compliance with the new law in time for May 25th 2018 has generated huge debate, not least among the privacy and and infosec communities.
At Perspective Risk, we are concerned over the volume of negative and doom-laden material circulating under the cover of ‘advice and guidance’. Here, we offer practical insights into how you might:

  • Interpret the key principles of the GDPR
  • Create a practical plan for reviewing your information stores and systems
  • Determine the work to be done

Let’s first look at what the key principles are regarding Personal Data:

I: Processed fairly, lawfully and in a transparent manner 

II: Collected for specified, explicit and legitimate purposes and not processed in a way which is incompatible with them 

III: Adequate, relevant and limited to what is necessary for processing 

IV: Where appropriate, kept up to date

V: Retained in a form which permits identification of data subjects for no longer than needed    

VI: Processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing, accidental loss, destruction or damage

The first principle is clearly expressed and looks simple to interpret. Article 6 specifies the conditions which much be satisfied lawful processing. 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 way you process it, which should be necessary for:

  • The performance of a contract between the data subject and the data controller;
  • Compliance with the data controller’s legal or regulatory obligations;
  • Protection of the vital interests of the data subject or another natural person;
  • The performance of a task carried out in the public interest when exercising an official authority vested in the data controller;
  • The legitimate interests pursued by the data controller, except where they 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 we must do and what we would like to do (e.g. profiling or analysis). Where you are unable to fulfil your contractual obligations or other conditions without processing personal data, then you’re permitted to, but in all cases you must have consent. See also Principle II.
Consent has been a hot topic for Chief Information Security Officers and Data Protection Officers, especially in the context of using personal contact information for sales and marketing purposes. One aspect of the GDPR relates to the question of whether a data subject must opt in to receive communications. In a nutshell, you must obtain data subjects’ prior and explicit consent for sales and marketing SMS or email communications.
If your job is business development and you have accumulated a contact list of potential prospects, you are permitted to write or telephone them without breaching the GDPR, as that would be a legitimate interest for your company. However, you have to make it easy for them to opt out of such communications. For example, include a pre-paid return envelope for stopping further postal communications and a user-friendly process to cease calls.
There are ongoing discussions across the industry about the business of purchasing contact lists, and the collators of such lists should ensure that they have obtained the proper consents from all data subjects. As a purchaser of a list, you would be well advised not to assume that such consents have been sought or granted.
A further consideration is that the data subject must have the ability to withdraw consent at any time (with constraints of course). Consequently, in your role as a data controller, you have the obligation to maintain auditable records of what the data subjects have consented to historically as well as currently. This means that after a data subject has withdrawn consent you should be able to evidence that at the time you communicated with them you had it, even though it’s since been withdrawn.
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 hold and process only the minimum set of information required for the purposes we have consent for. We must have explicit consent from each data subject for each form of processing of 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, and even anonymised analysis, of data for which we do not have consent.
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 element of processing. Once that period has elapsed, we are required to either securely delete the data set completely or ensure the information retained can’t be linked to the actual data subject. This allows data controllers to keep raw data for long-term trend analysis, as long as the information is anonymous.
To be 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) ensure that it is not possible for the it to be linked back to the data subject.
Failure to make either provision would be a clear infringement of the GDPR.
Principle VI reinforces existing data protection law and adds legal weight to good information security practice. It requires data controllers to ensure that personal information is adequately and appropriately protected from misuse, loss, destruction or damage.

Want to know more? Get in touch with one of our experts today

Applying the Principles of the GDPR in Practice

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

Begin with the end game in mind and envision if you will a situation where you have the ability to consult a database (preferably with visualisation capabilities) which would show where your repositories of personal data are physically located and which systems/applications make use of them. It would also display what technical and managerial security measures protect each repository and what processing the systems and applications perform.

You would have the ability to call up details of who has access to the applications and systems and whether the information can be accessed any other way. You would also be able to identify which data subjects have provided current and/or historical consent to process their personal data, including the explicit details of the consent provided.

Taking the example of a data controller with a medium to long range road-map, a few in-flight programmes and a several legacy systems, how would you approach this ideal?

As a first step, and to prevent unnecessary pain later down the line, we recommend embedding the GDPR requirements into your road-map for future systems and applications. The rationale for this is 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 (among other factors) to the “nature, gravity and duration of the infringement” and the “intentional or negligent character of the infringement.

Our interpretation of these last strictures is that by commissioning a new data processing application, system or service in the full knowledge of the GDPR but without incorporating its requirements, the data controller would likely be found negligent. So, whilst you may have a job on your hands with some of your existing arrangements, you can more easily build in what the ICO term ‘privacy by design’ for all future data processing systems.

Expert 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 that all affected data subjects will be eligible for compensation, regardless of whether they have been materially damaged by the infringement. Yes, deep breath, you read that right…

Secondly, we recommend that you retrofit the requirements into your 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 work has already been done, they should be built into the road-map for future releases. Where they cannot be incorporated into the deliverables, additional management controls should be viewed as essential to avoid the accusation of negligence.

This 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 is to retrofit new requirements, especially those as broad and deep as the GDPR. Sadly, we cannot offer a panacea or magic bullet solution for 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.

The GDPR: Questions to ask yourself

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

1. Is all personal data adequately protected against risks liable to result in an infringement?

2. If an infringement was to occur, would we know it had happened and could we identify the data subjects affected in a timely manner?

3. Do we have a proven response capability to manage the impact of a data breach, including notifying affected data subjects and the supervisory authority?

4. Do we have a proven capability to recover from a breach so that the long-term viability of our 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 the data subject owns their data. As data controllers and data processors, we are the custodians of the information and are obliged to act accordingly.  The terminology, a rarity for legislation, is clear and unambiguous, namely that the data subject has the right to:

1. Be informed

2. Access

3. Rectification

4. Erasure

5. Restrict processing

6. Data portability

7. Object

8. & Rights in relation to automated decision making and profiling

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

The GDPR: Where Best to Begin?

Whether you act as a Data Controller or a Data Processor, the GDPR applies to you and all the “personal data” you capture, store, process and disseminate, regardless of whether it exists 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 a future blog.

The following activities should be carried out to determine what you have, why you have it, how you use it and whether you are compliant with the 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 should 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 and;

2. Being transmitted internally or externally, including recipient and purpose and;

3. Identify processes for data subjects to verify, update and/or request deletion of their 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 and;

5. Information security management controls and processes against the GDPR principles

6. Identify opportunities for data rationalisation and process improvements

If you need a helping hand, our data privacy and technology experts are ready to assist you, so feel free to check out our GDPR solutions and get in touch today.

Related Content

PRCON 2011

PRCON 2011

Whilst we are ardent supporters of maintaining a healthy balance between work and life and well awar...

Welcome to the Perspective Risk Blog

Welcome to the Perspective Risk Blog

The Perspective Risk blog has been created to provide information security resources to the penetrat...