Last updated: 
3 weeks 5 days ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Data Protection Proposal: Privacy Breaches

Wednesday, June 6, 2012 - 11:14

In dealing with breaches of privacy the Commission’s enthusiasm to protect and reassure Internet users seems to run the risk of having the opposite effect. Article 4(9) of the proposed Regulation defines

'personal data breach' means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed;

According to Article 31, every personal data breach must be reported to the national privacy regulator (in the UK, the Information Commissioner), and a written explanation provided if this notification is not sent within 24 hours. Those breaches that are “likely to adversely affect the protection of the personal data or privacy of the [individual]” must then be notified to the individual “without undue delay” (Article 32(3) notes that this may not be needed where the personal data were encrypted so as to be “unintelligible to any person not authorised to access it”). The notification to the regulator must at least

(a) describe the nature of the personal data breach including the categories and number of data subjects concerned and the categories and number of data records concerned;

(b) communicate the identity and contact details of the data protection officer or other contact point where more information can be obtained;

(c) recommend measures to mitigate the possible adverse effects of the personal data breach;

(d) describe the consequences of the personal data breach;

(e) describe the measures proposed or taken by the controller to address the personal data breach.

The notification to individuals must include at least items (b) and (c) from that list.

The first problem with this timetable is that for many breaches the required information will not be known within 24 hours. If a system containing different types of personal data has been compromised it may take considerable forensic investigation to work out which information, and about which users, was actually disclosed to the intruder. Accurate answers to (a), (c), (d) and (e) cannot be provided until that results of that investigation are known. To meet the Regulation’s 24 hour target it seems likely that organisations’ answers will be estimates at best and, depending on their other motivations, may either be too optimistic or too pessimistic.

It is also important not to rush the process of notifying affected users. If organisations feel under pressure to publish something, they are likely to simply announce that they have suffered a breach affecting the security of personal data.  As many past examples have shown, this kind of bland announcement is more likely to worry users and make them suspect the worst than to help them take appropriate measures to protect themselves.

Concentrating on notification also risks changing the priorities of those dealing with the incident. In most incident response plans, the first step is to contain the incident, to stop it spreading and increasing in severity. After that has been done, the organisation can secure evidence, investigate the breach and provide appropriate notifications informed by what has been discovered. If, instead, the organisation’s first priority is notification to comply with the law, then containment may be done later or less carefully so the scale and impact of the incident may actually be worse than it needed to be. Recital 68 does recognise that “the need to implement appropriate measures against continuing or similar data breaches may justify a longer delay” in notifying users; it will be important to ensure that this balance is recognised in implementing the Regulation.

It is interesting to compare the Regulation’s approach to breach notification with the approach taken in amending the Privacy and Electronic Communications Directive in 2009 (Directive 2009/136/EC); this had the same objectives but only applied to electronic communications service providers. In 2009 the requirement was for breaches to be notified to the regulator “without undue delay”: the decision on actual timescales was left to those regulators. In the UK, the Information Commissioner’s guidance is that only serious breaches need to be reported immediately, with minor breaches being reported monthly as part of a continuing log to avoid "unnecessary delay". Clearly this is significantly different. Since the breach notification provisions of the 2009 Directive should now be in force in all Member States, results from those should at least be used to inform the development and implementation of the provisions in the Regulation. The new legislation must encourage organisations to help their users, not force them into early publication of either alarming or falsely reassuring information.