Originally posted on: Security Law
Critical questions from the incident include whether it constitutes a “personal data breach” within the meaning of the General Data Protection Regulation (GDPR) and, if so, whether impacted organisations have a duty to formally notify regulators, or to issue breach communications to the individuals whose data were affected.
What is a security breach?
These questions cause us to reflect for a while, about what a security breach is. We can easily fall into the trap of thinking that a security breach is defined by the essence of a cyber-attack, which involves a malicious attack on network and information systems, the data within or their users. Seeing that for many years the dimensions of public debate about security has been dominated by the topic of cybersecurity, the goal of which is to protect against cyber-attacks, this would be an understandable and natural starting point and, in part, it could explain George Kurtz’s statement on 19th July that the Crowdstrike incident “was not a cyberattack”. However, a more rounded view is that a security breach can have non-malicious causes, so that the goals of security include protections against hazards, acts of God and accidents. With this view of security, we are caused to focus not simply on the causes of insecurity, but also the desired qualities of security and the consequences of insecurity.
The qualities of security and the consequences of insecurity are reverse sides of the same coin and in operational terms most security professionals will likely point to the “CIA Triad” when trying to explain what this means, which encompasses confidentiality, integrity and availability. If these concepts are applied to information assets, such as networks, information systems and data, then confidentiality is the property of these assets being available only to authorised users, integrity is the property that allows changes to be made to these assets only by authorised users and availability is the property of these assets being usable by authorised users when they need them, as bounded by their rights and privileges.
When we look at things in this way and if we apply the various sources of risk to the various security properties, we soon arrive at a clear proposition, which is that a security breach can encompass a non-malicious incident that renders information assets unavailable to authorised users. In that case, the Crowdstrike incident can be fairly described as a security breach by the organisations and individuals affected by it, albeit it was not a cyber-attack as Mr Kurtz observed.
Having arrived at this conclusion, we must start to look at the incident through a legal lens. There are myriad laws around the world concerning security breaches and the GDPR has two interconnected pathways to explore. The first is the basic legal duty for security, which forms part of the GDPR’s data protection principles. The second is the legal duty for handling personal data breaches.
The basic legal duty for security in the GDPR
The basic legal duty within the data protection principles places a requirement on the controllers of personal data to ensure appropriate security of personal data, which includes “protection … against accidental loss, destruction or damage” (see Article 5.1.(f)). If we consider this sequence of ideas, what do they mean? Do they refer to different concepts, so that loss must be treated differently from destruction or damage? But how could that be so, seeing that something that has been destroyed must also have been lost? To bypass this problem, perhaps we would say that loss mean a loss of possession of data, so that it is different outcome to the destruction of data? I make these initial observations about the meaning of words to signpost a critical issue, which is that we need to understand the approaches, methods and techniques for legislative interpretation before we arrive at our conclusion. As will be seen later, the purposive approach should not be overlooked.
The basic legal duty is summarised as “integrity and confidentiality” and for completeness, this is how it appears in the legislation:
5.1. Personal data shall be:
(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).
This begs the question what has happened to the availability component of the CIA Triad? Does this mean that the basic legal duty does not extend to ensure the availability of personal data, so that non-availability would not constitute a breach of the duty? If that is the position, then it constitutes a massive and surprising gap in the duty. Yet, if data is lost, it is not available. Likewise if it is destroyed and, to a certain extent, likewise if it is damaged.
In part, the answer is found later on in the legislative text, where a risk-based approach to the security duty is described along with various indicative security controls, including “the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services” and “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident” (see Article 32). Why would the legislation identify controls for availability if availability did not form part of the basic legal duty? The obvious way to reconcile Articles 5.1(f) and 32 is to say that availability forms part of the basic legal duty despite the absence of the word in the summary of A.5(1)(f). This conclusion can be reinforced by the fact that the protections described in A.5.1(f) are preceded by the wording “including”, which suggests that they are indicative, not exhaustive, and by the purposive approach to legislative interpretation, mentioned earlier.
The legal duty to handle personal data breaches
The legal duty for handling personal data breaches involves the notification of them to the regulator, except if they are unlikely to result in a risk to the rights and freedoms of individuals, and communicating high-risk breaches to those persons, with both reports needing to take place without undue delay (see Article 33 and 34). Immediately, we see a critical point: it would be wrong to say that all personal data breaches require reporting.
A personal data breach is defined as a “breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure or, or access to personal data transmitted, stored or otherwise processed” (see Article 4(12)). The same problem arises as with A.5.1(f), which is that availability is not specifically mentioned. This raises the same questions as before; it creates the same problematic gap in the legislation; and it involves the same tension with the indicative security controls.
- Basic duty – GDPR A.5.1(f)
- 5.1. Personal data shall be: (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage,using appropriate technical or organisational measures (‘integrity and confidentiality’).
- Personal data breach – GDPR A.4(12)
- ‘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;
When we put the legislative text side by side, we must conclude, firstly, that the concept of security includes the protections listed in A.5.1(f) and that, secondly, a personal data breach is a breach of the concept of security. Therefore, another issue arises: referring to the underlined words in the table above, are the consequences of insecurity that constitute a personal data breach materially different to the security protections that are required by A.5.1(f)? If they are not materially different and A.5.1(f) includes availability breaches, then so must A.4(12).
At a high level, if the protections in A.5.1(f) are indicative and not exhaustive (due to the word “including”, as observed earlier), then there might be material differences, but due to the Crowdstrike incident being an accident, there is no material difference on the key point of accidental loss.
Therefore, we arrive at this logic:
- The basic duty in A.5.1(f) describes indicative security outcomes.
- The indicative controls for security in A.32 include ones for availability of processing systems and services and for the timely restoration of availability to data after an incident.
- Availability forms part of the basic duty.
- In the context of the Crowdstrike incident, where this led to the non-availability of personal data, it is best described as an accidental data loss.
- The basic duty involves protections against accidental data loss.
- Accidental data loss also constitutes a personal data breach.
The purposive approach to legislative interpretation
As the above discussion illustrates, it is easy to get lost in a rabbit warren of analysis about the meaning of words and phrases, but an established approach to legislative interpretation provides a clear pathway through the puzzle. That is the purposive approach. The purposive approach is regularly applied by the Court of Justice of the EU, it applies to the interpretation of retained EU law in post-Brexit UK and it provides a foundation stone for the development of regulatory guidance and the taking of regulatory enforcement action in both the EU and UK. Its objective is to interpret legislation in-line with the legislation’s overriding purpose, rather than by reference to the strict literal meaning of particular words and phrases if doing so would conflict with the overriding purpose.
We must always keep in mind the fact that the overriding purpose of the GDPR is the achievement of a high level of protection for personal data, as part of the protection of the rights and freedoms of individuals. These achievements rest on several key pillars, including a focus on regulating control over data, transparency about high-priority issues and the empowerment of regulators and individuals to counterbalance the powers of controllers.
With these objectives in mind, what is the compelling reason to exclude non-malicious availability breaches from the ambit of personal data breaches and the pathway they provide to post-incident transparency and the empowerment of regulators and individuals? The only reason would be to take a semantically literal approach to the interpretation of personal data breaches, with the argument being that the word “availability” is absent in the definition, but is that compelling? A semantically literal approach to legislative interpretation is the antithesis to the purposive approach and if it results in the conclusion that the Crowdstrike incident could not constitute a personal data breach, it will undermine the high level of protection for individuals and their rights that the law requires, while also ignoring the fact that the list of indicative security controls include ones for availability. A semantically literal approach fails the legislation’s purpose, because it does not see the wood for the trees.
With a purposive approach, the idea of data loss within the definition of a personal data breach can easily be interpreted as covering the non-availability of personal data. This is because when loss is suffered, utility disappears, which is the essence of availability. As well as being fully consistent with how the GDPR addresses availability within the indicative list of security controls, it is also consistent with the nature of data loss in a processing system, because when we talk about this situation what we are often dealing with is an inability to gain access to data, either due to an availability breach, or loss caused by an integrity breach that changes the character of data so that its original character is lost. The loss of encryption keys can also cause loss through non-availability. We can also have loss where a copy of data is exfiltrated by an adversary, but the original remains in the controller’s possession, which might be thought of as “half loss”. This reveals that the idea of loss is highly nuanced.
By extension, the purposive approach allows the idea of data loss to encompass the non-permanent non-availability of data, i.e., temporary loss of availability. Among other things, it is easy to conceive of situations whereby the impacts of temporary loss can be as harmful as permanent loss, i.e., where time is of the essence, which can span a multitude of concerns, from medical emergencies to time-limited opportunities and offers, such as holidays and auctions. A temporary system outage to a payroll, benefits or banking system that causes cash flow problems can be catastrophic for some people. This is why the indicative security controls require timely restoration of security services after an incident.
Finally, if we reach the conclusion that the Crowdstrike incident is incapable of constituting a personal data breach where that results in temporary non-availability, we are forced to conclude that the controller avoids performing the breach reporting assessments under GDPR A.33 and A.34, which in turn avoids breach reporting all together. Would avoiding these assessments make any sense, or even be conscionable, where a hospital is affected, or a retail bank, for example? Or is it more likely that the purposive approach will support the conclusion that temporary non-availability caused by an accident can constitute a personal data breach, to require the performance of the A.33 and A.34 assessments? My view is that is the correct landing point based on sound legislative interpretative.
Moreover, as indicated earlier, not all personal data breaches are reportable. Reporting turns on the nature of risks to rights and freedoms. Thus, the purposive approach when applied to the Crowdstrike incident does not create a situation of every instance of non-availability having to be reported. Instead, it causes the A.33 and A.34 assessments to be performed, which enable appropriate reporting decisions to be taken. Why would the GDPR not want this?
Contact us for more information.
