Data Protection Proposal: Incident Response

The Commission’s proposed Data Protection Regulation seems very positive for Incident Response. Indeed Recital 39 explicitly supports the work of Incident Response Teams:

The processing of data to the extent strictly necessary for the purposes of ensuring network and information security … by public authorities, Computer Emergency Response Teams … providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the concerned data controller. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems.

The mention of “legitimate interests” indicates that such activities would be justified by Article 6(f) of the Regulation (as was suggested in my paper on Privacy and Incident Response for the equivalent Article 7(f) of the current Directive), and now also supports necessary transfers of information outside Europe (for example when dealing with an attack coming from elsewhere in the world), since those, too, are permitted for “legitimate interests” by Article 44(1)(h). International transfers covered by this article are required not to be “frequent or massive” but this will rarely be the case when responding to an incident, and “appropriate safeguards”, such as transferring to a trusted partner CERT, must be applied. Although a similar recital about Incident Response was recently added to the Electronic Commerce Directive, having it in the main Data Protection Regulation confirms that it applies to all CERTs, not just those associated with electronic communications networks.

For those organisations that do not have an Incident Response capability, Recital 69 seems to encourage them to establish one, since if an organisation suffers a security breach that affects personal data, it will be judged on whether it has “implemented and applied appropriate technological protection and organisational measures to establish immediately whether a personal data breach has taken place”. An Incident Response capability could well be one of those organisational measures.

The Regulation also appears to address one of the unusual features of Incident Response – that although it often involves identifiers such as IP addresses that are regarded as personal data, the Incident Response team will rarely be able to identify the individual to inform them that their personal information is being processed. Article 10 recognises that this situation may arise, and clarifies that “if the data processed by a controller do not permit the controller to identify a natural person, the controller shall not be obliged to acquire additional information in order to identify the data subject for the sole purpose of complying with any provision of this Regulation”. It would be perverse indeed if a law on privacy compelled Incident Response teams to seek out the personal identities of all the Internet users who may be associated with incidents!

There is one concern in the apparent contradiction that Recital 39 encourages “public authorities” to also use the “legitimate interests” justification for their incident response activities, while Article 6(f) says that it may not be used by public authorities. If different justifications are used by different CERTs this may create problems for transferring information between them, since a CERT processing information under Article 6(f) – required to ensure such processing is not overridden by the fundamental rights of the individual – may be reluctant to share information with a CERT operating under Article 6(e) which is not subject to that limitation. The potential for difficulties if national CERTs were handled differently from others was highlighted in ENISA’s recent report on legal aspects of information sharing and will need to be borne in mind in implementing this part of the legislation.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *