After more than three years of discussion, all three components of the European law making process have now produced their proposed texts for a General Data Protection Regulation should look like. The Council of Ministers’ version published last week adds to the Commission’s 2012 original and the Parliament text (unofficial consolidated version) agreed last March. EDRI have a helpful side-by-side comparison of the three versions. Data Guidance note significant differences between them , particularly on how prescriptive European law should be and how much its obligations may vary between organisations and countries. Representatives of the three bodies have just started a ‘trilogue’ process to develop a single agreed text. Although participants seem confident that this can be achieved before the end of 2015, commentators are less optimistic. Once a text is agreed, it’s likely to be around two years before it comes into force.
This seems a good time to revisit the comments I made in 2012 on how the original Commission proposal might affect three services of particular interest to the Jisc community: incident response, federated access management, and cloud computing.
On incident response, the news is mostly good. All three versions retain Recital 39 stating that protecting computers and networks is a legitimate reason for processing personal data, subject to appropriate safeguards (as I explained in my presentation last week at the FIRST conference). The Parliament adds limiting abusive access and use as a legitimate purpose, the Council adds fraud prevention and, probably more controversially, direct marketing. Under the Commission and Parliament texts, most incident response teams will also be able to use the same justification for including data such as IP addresses in reports sent to teams outside Europe (Art.44(1)(h)); the Parliament text would require some other justification to be found. And none of the three allows “legitimate interests” to be used by “public authorities in the performance of their tasks/exercise of their duties” which may create a problem for Government teams (Art 6(1)(f)) and those who wish to exchange data with them.
Access management federations in Research and Education have tried to encourage service providers to use privacy-protecting identifiers, rather than names or e-mail addresses. However under the current Data Protection Directive there is little legal incentive to do this. Both the Parliament and Council texts try, in Article 10, to create an incentive to use pseudonyms where possible: the Council version is clearest, stating that duties including subject access and the right to be forgotten will not apply in these cases, unless a data subject can provide proof of their identity. As for incident response above, the Council and Commission texts would allow federations to use the same legal basis when accessing services both inside and outside Europe, the Parliament text would not. However one of the major benefits for access management – that the use of a Regulation would lead to more similar laws in different member states – seems to have been put at risk by the Council text which allows national variation in as much as a third of the Regulation. Indeed the former Commissioner who originally proposed the Regulation commented that the Council risked turning it into a Directive.
For cloud computing the main benefit of the Regulation would have been more consistency of national laws: something that now seems in doubt. All drafts follow the Commission in extending the Regulation’s scope to services outside Europe that offer services to individual European consumers (Art.3(2)(a)), thus making all consumer cloud services subject to European law. However there appears no resolution of the difficulties of fitting lower level cloud services, such as Platform as a Service and Infrastructure as a Service, into the legal regime (comments from Council members indicate that they were aware of these problems but did not find a solution – see footnotes in the EDRI comparison). For example if such clouds are considered to be “processing” personal data at all it seems that they will need to know what kinds of data are being processed, in order to fulfil a duty to provide appropriate security measures, even though an IaaS provider trying to determine the meaning of bytes processed on its equipment would itself be a significant privacy breach.
