GDPR (General Data Protection Regulation) comes into full force in the UK and European Union on May 25^th 2018.  Non-compliance can result in a fine of 4% or organisation revenue or €20 million, whichever is higher.  Failing to put in place and demonstrate he necessary administrative measures can result in a fine of 2% of organisation revenue or €10 million.  Clearly the regulation has teeth sharp enough to be taken seriously at the highest levels of an organisation.  

If you work for a European or UK company ,or the target of your goods and services are European or UK citizens, then the act will affect you. The full text (88 pages) of the act can be read in “The Official Journal of the European Union”. For those in the UK the Information Commissioner’s Office provides a reasonably clear summary and guidelines for implementing GDPR. 

The act is broken down into eleven chapters, 99 articles and 170+ recitations.  For a data engineer, the first four chapters are of most relevance

• Chapter one – General provisions (overview, definition of terms and scope)
• Chapter two - Principles
• Chapter three – Rights of “Data Subjects” (you and me)
• Chapter four – The role of the “Data Processor” and “Data Controller”

An example of an article would be Chapter three, Article 17 – Right of erasure (the right to be forgotten).  The article is supported by two recitals which give more detail as to what is expected when enacting the article

However, I am a data engineer not a lawyer, so although I have read through the act I needed something to help remember the key points in a form that was easy to follow and understand.  I decided to represent the first four chapters as simple diagrams to act as a summary and crib notes which I would like to share with you in this article.

Chapter One – Overview, scope and definition of terms

Within GDPR there are certain terms (see Article 4) that have special meaning and are used throughout the document.  The main terms are listed in the table below.

Given that there is a €20million fine riding on these definitions then context is all.  If in doubt get legal advice or speak to your “Supervisory Authority”.

In the diagrams that follow I have highlighted the key terms in orange to emphasise their importance.

Notice that the regulation covers your personal data even if it not stored on a computer.

The regulation makes a clear distinction between a “Natural Person” and a “Legal Person”.  A human being is a “Natural Person” AND a “Legal Person”. An organisation is a “Legal Person” only.  This is why ISO5218 covering gender has a specific code for “Not applicable” that can be applied to an organisation and a separate code for “Unknown”.

Chapter Two – Principles

GDPR is all about you as a “Data Subject” giving informed and explicit consent.  A helpful pre-checked consent box is not allowed.  Giving your consent has to be a definite choice on your part.

I have described a contract as giving implicit consent.  Strictly speaking there is no implicit consent in GDPR.  What I mean that if you ask a company to carry out a task on your behalf then, in order to fulfil your request, you are granting consent for those actions that are obvious and necessary to fulfil that request.  For example, if you went to an insurance broker to insure your car then you are giving them permission to share your details with insurance companies for the purpose of giving you a quote.

It should be made clear to you what you are giving an organisation permission to do and why they need to do it.

The regulation makes specific provision for special categories of data.  It may be illegal for an organisation to share that information even with your consent.  For example, an EU state may decide that it would be illegal for the Strava sports app to share biometric data with insurance companies.

Chapter Three – Rights of the Data Subject

As a “Data Subject” your rights are covered by a number of articles within the regulation.  Examples of which are as follows.

• Article 15 - Right of access
• Article 16 - Right of Rectification
• Article 17 - Right of erasure - known as the right to be forgotten
• Article 18 - Right to restrict processing
• Article 19 - Obligation to communicate actions taken to ensure compliance with Articles 16-18
• Article 20 - Right of data portability

Data portability presents some interesting challenges.  A Data Subject could ask your organisation to present their data to your competitor and you would be legally obliged to do this.  However, not all industries have an agreed standard that would make this practical.  The intent is clearly to make it as easy as possible for consumers to choose and change who provides utility services such as gas, electricity, banking, telecommunications.  In the UK these industries have either originated from monopolies or have exhibited monopolistic tendencies in the past.

I see Article 20 as being forward looking and a positive step.

The point of the regulation is to protect your personal data and therefore a “Data Controller” has to put in reasonable steps to ensure that any requests you may make actually do come from you.

Having made a request to the “Data Controller” they are duty bound to respond within 30 days.

The regulation is clear that a response must be made within 30 days.  This is shorter than the 45 days allowed under the UK Data Protection Act.  Another key difference is that under the DPA companies can levy an administrative charge for satisfying your request.  Under GDPR they can only do this under exceptional circumstances.  These might be due to the repetitive nature, excessiveness or being of an unfounded nature.  The onus is on the organisation to prove such circumstances.

Where your data is acquired other than directly from you as “Data Subject” the organisation has to give you the contact details of the “Data Controller” from which they obtained it.

If an organisation cannot identify you then they are obliged to tell you but are not obliged to acquire additional information from 3^rd parties to enable them to identify you.

Chapter 4 – Role and responsibilities of the Data Processor & Data Controller

I found my enthusiasm for GDPR grew while reading through Chapter 4.  It mandates what I would consider to be good data disciplines.

General obligations

• Article 24 & 25 say that whatever safeguards, technical or organisational, to protect personal data must be put in a way that is by design & default.
• Article 32 says that considering costs, state of the art, likelihood and severity of risk we have to put in place appropriate security measures
• Article 35 says that when processing is likely to result in high risk we have to carry out a data impact assessment that takes into account the scope, context and purpose of activity.

Article 30 makes it plain that a catalogue of processes must be maintained, who is responsible for them and the categories of personal data processed.  This catalogue has to be provided to the “Supervisory Authority” on request.

In my experience software projects usually descope such tasks. At some future date beyond the consideration of the stakeholder or project team someone will have to be assigned the thankless task of software archaeology in order to support the next big application change. Under GDPR this significant piece of work has just become mandatory. 

Failure to be able to demonstrate compliance with the administrative requirements of GDPR can result in a fine that is 2% of turnover of €10million.

The role of the Data Protection Officer

In certain circumstances an organisation may have to appoint a data protection officer

• The organisation is a public body
• The core function of the organisation is bulk processing of special categories of data such as forensic information
• The core function of the organisation is to monitor individuals

A summary of the role of the “Data Protection Officer” is shown below.  The regulation makes clear that the Data Protection Officer cannot be instructed or coerced by the Data Controller or Data Processor in the execution of their duties.  They answer to the highest level within the organisation.

Handling data breaches

If you put in place all the technical and organisational safeguards necessary to comply with GDPR then the personal data you hold on behalf of your “Data Subjects” should be well protected.  However, accidents do happen and data breaches do occur.  In such a case the Official/Supervisory Authority must be informed within 72 hours.

There are situations where the Data Subject does not have to be informed.

• When there is no risk to the Data Subject
• When a public notification has been issued

Closing thoughts

I do not see chapters 5 to 11 as of lesser importance but simply falling outside the scope of my role as a data engineer.

• Chapter 5 deals with transfer of data to countries and organisations outside of the EU
• Chapter 6 describes the posers and responsibiltiies of official/supervisory authorities
• Chapter 7 describes the governance mechanism between supervisory authorities and the EU states
• Chapter 8 describes the penalties and judicial procedures
• Chapter 9 describes specific processing situations such as freedom of information requests, freedom of expression
• Chapter 10 describes delegation of powers down from the European Commissim
• Chapter 11 describes repeal of any preceding regulation and the activation of GDPR

Throughout the act the various articles make reference to each other and in doing so they also reinforce each other.  The more I read the regulation the more I respect the effort that has gone into producing it.  It is being viewed by countries outside of the EU & UK as a good template on which to base data protection regulation

I can see that compliance with the regulation will make the work of a data person much easier and ultimately benefit scrupulous organisation.  If an organisation has to gain explicit permission to use someones data then those organisations that treat their customers with respect and demonstrate their trustworthiness are likely to be the winners from GDPR.