Towards a New Personal Data Breach Notification Framework in the EU

The European Commission, which is the European Union’s (“EU”) executive body, published on January 25 a Proposal for a Regulation (the “Proposal”) on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

Chapter IV of the Proposal on the controller and the processor contains provisions on ‘Data Security’ (Section 1) which details the functions of these two individuals: preserve the security of processing and follow a procedure in the case of a personal data breach (Section 2).

“Everyday life of bits and bytes” by Rene Jakobson.

I. Data Security

Evaluation of the risks

Before implementing technical and organizational measures to ensure data security, the controller and the processor would first have to evaluate the risks (Article 30-2). The preamble specifies that

“[i]n order to maintain security and to prevent processing in breach of this Regulation, the controller or processor should evaluate the risks inherent to the processing and implement measures to mitigate those risks.” (Recital 66)

What are these measures?

Technical and organizational measures and “privacy by design”

The Data Protection Directive (Directive 95/46/EC) gave the controller the duty to “implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access, in particular where the processing involves the transmission of data over a network, and against all other unlawful forms of processing.” (Article 17(1)).

The Proposed Regulation extends this obligation to the ‘data processor’ (Article 30), that is, as defined by of the Proposal,

the person or entity which processes personal data on behalf of the controller“. (Article 4(6)). When choosing a processor, the controller must make sure, that he will provide “sufficient guarantees to implement appropriate technical and organizational measures and procedures in such a way that the processing will meet the requirements of [the] Regulation” (Article 26(1)).

These measures must

ensure a level of security appropriate to the risks represented by the processing and the nature of the personal data to be protected, having regard to the state of the art and the costs of their implementation” (Article 30(1)).

The preamble gives some clues as to how these security measures should be put in place, “both at the time of the design of the processing and at the time of the processing itself.” In order to do so, “the controller should adopt internal policies and implement appropriate measures, which meet in particular the principles of data protection by design and data protection by default.” (Recital 61)

The term ‘data protection by design and by default’ is used through the Proposal at Article 23. The term indeed refers to the technical and organizational measures and procedures that must be put in place.

However, what ‘privacy by default’ exactly is, is not very clear. The Regulation states that ‘privacy by default’ must ensure that only personal data “which are necessary for each specific purpose of the processing” must be collected, and that such data should not be “retained beyond the minimum necessary” for the specific purpose of the processing (Article 23(2)). However, what would the standard ‘privacy by default’ be, and who would set what this default standard would be, is not specified by the Proposal.

The Commission has the power to adopt, where necessary, ‘delegated acts’ specifying “the criteria and conditions for the technical and organizational measures,” (Article 30(3)) so we should expect more detailed explanations of what constitutes “adequate technical and organizational measures” in the near future, probably early July or September 2012 and also better understand what is ‘privacy by default.’

Data Protection Impact Assessment

The controller, or the processor acting on behalf of the controller, also would have an additional duty under Article 33 when processing data which “present[s] specific risks to the rights and freedoms of data subjects by virtue of their nature, their scope or their purposes.” They would have then to prepare “an assessment of the impact of the envisaged processing operations on the protection of personal data.”

The explanatory memorandum preceding the Regulation in the document published by the Commission provides that Article 33 “introduces the obligation of controllers and processors to carry out a data protection impact assessment prior to risky processing operations.” (p. 10 of COM 9(2012) 11 final)

The preamble of the Proposal at Recital 70 gives more indications at to what this data protection assessment would be. It first notes that the general obligation to notify authorities about personal data processing provided for by Directive 95/46/EC would disappear, as it “produce[d] administrative and financial burdens”, while not necessarily improving the protection of personal data. This procedure would be replaced under the Regulation by:

procedures and mechanism … focus[ing] instead on those processing operations which are likely to present specific risks to the rights and freedoms of data subjects by virtue of their nature, their scope or their purposes. In such cases, a data protection impact assessment should be carried out by the controller or processor prior to the processing, which should include in particular the envisaged measures, safeguards and mechanisms for ensuring the protection of personal data and for demonstrating the compliance with this Regulation” (our emphasis).

Recital 71 gives as an example of an instance calling for a data protection impact assessment the establishment of “large scale filing systems,” and Recital 72 states that sometimes a data protection impact assessment should be made beyond a single project. Such would be the case when “public authorities or bodies intend to establish a common application or processing platform,” that is, when government databases are being interconnected, or if “several controllers plan to introduce a common application or processing environment across an industry sector or segment or for a widely used horizontal activity,” that is, the interconnection of private databases.

We know that only data processing likely to present ‘specific risks’ to the rights and freedoms of individuals would trigger that assessment. What are these risks? Recital 38 provides that

“[t]he legitimate interests of a controller may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding. This would need careful assessment in particular where the data subject is a child, given that children deserve specific protection” (our emphasis).

Is this ‘careful assessment’ the ‘data protection impact assessment’ of Article 33? Processing the data of a child indeed carries specific risks, such as the difficulty of obtaining an enlightened consent to data processing, and increased risks for the privacy of the child.

 II. Notification of Personal Data Breaches

The Proposal introduces an obligation to notify personal data breaches (Articles 31 and 32).

Personal Data Breach Notification to the Supervisory Authority

Compared to the first mention of that notification obligation in the EU legal framework (see Article 4 of the “e-Privacy Directive”, the Directive on privacy and electronic communications 2002/58/EC, as amended by Directive 2009/136/EC on November 25, 2009), the Draft Data Protection Regulation broadens the scope of the breach notification obligation. Where the e-Privacy Directive obliges providers of publicly available electronic communications services to notify personal data breaches to their national data protection authority, and to the data subject if the breach is “likely to adversely affect the personal data or privacy” of the data subject, the Regulation compels data controllers to include in their notification a description of the nature of the breach (Article 31(3)(a)), that is, “the categories and number of data subjects concerned and the categories and number of data records concerned,” and also describe the consequences of the breach (Article 31(3)(d)). The processor does not have a duty to directly notify the supervisory authority. However, he must “alert and inform the controller immediately after the establishment of a personal data breach” (Article 31(2)).

The notification would also have to include the identity and contact information of the data protection officer or of another contact point (Article 31-3(b)).

The notification by the controller to the supervisory authority would not merely be a passive report: it would also have to recommend mitigating measures to the personal data breach (Article 31(3)(c)) and describe the measures proposed or taken by the controller in order to address the breach (Article 31(3)(e)). Odly, Article 31(3)(c) states that the controller must recommend measures to mitigate the effects of a breach, yet does not specify to whom these recommendations must be made. It seems odd that the controller would “recommend” measures to the supervisory authority. Should Article 31(3)(c) be interpreted as requiring controllers to recommend measures to themselves? Yet, nothing is said in the Proposal about a duty for controllers to implement these measures.

Pursuant to Article 31(1) of the Proposal, the data controller would have to notify the supervisory authority of a personal data breach no later than 24 hours after having become aware of it, if “feasible”: a rather short deadline not likely to be often “feasible.” If the notification could not be made within 24 hours, a “reasoned justification “would then have to be joined.

In the United States, almost all States have enacted data breach notification laws, yet none set such a short timetable. New York state law (N.Y. GEN. BUS. LAW § 899-aa) requires that to disclose a breach “in the most expedient time possible and without unreasonable delay.” Michigan state law (Identity Theft Protection Act 452 of 2004) acknowledges that a “delay is necessary in order for the person or agency to take any measures necessary to determine the scope of the security breach and restore the reasonable integrity of the database.” However, the notice is required “without unreasonable delay” after completion of these measures.

The Federal Trade Commission described in an informal note about the draft of the EU Proposal published last December what a company would have to accomplish in order to comply with the short 24 hours delay. If a company were to discover at the beginning of a business day that a data breach had occurred, it would have to determine what happened, how many individuals were affected, identify them and send them a notice by the beginning of the next business day. Failing to do so would carry a heavy fine under Article 79(6)(h), EUR1,000,000, or, for a company, up to 2% of its annual worldwide turnover. One can only imagine the panic of a controller discovering a breach, and facing that daunting list of duties to accomplish in the next 24 hours. Hardly “feasible” indeed, and the controller should be able to write a “reasoned justification” as required by article 31(1) if finally notifying the data breach past the 24 hours delay. Therefore, notifications made no later than 24 hours after their discovery should be rare in practice.

The Directive 2009/136/EC amending the e-Privacy Directive states that “[t]he subscribers or individuals whose data and privacy could be adversely affected by the breach should be notified without delay in order to allow them to take the necessary precautions” (Recital 61), but does not give a timeframe. As the Regulation would repeal the data protection Directive, but not the e-Privacy Directive, there could be a conflict between the Regulation and the e-Privacy Directive.

Documenting the Data Breaches

The controller has to document any personal data breaches, including only “information necessary for that purpose” (Article 31(4)).

Data Breach Notification to the Data Subject

After having notified the supervisory authority of the data breach, the controller must also inform the data subject about it, if the breach “is likely to adversely affect the protection of the personal data or privacy of the data subject” (Article 32(1)).

But what constitutes a breach that “adversely affects the personal data or privacy of a data subject”? A breach that “could result in, for example, identity theft or fraud, physical harm, significant humiliation or damage to reputation,” according to Recital 67.

If one could objectively define what an ‘identity theft’, ‘fraud,’ or ‘physical harm’ constitute, as these are criminal activities punishable under the laws of the 27 Member States, what would constitute ‘significant humiliation’ or ‘damage to reputation’ leads to a more subjective interpretation. A data subject may state that a particular breach leads to a significant humiliation for her, whereas, in the controller’s opinion, the breach leads to some humiliation, but not a ‘significant’ one.

Could a Data Breach be a Defamation?

Interestingly, data breach law may collide with the Member States libel and defamation laws. As an example, article 29 §1 of the French law of July 29, 1881 defines libel as “any allegation or imputation of a fact that undermines the honor or reputation of the person or body to which the act is attributed.” Imagine that a personal data breach lead to the public exposure of Mrs. DataSubject’s taste for deep-fried pickles. Pretty harmless, except for your arteries of course, and Mrs. DataSubject’s reputation, since she happens to be the long-time president of ‘Eat Healthy Club’, a member-based association of die-hard organic and fat-free food enthusiasts. As a result of the breach, she has to step down from her tenure. Mrs. DataSubject is French, and she endured indeed a significant humiliation because of the breach, as the breach undermined her honor and reputation. Yet the controller would have no way to know that, and penalties may nevertheless be imposed to him. Under article 79(6)(h), failure to inform the data subject would allow the supervisory authority to impose a fine as high as EUR1,000,000, or 2% of a company’s annual turnover, enough to buy a lifetime supply of fried food, which shows that the stakes are high for data controllers.

Would the French libel law apply in this case? The courts would have to interpret a breach as a publication, and it is unlikely they would be inclined to do so. If the French libel law would apply, would the fine be imposed only if Mrs. DataSubject is able to prove that the breach affected her reputation, or only if she is able to prove that the breach affected her reputation, and that the controller knew it would do so? We cannot answer that question yet. Also, imagine a company facing a huge penalty, but having the pockets deep enough to hire an entire defense team to prove that the controller did not know about Mrs. DataSubject whatsoever. It will be interesting to see how the Regulation would be interpreted by the Member States courts.

A Safe Harbor?

The notification breach would not merely be a document informing the supervisory authority about the breach. It would also have to describe which “appropriate technological protection measures” the controller has implemented, if the controller claims safe harbor. However, what these measures would have to be is not clearly defined by the Proposal of Data Protection Regulation.

The duty of the controller is not only a passive one, as the notification should recommend measures to mitigate the adverse effects the breach may have (Article 31(3)(c)), and would have to describe the measures the controller took, or proposes to take, to address the issue.

There is a safe harbor provision from that requirement: notifying the data subject of the breach is not necessary “if the controller demonstrates to the satisfaction of the supervisory authority that it has implemented appropriate technological protection measures, and that those measures were applied to the data concerned by the personal data breach.” (Article 32(3)).

What constitute ‘appropriate’ measures is not defined by the Proposal. Recital 69 provides a small clue by implying that ‘appropriate technological protection measures’ would “effectively limit . . . the likelihood of identity fraud or other forms of misuse”. Would these ‘other forms of misuse’ include the ‘significant humiliation’ or ‘damage to reputation’ of Recital 67? In that case, the national libel law of the Member States would not have to come to play and a breach could lead to a damage to reputation, regardless of whether there has been a publication – quite a novel legal concept.

Also, it is not clear whether these ‘appropriate technological protection measures’ are the same as the ones described by Article 22(2)(b). Article 22(2)(b) does not specify that these measures must render the data unintelligible, yet Article 32(3) specifies that in order to benefit from being exempted from notifying data subjects concerned by a data breach, the technological protections measures must render the data unintelligible to anyone accessing it unlawfully.

At any rate, for a company to make the data “unintelligible” (to encrypt it) cannot be considered as the solve-it-all measure that would automatically exempt a company from the requirement to notify data subjects of a data breach. One must examine all the circumstances surrounding the breach and determine whether, based on the evidence, a significant risk was created for the potentially affected individuals as a result of it. Neither is it sufficient for a data controller to demonstrate that it applied those measures to the data concerned by the data breach since the sole fact of applying those measures does not constitute a guarantee that that data will become unintelligible to anyone. Also, one of the criteria to assess the sufficiency of these ‘appropriate technological protection measures’ is whether they were applied to the data concerned by the data breach, i.e. before the data breach occurred.

This post is a first review of the data security aspects of the Proposal that is currently debated in the European Parliament, and commented upon by several data protection institutions, such as the Article 29 Working Party and the United Kingdom Data Protection Authority (the Information Commissioner’s Office). We will report about these comments in the next few weeks.

Marie-Andrée WEISS & Cédric LAURANT


2 Responses to “Towards a New Personal Data Breach Notification Framework in the EU”
Check out what others are saying...
  1. […] to Directive on privacy and electronic communications 2002/58/EC in Directive 2009/136/EC (more details in earlier posts in this blog) that applies to telecommunications companies and Internet service […]

  2. […] to Directive on privacy and electronic communications 2002/58/EC in Directive 2009/136/EC (more details in earlier posts in this blog) that applies to telecommunications companies and Internet service […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

  • Blog authors

  • Copyright notice

    © Copyright 2010-2014 "Information Security Breaches & The Law".
    All rights reserved, unless noted otherwise under each author's post, page or other material.
    If you would like to discuss licensing terms, contact us at: info [at] security-breaches [dot] com.

  • Enter your e-mail address here to follow this blog and receive notifications of new posts by e-mail.

  • The “Global Information Security Breach Professionals” Group on Linkedin

  • Wordpress Blog Stats

    • 46,846 hits
%d bloggers like this: