GDPR - Line-by-line

In May 2018, the GDPR, which is new data protection legislation, becomes applicable, with worldwide impact.

Now, there's plenty of management summaries available on-line, but sometimes it's worth going back to the source document. The below is intended as a recital-by-recital interpretation of the supporting information in the GDPR to allow people to navigate to the parts of the source they would like to inspect in closer detail. As such, the information below should be very much considered the spirit, not the letter, of the document.

So, I'm going to go through the supporting recitals of the new legislation and turn it into plain (and hopefully still semantically correct) English. A couple of things to note:

  • I'm not a lawyer and, even if I was, anything you read below should not be construed to be legal advice.

  • I'm a software developer, so I've probably paid more attention to the impact the law is likely to have on systems, as opposed to other aspects.

I've flagged recitals up individually with the rough aim of the recital as listed below:

Supporting - Background information, history, justifications, summaries

Legal - Extension points for the legislation, plus how the legislation may be modified by, or interact with, new or existing legislation.

Modification - A recital modifies the terms of a preceding recital

Definition - Something which defines who or what is protected, or who or what must comply with regulations

Processing - Things to do with processing personal data

Storage - Things to do with storing personal data

Collection - Things to do with collecting personal data, including consent

Transfer - Things to do with transferring personal data

Oversight - Things to do with regulation.

In the source, the following terms are used (and I've used the terms in brackets in the interpretation):

Data subject (person/people) - The person whose personal information has been collected.

Data processor (processor) - The entity responsible for performing the processing of personal information (may be subcontracted by the controller, may be the controller or may be a subordinate of the controller).

Data controller (controller) - The entity responsible for the data collected for the purposes of processing.

Supervisory authority - The legal entity responsible for overseeing data protection activities in a given country.

(this) Regulation - The GDPR.

(the) Board - An overarching oversight committee which regulates supervisory authorities.

The text of the GDPR may be found here: http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf

In later blogs we'll look at the real-world impact of the drafted legislation, particularly as it relates to Land Assembly.

Let's begin! (the numbering below follows that of the recitals in the GDPR).

- (Page 1) (Supporting) It's legislation by the EU, and they've jumped through all the hoops they need to jump through to make this legislation legitimate.

1 (Supporting) People's personal information should be protected...

2 (Supporting) Wherever they're from...

3 (Supporting) A standard way of doing this makes information flow between entities easier.

4 (Page 2) (Supporting) Processing people's personal information is useful, so it shouldn't be banned completely.

5 (Supporting) Personal data is moving around much more frequently now and...

6 (Supporting) Technology has enabled this...

7 (Supporting) So we need better legislation to deal with data protection.

8 (Legal) Certain elements of the GDPR may be customised on a country by country basis...

9 (Supporting) We've had a stab at this before, but it spun out in various directions and became fragmented...

10 (Supporting, Legal) So this time, we're going to make sure it all stays consistent. If you're a government, you'll still be able to put in specific regulation to allow your government to operate, and the GDPR doesn't override anything you've already got in place.

11 (Page 3) (Supporting) So, we need to define what protections are offered to people, what controllers who use personal data must do and what oversight must be applied.

12 (Legal) We've got the power to do this.

13 (Supporting, Modification) For this thing to work, everyone's got to do things in the same way. That being said, we'll make things easier for you if you're a controller with less than 250 employees.

14 (Definition) The protection offered by the GDPR applies to people, not businesses or suchlike.

15 (Supporting, Definition) We're not going to tell you exactly how to go about protecting data: just make sure you protect any structured personal information within your care.

16 (Legal) The GDPR doesn't apply to anything outside of European law. If you're not sure if what you're doing is outside of European law, it probably isn't.

17 (Legal) We're going to keep other legislation consistent with this.

18 (Definition) We only care about protection of personal information if you're using it for business purposes. Your personal address book is not our concern!

19 (Page 4) (Modification) If you're a law enforcement agency then other legislation to do with data protection applies.

20 (Modification) Same if you're law courts and suchlike.

21 (Legal) If something in the GDPR is less restrictive than other existing legislation, the more restrictive legislation wins. No get-out-of-jail-free cards.

22 (Definition) If you're a company operating from the EU, the GDPR is applicable to all personal information you hold, not just that of EU citizens.

23 (Page 5) (Definition) If you're a company operating from outside the EU, the GDPR applies to personal information about EU citizens, if you're planning on selling stuff to them.

24 (Definition) Same again, but if you're planning on using data about their behaviour, such as internet usage.

25 (Legal) Embassies and suchlike count as being part of the EU, if they belong to an EU country.

26 (Definition) Personal information is any information which is linked to a known person, or which may be used (using reasonable methods, when combined with other information) to identify an unknown person

27 (Definition) If you're dead, you're no longer protected.

28 (Definition) Splitting information which can identify a person away from non-identifying information prior to processing (pseudonymisation) is a great idea, but don't go thinking it's the only way of doing things.

29 (Supporting) We encourage processors to use pseudonymisation where possible

30 (Page 6) (Definition) Things like cookies and IP addresses are personal information too.

31 (Definition) Governments may request personal data to use to carry out special tasks to support their running, but they should only ask for what they need and should follow all applicable laws when processing the data.

32 (Definition, Collection) Personal information may only be collected if the person has actually agreed that it may be collected (by ticking a box, or saying yes or suchlike – the default stance must be that they have not agreed). Personal data may only be used for the purposes that the person has agreed to.

33 (Definition) If it's not possible to define a specific purpose for data processing, a general one may be stated.

34 (Definition) Genetic data is personal data.

35 (Definition) Health data is personal data.

36 (Definition) When processing data, some entity is considered to be in control of, and responsible for, the process (the controller). This entity is the one which has control over how the data is processed which isn't necessarily the same entity which actually processes the data (the processor).

37 (Page 7) (Supporting) Controllers may be structured in a hierarchical manner. There will always be a head controller.

38 (Modification) Children should be treated with special care.

39 (Collection, Storage) A person that has consented to have their personal data collected should be clearly told, when their data is collected, who is the controller, what is being done with the data and what procedures are in place to minimise the risks of negative impact. They should also know that they can ask to see their data. The data collected should be the minimum required to perform the required process and should be retained for the minimum time necessary. Any data errors should be corrected so the personal data is correct. Personal data should be stored and accessed in a secure manner.

40 (Definition, Collection, Legal) In order to process personal data, there must either be consent from the person, or something legal which enables the processing of the data.

41 (Page 8) (Legal) If personal data is being processed based on something legal rather than consent, the legal basis must be solid.

42 (Collection) If personal data is being processed based on the person's consent, the consent must be given having been told what's going to happen to the data and who the controller is. The controller should be able to provide proof of consent. Consent should be freely given, there should be no incentives or drawbacks to giving or not giving consent.

43 (Collection) Consent is invalid if:

  • Providing a service or contract is made dependent upon consent being given, but the service or contract doesn't require the personal data to be collected.

  • It isn't asked for at the most granular level possible for all processing to be undertaken.

  • Consent is being sought by a governmental body; they would have to use legal methods to enable the processing of personal data.

44 (Processing) If the processing supports anything contractual, it must be done lawfully.

45 (Processing) When processing of data is required by law, or the processing is being done for a government, the processing should be based on a law which describes how the processing takes place and who may perform the processing.

46 (Processing) Personal data may be processed, if it is used to safeguard life and prevent suffering, and there is no other way of accomplishing the same task.

47 (Page 9) (Processing) Personal data may be processed if there is an existing relationship between the person and the controller (like being a customer or employee), if the person would expect their data to be processed.

48 (Processing) Controllers which have been given consent to use personal data, may move the data between their branches for processing.

49 (Processing) Personal data may be used to support network security operations (e.g. IP addresses of malicious users)

50 (Processing) Personal data may only be processed for the purpose described when consent was given, unless the new purpose is:

  • Specifically allowed by law or

  • Is in the spirit of the original purpose, and poses no additional risk to the person

  • To prevent an illegal act by the person by reporting the details to the authorities

51 (Page 10) (Processing) Certain types of personal data count as special category. Special category data should not be processed unless specifically allowed by other legislation or explicit consent is given. Biometric data is special category data. Racial data is special category data.

52 (Processing) Special category data may be processed when there is another law which explicitly allows it.

53 (Processing) Health data is special category data. Special category data relating to health should only be processed when the processing benefits specific people or society as a whole.

54 (Page 11) (Processing) Certain categories of special category data relating to health may be processed without consent when the processing of such data is for the public good.

55 (Processing) Special category data may be processed to further the lawful aims of officially recognised religious organisations, so long as the personal data is that of their members.

56 (Processing) Personal data may be processed in support of democratic systems.

57 (Processing, Collection) If a controller cannot identify the person being processed from the data available to them, they need make no effort to identify the person for the purposes of complying with the GDPR. They must accept any additional personal data supplied by the person.

58 (Collection) Communication regarding the use of collected data should be easily understood by its target audience.

59 (Storage) The person about whom data is stored should be able to, via the controller, be able to view and, potentially, to correct and delete the data. The person should also be able to object to the data being stored. If the data is being processed electronically, there should be mechanisms of doing this electronically.

60 (Page 12) (Processing, Collection) Any processing of personal data should be communicated to the person. The nature of the processing and its impact should be clearly communicated. If the data is being collected, the impact of supplying or not supplying the data should be clearly communicated.

61 (Collection, Processing, Transfer) The purpose for which personal data is being collected should be communicated to the person when the data is collected or, if the data is disclosed to another processor, when it is disclosed. If the controller is going to use the data for a purpose other than that originally stated, the person must be informed.

62 (Processing) If the person already has been informed that their data is going to be processed, or there's another law saying that it's OK to process, or it's going to be insanely difficult to get in contact with the person, it isn't necessary to inform them again.

63 (Storage, Processing) A person should be able to access personal data stored about them, and about processes which have been carried out on this data.

64 (Storage) A controller should verify that a person requesting their personal data is who they say they are, but supporting this requirement is not enough to justify holding additional personal data.

65 (Storage) A person may request to have their personal data deleted from a controller, and this request must be honored if the person's consent is the only thing which allowed the collection of the information in the first place.

66 (Page 13) (Storage, Transfer) A controller holding personal data which is to be deleted must inform anyone to whom they have communicated the data that the data is to be deleted.

67 (Supporting) There are various ways that personal data may be made unavailable to be processed within a system.

68 (Storage, Processing) If the controller holds personal data in electronic format, the person should be able to request this data in a common electronic format where possible, or to request that this is sent to another controller.

69 (Processing) Even if the processing of person data is allowed by law, a person may still object to the processing.

70 (Processing) Where data is processed for marketing reasons, the person may object to this processing.

71 (Page 14) (Processing) Any processing of personal information which results in inferring personal traits from personal data (profiling) are not allowed unless expressly stated by the person or expressly allowed by law – especially so for special category data.

72 (Oversight) A body will be setup to provide guidance on profiling (the board).

73 (Legal) All the rules in the GDPR may be overridden by specific law to deal with public safety and criminal matters.

74 (Legal) All controllers should be able to prove they're following the GDPR, on a case by case basis.

75 (Page 15) (Supporting) Personal data may have a negative impact on a person's life, in a wide variety of ways, if it isn't properly controlled.

76 (Processing, Collection) Controllers should perform risk assessments.

77 (Supporting) Guidance on what is risky may be provided by the board, or from several other places.

78 (Processing, Collection) All controllers must put appropriate procedures and technologies in place to ensure personal data is dealt with according to these regulations. Controllers should use systems and procedures which are designed to protect personal data.

79 (Processing) Controllers dealing with personal data in a hierarchy of controllers/processors must have clearly defined responsibility boundaries.

80 (Processing) Any controller which is outside the EU, which is processing personal data of EU citizens, must (with certain exceptions) nominate a representative to deal with the obligations of the GDPR. This representative can get in trouble if things go wrong.

81 (Page 16) (Processing, Transfer) If processing of personal data is farmed out, the controller must ensure the processors are up to the task in terms of compliance with the GDPR.

82 (Processing) All processors should keep an audit trail of the processing which has been done.

83 (Processing) All processors should minimise the risk of something going wrong by using techniques such as encryption.

84 (Processing, Oversight) Any processing of personal data which is deemed risky must have an impact assessment done. If that impact assessment reveals risks which cannot be minimised, the processing must be referred to the supervisory authority before processing is started.

85 (Processing, Oversight) In the event that personal data is lost/stolen or otherwise breached, the controller must notify the supervisory authority.

86 (Page 17) (Processing) In the event of a breach, the entity processing the data must notify the person to whom the breached data relates.

87 (Processing, Oversight) In the event of a breach, the controller's procedures for detecting a breach are reviewed by the supervisory authority to ensure that notification happened as soon as it should have.

88 (Processing) How notification of a breach is reported will depend on the controllers's procedures and any technical protection on the data.

89 (Oversight) It's no longer necessary to report all data processing to the supervisory authority, only processing which is more risky because:

  • it uses new techniques or

  • similar processing has not already been undertaken by the controller

90 (Processing) Processing which is deemed more risky should always have an impact assessment done.

91 (Supporting) An example of the above would be something which processed a large quantity of special category data using new technology, or where profiling is involved, or where lots of data is automatically collected and processed (e.g. CCTV)

92 (Page 18) (Processing) Impact assessments may cover more than one processing instance.

93 (Legal) Government bodies should carry out impact assessments too for their personal data processing activities.

94 (Oversight) Where an impact assessment flags up that a processing activity is risky and cannot be made less risky, the supervisory authority must be notified.

95 (Processing) Processors should assist controllers by providing evidence of GDPR compliance

96 (Legal, Oversight) Any laws drafted to enable processing of personal data should be made in consultation with the supervisory authority

97 (Processing) Where processing is carried out by:

  • The public sector or

  • The private sector and the processing involves a large amount of personal data, updated regularly or

  • The private sector and the processing involves personal data to do with criminal activity

a consultant should be employed.

98 (Page 19) (Supporting) Associations representing groups of controllers should draft their own codes of conduct to aid in their members effectively implementing the GDPR

99 (Supporting) When making a code of conduct, all people affected by it should be consulted.

100 (Supporting) The existence of data protection compliance badges and suchlike is a good thing.

101 (Definition) The GDPR applies to personal data belonging to EU citizens, irrespective of where in the world the data ends up.

102 (Transfer) EU members may still make agreements with other non-EU entities (including countries, organisations etc.) regarding data protection and the transfer of personal data, but they must be subject to the GDPR.

103 (Transfer) The EU can blanket-approve a non-EU entity as having a data protection policy compatible with the GDPR.

104 (Transfer) When deciding if a non-EU entity can be trusted regarding data protection, the EU should consider a wide range of issues.

105 (Page 20) (Transfer) As well as considering a non-EU entity with regards to data protection in isolation, it should also be considered in terms of agreements it has with other non-EU entities.

106 (Transfer) The EU should regularly review how it views other non-EU entities with regards to data protection.

107 (Transfer) If a non-EU entity which was trusted regarding data protection becomes untrustworthy, that entity will no longer be blanket-approved.

108 (Transfer) If no decision has been made regarding a non-EU entities trustworthiness regarding data protection, it is the responsibility of the controller to ensure suitable protections are in place.

109 (Supporting) When drafting agreements about data protection procedures with non-EU entities, standard clauses from the GDPR may be used, as may bespoke clauses, so long as the spirit of the GDPR is maintained.

110 (Page 21) (Supporting) If a controller is part of a hierarchy, agreements and procedures from further up the tree may be used instead of having to draft new ones.

111 (Modification) When drafting transfer agreements, there are various things which should be considered to enable data to be transferred which may not have otherwise have been transferrable. Overall, personal data transferred should be minimised.

112 (Modification) Reasons to do with the public interest may also allow the transfer of data between EU and non-EU entities to be lawful.

113 (Modification, Oversight) Transfers between EU and non-EU entities may also be lawful if the controller has a reason to transfer the data, and notifies the supervisory authority and person.

114 (Definition) It is the controller's responsibility to ensure that the person has access to the same functionality they have within the EU, when their data is transferred outside of the EU.

115 (Page 22) (Modification) Some non-EU entities have laws which unilaterally say it's OK to receive person data from EU members. Unless the GDPR is satisfied, these laws are irrelevant.

116 (Supporting) Once personal data about an EU citizen has travelled outside of the EU, it gets harder to control, as such we should all try to work together to make it easier to control.

117 (Supporting) Supervisory bodies are necessary. If a given EU member needs more than one they should do so.

118 (Supporting) Supervisory bodies are independent when it comes to performing their duties regarding data protection, but may be subject to oversight for things like financial management etc.

119 (Supporting) If there are multiple supervisory authorities within an EU member, their responsibility boundaries should be clearly defined.

120 (Supporting) Supervisory bodies should have whatever is necessary to get their jobs done.

121 (Oversight) How a supervisory authority is run should be enshrined within an EU members’ law and should be open to scrutiny.

122 (Oversight) Supervisory authorities should be capable of handling all of their duties.

123 (Page 23) (Oversight) Supervisory authorities should help one another support the GDPR

124 (Oversight) In the event that a controller is distributed across various EU members, the supervisory authority in the member where the head of the controller's hierarchy sits (as per clause 37) should take the lead.

125 (Oversight) If supervisory authorities are working in a hierarchy, the lead will take decisions which will be adopted by the others in the hierarchy.

126 (Oversight) Any formal communication between hierarchies of supervisory authorities and controllers should happen between the heads. Controllers should do whatever the supervisory authority tells them to do.

127 (Oversight) If supervisory authorities are working in a hierarchy with controllers in a hierarchy, a non-head supervisory authority may still work with a non-head controller on matters local to both.

128 (Page 24) (Oversight) Oversight required on processing work done for a government will always be carried out by the supervisory authority local to that government.

129 (Oversight) Supervisory authorities must be granted at least a minimum set of powers by the government under which they operate.

130 (Oversight) If supervisory authorities are working in a hierarchy, the supervisory authority local to a complaint or other event should be consulted with closely by the lead.

131 (Oversight) If supervisory authorities are working in a hierarchy, and action is to be taken solely within a non-lead EU member, the local supervisory authority should try to sort things out, but should escalate it if necessary.

132 (Supporting) Supervisory authorities may raise awareness of data protection issues via advertising and suchlike

133 (Page 25) (Oversight) Supervisory authorities should help one another out.

134 (Oversight) Where it's more effective for supervisory authorities to work together, they should do so.

135 (Oversight) It's important that supervisory authorities work to the same standards across the union.

136 (Oversight) The board (as defined in clause 72) will provide oversight of supervisory authorities.

137 (Oversight, Modification) Supervisory authorities may do whatever is necessary and legal to protect personal data (provisional measures), but if it does anything non-standard, it must only be for 3 months maximum.

138 (Oversight) In the event that supervisory authorities are working in a hierarchy, they should coordinate the use of provisional measures.

139 (Oversight) The board will have certain defined legal and organisational characteristics.

140 (Oversight) The board will be assisted by other EU departments.

141 (Definition) People may raise complaints about data protection with their local supervisory authority, and may complain about the supervisory authority if it doesn't do its job.

142 (Page 26) (Definition) People may appoint certain other organisations to complain on their behalf.

143 (Definition) People, processors and controllers may object to a decision by a supervisory authority or the board via the legal system.

144 (Supporting) If legal proceedings about the same thing are under way in various courts, they should all communicate and work sensibly.

145 (Page 27) (Supporting) Legal proceedings should happen in a legal system local to the processor, controller or person which is the focus of the legal proceedings.

146 (Processing) In the event of a controller infringing the GDPR, they will need to compensate the affected parties.

147 (Legal) Rules to do with compensation with the GDPR supersede more general rules.

148 (Oversight) Fines and reprimands may be issued by supervisory authorities.

149 (Oversight) Criminal penalties may also be imposed for breaches of the GDPR.

150 (Supporting) The GDPR will provide guidance on upper limits for fines and suchlike.

151 (Page 28) (Legal) Issues specific to Denmark and Estonia and how they deal with fines.

152 (Supporting) Where the GDPR doesn't provide guidance on fines and suchlike, EU members should ensure that their legal systems provide strong disincentives to breach the GDPR.

153 (Legal, Modification) The GDPR should be legally implemented in the context of other laws (such as freedom of expressions etc.).

154 (Legal, Modification) The GDPR should take account of public access to official documents.

155 (Page 29) (Legal, Modification) The GDPR should take account of existing employment law regarding the processing of personal information.

156 (Processing) Processing personal data for scientific, statistical, historic or public interest reasons should use protective techniques on the data such as pseudonymisation and minimisation of processing.

157 (Storage) Specifically, storing scientific research data containing personal data is useful for certain purposes, but must be protected.

158 (Storage) Specifically, storing archived data containing personal data is useful for certain purposes, but must be protected.

159 (Page 30) (Processing) Processing personal data for scientific research is covered by the GDPR.

160 (Processing) Processing personal historical data is covered by the GDPR, unless the person is dead.

161 (Collection, Legal) If a person wishes to consent to be part of a scientific trial, there is also other legislation which must be followed.

162 (Processing) Processing personal data in a statistical manner is covered by the GDPR.

163 (Supporting) Statistical data held by the EU should be protected.

164 (Legal) Professional secrecy laws should be balanced against the GDPR.

165 (Legal) The GDPR doesn't supersede any existing laws relating to religious bodies.

166 (Legal) In order to support the GDPR, the EU commission will adopt other supporting law (e.g. defining certification schemes etc).

167 (Page 31) (Legal) The EU commission will implement the GDPR, paying heed to things like clause 13.

168 (Legal) The EU will follow one of its standard procedures when implementing the GDPR.

169 (Legal) The EU will not delay if it needs to take immediate action to protect personal data from being transferred to a non-EU entity with unsuitable data protection standards.

170 (Legal) As data protection is an EU level challenge, some things will happen at union level.

171 (Legal) Some existing legislation is being repealed by the GDPR.

172 (Legal) Some other bodies were consulted whilst the GDPR was being drafted.

173 (Legal) The GDPR is going to be the primary source of legislation for data protection matters and, once implemented, some other legislation will be reviewed to bring the other legislation in line with the GDPR.

That wasn't so bad, was it? Now, the above is from the supporting recitals to the draft legislation which, I feel, give the best overall flavour of the legislation. When we dig into the impact of the legislation, we'll refer to the articles and sections of the drafted legislation.


 ​​64 Wellington Road,

Edgbaston, Birmingham,

United Kingdom B15 2ET

Tel: 07970 280 241


Get in touch

​​​​© 2017 Land Assembly Services  |  Image credits and acknowledgements.

  • Grey Twitter Icon
  • Grey LinkedIn Icon