GDPR in Plain English

Free Resource: The GDPR in Plain English

So here we are, it’s 2018 and the GDPR will be enforced THIS year. I suspect that both marketing budgets and the corresponding hype will now grow exponentially until everyone is sick to death of it. I know I am, and judging by the majority of questions on LinkedIn, I’m one of the seemingly few who have actually read the damned thing. Really read it.

And that’s the point of this blog. As a privacy novice I have made a significant effort to truly understand the GDPR. I have, quite literally, spent months poring over it in an effort to fully grasp its intent in order to provide appropriate guidance to my clients, and to more junior cybersecurity professionals. But just as importantly, I read it because the GDPR is about MY personal data, MY privacy, MY fundamental human right.

More often than not my guidance to others has been; “Talk to a privacy expert/lawyer.”, but I am now in a position to provide something a little more useful. In partnership with Angela Boswell (Lawyer / DPO / GDPR implementer), we have drafted a ‘GDPR in Plain English‘ resource designed to allow anyone to get a significantly better understanding of its meaning without having to either be a lawyer, or go through months of soul-destroying tedium.

The resource consists of 3 spreadsheet tabs:


  1. ‘Recitals’ – All 173 Recitals with 3 additional columns:o
    1. Recital Title‘ – Very brief summary of the Recital’s main theme, similar to those provided for the Articles;
    2. Plain English‘ – Angela’s and my attempt at turning legal-ese into plain language; and
    3. References‘ – Links to every Article or external document for more convenient access to relevant context
  2. ‘Articles (Reference)’ – The Articles contain a significant number of references to other Articles, Recitals, and external documentation. They are all provided here for convenience. ‘In-cell’ comments provide titles and, where appropriate, relevant content
  3. ‘Articles (Operations)’ – Work in progress, but we intend to provide implementation and operationalisation guidance as and when available. This will include the excellent guidance so far produced by the likes of the UK’s ICO, the WP29, and numerous law firms happy to share their knowledge for free (most notably Bird & Bird from whom I have plagiarised shamelessly).
    We have broken this tab into 7 distinct columns.

    1. Regulation‘ – A significant portion of the Articles relate to the ‘administration’ of the regulation itself and require no specific action on behalf of the controllers or processors. These cannot be ignored, but you should probably spend more time on the other stuff;
    2. Principles‘ – The foundational principles of the GDPR and should be fully understood by everyone. Again, no specific action is required other than to read and understand them, because these underpin everything that the GDPR is about;
    3. Process‘ – These are the things that will eventually need to be operationalised in some fashion. Documentation, record keeping, technology, security etc. all fall within this category;
    4. Legal/Compliance‘ – Things that will require legal expertise to handle. While this does not have to be a privacy lawyer, or any lawyer for that matter, if these things are not handled by subject matter experts you’re leaving yourself wide open;
      …and eventually;
    5. People Requirements‘ – The implementation and ongoing maintenance of GDPR is the definitive team effort. This is not an IT problem, or a legal one, it is a business challenge. This section will provide guidance, examples/samples, links and hopefully, in time, some real-world input from generous contributors;
    6. Process Requirements‘ – From policies and procedures, to privacy notices, to contractual language, at some point you are going to have to DO something. This section will provide guidance and sanitised samples of what others have done to meet a requirement; and
    7. Technology Requirements‘ – Technology can never fix a broken process, it can only make a good process better. This is as true for security as it is for the GDPR. Technology will be required to support/enable your ongoing operational efforts, and this section will provide guidance on technologies to consider, and to avoid. We will only care about function, not brand.

Hopefully this resource will be of some benefit to you, and you’re welcome to do with it as you wish. We only ask 2 things:

  1. Credit both Angela and myself if you do end up using this for commercial benefit; and
  2. Add to it! This resource has been the work of only 2 people who have nowhere near the experience or skill-sets to make it universally relevant. There will be translation gaps, naive assumptions, and things that we didn’t know we didn’t know. Help us!

Finally, I would just like to reiterate that the GDPR is not just a burden placed on businesses, it is a fundamental shift in how YOUR personal data is used. This is a significant enhancement to one of your fundamental human rights. Everyone should read this regulation, so please do your part to get this out to every ‘data subject’ and ‘natural person’ who needs it.

Download the Excel spreadsheet here: GDPR in Plain English

Please provide any feedback to

We thank you in advance.

[If you liked this article, please share! Want more like it, subscribe!]

2 thoughts on “Free Resource: The GDPR in Plain English

  1. In your opinion, does this protection apply to individuals in their professional capacity, i.e. representing a company/corporation in a B2B scenario rather than purely in their own individual right, such as a B2C web site?

    So if, for example, I work for ABC Corp and we’re looking into buying a new Widget Digitizer from XYZ Corp, so I go to and complete a contact form. Does my data from that form demand the same level of protection as if I’d gone to buy a pair of shoes for myself from

    • In general, the GDPR does not include B2B, it is about the data subjects themselves. It’s the ePrivacy Regulation that will cover B2B.

      So, for your example, while the data collected to fulfil the contract should be protected, the effects of it’s loss would be significantly less than the loss of personal data received directly from a data subject. The controls you put in place to protect the data would be appropriate to the risk.

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.