This essay discusses the relationship between technical standards and mandatory security measures under the European data protection legal framework.

The starting point of the discussion is the existing data protection primary legal source which, at EU level, is EC Directive 95/46 (hereinafter the “Directive”). This is soon bound to be replaced by a new legislative instrument, this time in the form of a Regulation (hereinafter the “GDPR”). A specific point of interest of the forthcoming GDPR is that it seems to propose an ampler view of security measures and, unlike the Directive, expressly tackles to some extent the issue of the relevance of standards. The discourse on the GDPR will rest on a text which is still in the form of a draft, reflecting the different positions that the institutions involved in the “trialogue” legal procedure have expressed with specific regard to the desirability of standardization of security measures.

The issue that I more specifically wish to focus upon is how technical standards in the field of data protection security measures relate to the responsibility of data controllers[1] and, namely, whether adherence to information security standards is sufficient to demonstrate fulfilment of the requirements of the law prescribing the adoption of “appropriate” and “state of the art” security measures.

To be sure, data protection and information security are not entirely overlapping concepts when one looks at goals and stakeholders: information security is technician driven and is concerned with the management of risks of large organizations, whereas data protection is lawyers’ driven and the risk is evaluated from the perspective of the potential injury that the individuals’ fundamental right to privacy can suffer[2]. In this respect, at the expense of sophistication, it could be maintained that information security in general is very much a matter of inward-looking safeguards that organizations put in place with a view to protect their own assets (such as trade secrets, information with commercial value and more in general to keep a healthy IT system in consideration of the specific activity of the organization concerned), whereas data protection related security measures are more outward oriented and legally derive from a statutory duty to protect the information privacy of third parties (the data subjects) as fundamental human rights. As discussed in this essay, this difference has a bearing on the role of security standards under data protection laws.

The role of standards in the Directive

Art. 17 of the Directive sets forth the principle of secure personal data processing in quite broad and general terms. It states that “in order to protect data against accidental or unlawful destruction of accidental loss, alteration, unauthorised disclosure or access…” the “data controller must implement appropriate technical and organisational measures”. Notably the provision goes onto saying that to achieve an appropriate level of security, “the state of the artcostsdata protection related risks and the nature of personal data processed shall be taken into account”.

The obligations deriving from art. 17 are specified and tightened up in art. 8 as it concerns special categories of data, known as “sensitive data” and explained by recital 46 of the Directive.

There is no express reference in the Directive to existing (or future) technical standards as a means to secure compliance with security obligations. Even though it has been held that the wording of article 17 and recital 46 of the Directive attaches implicit importance to standards[3], the Directive’s silence over standards is not accidental, to the extent that the adoption of a specific standard would in the medium term endanger the very goal of providing up-to-date technical safeguards against the risks to which personal data are exposed. As a matter of fact, technology frequently changes and so do the threats posed by malicious adversaries to data management systems. Therefore the adoption of specific standards in the law would require regular and frequent updates to the legislation. Hence the choice of the Directive’s legislator to opt for framing the requirements of the law by using general and undetailed expressions, as it is evidenced by the usage of the words “appropriate” and “state of the art”. This is consistent with the generally accepted view that security is a relative concept.

In this vein, while the Directive does certainly not prohibit reference to technical standards in a controller’s security policy, it does not qualify as a “new approach” directive, where technical standards are expressly recognised in the legislation as providing a presumption of compliance with the law. Hence, at least from the perspective of the wording of the Directive, the implementation of a technical standard is not enough for an organization to (at least presumptively) demonstrate compliance with the requirement of “appropriateness” set forth in article 17.

Clearly the Directive has not taken this approach and, as mentioned, this is the consequence of a deliberate policy choice made by the EU legislator.

Failure by the Directive to incorporate security standards makes it also difficult to identify the meaning of the “state of the art” as a benchmark against which, according to art. 17 of the Directive, the appropriateness of the measures should be assessed. The question is in fact, if the state of the art is what is commonly accepted among experts as the more up to date solution to security issues, then what better tool than a technical standard? In this respect, some authors have taken the firm view that the application of technical standards in the field of Information Security Management Systems (“ISMS” such as ISO 27001 series), would meet the state of the art requirement of the Directive. In the context of the current data protection Directive, I am however sceptical that this position would in all circumstances withstand scrutiny before a court of law. The first observation that comes to mind is that existing ISMS standards were in general not specifically devised to respond to the specific requirements of the Directive concerning the protection of personal data; the second remark is that, as drafted, the wording of article 17 uses the “state of the art” as just one of the elements to be taken into account for the assessment of the appropriateness of the security measures. Such an element is to be blended in with the other elements that art. 17 considers of relevance, these being “the cost of their implementation”, “the risks represented by the processing” and “the nature of the data to be protected”.

An interesting example of a standard that on its face appears capable to qualify as “state of the art” for secure processing is provided by the recently adopted ISO/IEC 27018 concerning “Information technology – Security techniques – Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors”. Next to ISO/IEC 29100, which provides “Information – technology-Security techniques – privacy framework”, ISO/IEC 27018 appears the closest thing to a standard designed around the need to address the specific data protection security requirements that are required of a cloud provider acting as data processor. In this regard, ISO/IEC 27018 adds to ISO 27001 and 27002, as it specifically deals with information privacy risks from the visual angle of a processor of Personal Identifiable Information (“PII”).

Unlike other ISO 27000 series standards, ISO/IEC 27018 addresses the specific risks of public cloud computing vis-à-vis the processing of PII. From a legal stand point, as the standard was approved by a recognized international standardisation body, it no doubts can be held to document what it is perceived to be the “state of the art” with respect to the security issues it deals with. However, compliance by a cloud provider with the standard in question may prove insufficient to fulfil the security requirements of art. 17 of the DP Directive, bearing in mind that according to the latter the “appropriateness” of the measures is relative to (inter alia) the “nature of the data to be protected”. In this latter respect, the ISO/IEC 27018 does not seem to be capable of providing full comfort to a data controller using a cloud provider that it complies with the law, to the extent that the concept of “PII”[4] is not differentiated having regard to the different types of PII, such as in particular those qualifying as “sensitive information” for the purposes of the Directive. Consequently the standard makes no differentiation as between the several controls relating to different categories of PII. This configuration of the standard, although state of the art, may fall short of the Directive’s requirement to ensure that the level of security is appropriate to the “nature of the data to be protected”.

The story of ISO/IEC 27018 tells us that, even when technical standards may be used as benchmarks of the “state of the art” in the field of data protection security measures, it will most likely still be necessary to double-check whether the specific standard would withstand scrutiny, having regard in particular to the specific risks in each instance posed by the processing and the nature of the data.

The example of ISO/IEC 27018 vis-à-vis the choice of the Directive to formally disregard any reference to technical standards suggest that, as it has been argued, security is primarily a process and not a product[5] and, therefore, it is something that cannot be frozen in a set of security measures adopted once and for all by a given organisation. This configuration should, under the Directive, ultimately lead to individualised and forms of security policies subject to adjustment and review from time to time. There are a variety of security measures to choose from. However, what controllers would as a first step be required to do is to demonstrate that they have put in place a program, comprised of several security related controls, on the basis of which they would then implement specific security measures. The first of these controls should be the identification of risks relative to the companies’ specific operations and processed data.

On this premise, ISMS standards, such as ISO 27001, in so-far-as they establish an internationally accepted set of controls that together contribute to form a “process”, will not provide full comfort to controllers that they are complying with the requirements of the law[6]. However, they may be taken as a “state of the art” codification of the best practice companies may follow to set up a security process, contributing to compliance with the law. This position is echoed by scholars remarking that standards look primarily at the effectiveness of processes, while the adequacy of the protection afforded to human rights is not something they are concerned with[7].

The role of standards in the proposed GDPR.

On 15 December 2015, the EU Commission announced that an agreement was found with the European Parliament and the Council on the GDPR’s final text. The agreed text is not available yet. For the purposes of this paper, it is however of interest to report, on the basis of the table comparing the different positions as of June 2015[8], how the “trialogue” among the EU institutions has developed around the issue of security measures and standards.

The duty for controllers and processors to implement security measures is dealt with under article 30 of the GDPR. The terminology is similar to that in art. 17 of the Directive: the measures must be “appropriate” to ensure a level of security “appropriate” to the risks of processing, having regard to the state of the art and the costs of implementation. The three EU institutions’ versions however are not entirely convergent. The Council has in fact deleted any reference in art. 30 to the “state of the art” and replaced it with reference to “available technology”. A significant departure in the Council’s position is also where the Council has proposed the deletion of para. 3 of art. 30, where both the Commission and the EP proposals sought to empower the Commission (or the European Data Protection Board in the EP version), to adopt guidelines for the technical and organisational measures, “including the determination of what constitutes the state of the art for specific sector and in specific data processing situations”. The Council’s decision to remove para. 3 of art. 30 altogether, has likely been expired by scepticism towards any rigid legal definition of “state of the art” to be delegated to lengthy institutional processes incapable of keeping pace with technology innovation. Hence the Council’s preference for reference to “available technology”, which is something which will need to be identified real time on a case by case basis.

The role of technical standards as a means to ensure security of processing is expressly mentioned in recital 66 of the GDPR in both the Commission and the EP versions. Consistently with the approach described above, the Council has eliminated from its version of recital 66 any reference to technical standards. The Council’s has instead chosen to place emphasis on the importance for each controller of carrying out a privacy impact assessment ( “PIA”), “the outcome of which should be taken into account when determining the appropriate measures to be taken in order to demonstrate that the processing is in compliance with the Regulation”. Any PIA would of course inherently be a highly individualised instrument, something on its face which does not combine well with standardised guidelines.

The role of standardisation for the purpose of securing compliances is, however, not completely neglected in the Council’s position. As a matter of fact, the Council’s wording of art. 30 of the GDPR, at paragraph 2a., proposed that adherence to approved codes of conduct under article 38 or to an approved certification mechanism under article 39 “may be used as an element to demonstrate compliance”. Approved codes of conduct may, according to the Council’s proposal, regulate measures and procedures to satisfy the requirements under the accountability and privacy by design and by default provision and to ensure security of processing, pursuant to article 30. Article 39 deals instead with the certification of compliance with the Regulation’s provision by third party independent certification bodies to be accredited in accordance with Regulation (EC) 765/2008. Both the EP and the Council concur that the Commission should be empowered to adopt delegated acts specifying the requirements and criteria for the data protection certification mechanism.

The framework resulting from either self-imposed approved codes of conduct or from certification provided by accredited bodies on the basis of criteria fixed by the Commission, would thus qualify as a technical standard in the field of data protection, including security safeguards.

At the same time, the Council’s proposed draft of art. 39, paragraph 2, seems to provide a direct response to the question whether adherence to standards and certification schemes are sufficient to alleviate the responsibility of controllers. The answer, according to the Council, is negative, to the extent that art. 39, paragraph 2, provides that a certification “does not reduce the responsibility of the controller or the processor for compliance with this Regulation…”.

This provision is consistent with the stance taken by the Council’s vis-à-vis standardisation/certification throughout its reading of the proposed GDRP’s provisions. While in fact the EP and the Commission seemed interested in providing the higher possible level of legal certainty to controllers/processors, the Council has instead shifted focus onto the concept of -accountability of each controller/processor. The general principle of accountability is enshrined in article 22 of the GDPR, which burdens controllers with the obligation to adopt policies and implement appropriate measures “to be able to demonstrate” that the processing of personal data is performed in compliance with the Regulation. This demonstration is downstream of a personalised assessment of the operations of each controller. The Council therefore, unlike the other institutions, in its version of article 22 reiterates that adherence to certification schemes or codes of conduct will only be one of the elements to verify compliance with the Regulation.


Both under the existing Data Protection Directive and (probably) under the forthcoming GDPR, adherence to technical standards is not decisive for making a case of full compliance with the prescriptions of the law. As mentioned above, security is a process that must be conducive to the implementation of effective safeguards of personal data from the relevant risks. Such risks on their end must be identified on a case-by-case basis and the appropriateness of the security measures adopted will then be tested in the specific environment where the processing operations take place, relative to the nature of the data concerned. A crucial step of the security process will thus be the privacy impact assessment upstream and the regular testing of the effectiveness of the security policies against new threats and the available technology solutions at each point in time.

Security standards, weather existing ISMS or future certification schemes adopted under the auspices of the GDPR, will nonetheless provide a basis to build security policies upon, while at the same time providing to the data subjects and other interlocutors of controllers a fair degree of confidence in the reliability of the systems they entrust their data to.