Incident Response and the GDPR

The Commission's original draft Regulation included explicit support for the work of computer security and incident response teams, recognising that such activities were a legitimate interest that involved processing of personal data. Furthermore the legal requirements implied by using the legitimate interests justification (notably ensuring that those interests not be overridden by the rights and interests of the individuals whose data are processed) are a good match for existing and developing computer security practice (see my FIRST talk from last year). The latest text of the Regulation maintains that support (explicitly in Recital 39) and adds some helpful new features, though it still leaves some uncertainties.

The text recognises that using "pseudonyms" can "reduce the risks for the data subjects concerned and help controllers and processors meet their data protection obligations" (Rec 23a). Pseudonyms are defined as

processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information, as long as such additional information is kept separately and subject to technical and organisational measures to ensure non-attribution to an identified or identifiable person (Art 4(3b))

In security and incident response work, most of the identifiers used are pseudonyms, since an organisation looking at external IP addresses communicating with its own systems is highly unlikely to be able to attribute those to individuals.

When investigating attacks on their own systems, teams often discover the IP addresses of computers outside the EEA that are likely to be compromised. Since European law may consider such IP addresses to be personal data (as discussed below this is still uncertain) it is not clear whether informing their owners of the problem constitutes an unlawful export of personal data! To date, teams in the UK have at least had the Information Commissioner’s reassurance that it is acceptable to return personal data to where it came from. The Regulation now permits incident notification to be done on the same basis - legitimate interests - whether or not the affected organisation is in the EEA. However the latest text requires that supervisory authorities be informed when exports take place on this basis (Article 44(1)(h)). Regulators should be careful not to interpret this requirement in a way that makes impractical an activity that benefits everyone.

As in my blog post on that topic, the introduction of a breach notification requirement also provides strong encouragement to all data controllers to have an effective incident response process.

Unfortunately the latest draft fails to clarify two problems that were highlighted in the original Commission version. There is still no clear explanation of when information associated with IP addresses will constitute personal data and fall within the Regulation. Recital 24 merely warns of the possibility that "Individuals may be associated with online identifiers provided by their devices, applications, tools and protocols, such as Internet Protocol addresses, cookie identifiers or other identifiers such as Radio Frequency Identification tags". With contradictory court rulings from several European countries on the status of IP addresses in log files it is likely that opportunities to prevent and mitigate privacy breaches will be missed because of uncertainty whether information sharing (particularly across borders) may breach data protection law. With ENISA finding privacy and data protection law the most cited reason for not exchanging data between CERTs, greater clarity and consistency would have been welcome.

Finally, the text is still contradictory on the status of national and Government CERTs. Recital 39 explicitly includes "public authorities" in its list of those for whom computer security is a legitimate interest, but recital 38 states that public authorities may not use the legitimate interests justification in the performance of their tasks. Using different justifications for different types of CERTs would create barriers to information sharing between them, so it important that regulators resolve this contradiction in a way that allows national and Government CERTs to maintain their position as trusted peers in national and international CERT networks.