Arguably the most significant piece of security legislation in Europe is the GDPR, which came into effect in 2018. Actually, there are two GDPRs, because of Brexit: the original EU version and the UK one. Before the purists wade in and the pile on begins, yes, I know, strictly speaking the GDPR isn't security legislation - that wouldn't do it justice - it's more than that. It's about the overall concept of regulation of processing of personal data and the end to end information lifecycle, but security is key part and, I believe, elemental to everything within the concept of data protection.
The way the GDPR works is to impose principles-based requirements on "controllers" and, through various routes, on "processors" of personal data. Breaking this down a bit further:
A controller decides the purpose and means of personal data processing.
Processors perform processing activities on behalf of controllers.
Personal data is information that relates to identified, or identifiable, living individuals. Such people are called "data subjects".
Processing is the performance of activities on personal data wholly or partly by automated means, or by non-automated means where the data forms part of a filing system.
Check out Article 4 of the GDPR to understand more about these concepts, but what this all means is that the GDPR is about protecting people from harms that can result from the processing of their personal data. Keep this in mind at all times, as its helps to make sense of how the GDPR relates to security breaches.
Returning to the idea of principles-based regulation, the GDPR is based around seven core principles. One of the principles is called "integrity and confidentiality", which are ideas borrowed directly from the world of operational security (although the security literate readers amongst you will immediately think "broken triad", or "what's happened to availability?" - don't worry, its in there). It requires controllers to ensure the appropriate security of personal data that is being processing, to protect the data from wrongful use, alteration or loss. This means that controllers have to protect personal data from hackers, eavesdroppers, virus writers, rogue insiders, negligence, accidents etc. This includes protection of the technologies, networks and infrastructures that enable or support processing, as well as paper files that constitute filing systems. See Article 5 for more information.
So what constitutes appropriate security? The GDPR aligns this to the issue of risks to the rights and freedoms of people, such as the right to privacy, the right to protection of property, the right not to be discriminated against - and so on - saying that appropriate technical and organisational measures ("ATOMs") must be implemented to ensure a level of security that is appropriate to the risk having regard to the overall context of processing. It isn't highly prescriptive of what these ATOMs should be, but it does provide an indicative steer of the kind of issues that should be addressed, such as the use of encryption, the need for processing systems to deliver conventional operational security services and ongoing controls testing. See Article 32.
As we all know far too well, security breaches are inevitable, even in the best run organisation. Therefore, the GDPR requires controllers to adopt systems and operations for incident detection, management and response. Following the detection of an incident, it has to be assessed to understand whether it constitutes a "personal data breach". If it does, the breaches reporting rules may apply. There are two kinds of reports, breach notification and communications rules. Notification means the reporting of breaches to the data protection regulators. Communications means informing the impacted people. In both cases, this should be done without undue delay, but it is subject to a 72 hour long stop for notifications, commencing from the point of understanding that a personal data had occurred.
Breach reporting is conditional on the breach meeting the requisite levels of seriousness, however, which are aligned to the risks to rights and freedoms. The threshold for notifying breaches to the regulators is lower than for communicating them to the people affected. There are also some carve outs and exceptions to these rules. Personal data breach logs must always be maintained, to provide the regulators with a reference point, should they need to perform an investigation. See Articles 33 and 34.
While controllers have responsibility for compliance with the integrity and confidentiality principle and for breach reporting, the rules in Article 32 applies to controllers and processors. Additionally, controllers are required to cascade the requirements of the security rules to processors that operate data processing services on their behalf. This covers Cloud service providers, data analytics providers, storage providers, application providers, systems integrators, managed service providers, security operations centres and countless other kinds of businesses and service providers. This is generally done through contracts that contain the prescribed requirements and which are preceded and followed by relevant due diligence. Processors have to ensure that their operations meet the GDPR's security requirements and they have to support the controller with its compliance, such as by reporting incident personal data breaches helping the controller with the incident management and response. See Article 28.
If things go wrong and there is a security breach, the regulators and impacted persons can take action. Controllers and processors are both at risk. The regulators can impose fines, or take other enforcement action, and they can be sued for compensation by the impacted persons. The maximum fine in a security breach situation can be 4% of the annual worldwide turnover of a controller that operates as a business, or £17.5M in the UK, or €20M in the EU, whichever is the higher, but if the controller forms part of an undertaking (that is a group working together as part of an economy unit, such as a group of companies), the fine can be based on the turnover of the undertaking as a whole. Fine levels are tiered and some are subject to a lower percentage or cap. See Article 82.
Finally, let me conceptualise the reason why I say that the GDPR is arguably the most significant security legislation in Europe. As you will see as this series of blogs evolve, there are many pieces of impressive security legislation to consider, but most of it is sectoral and does not provide the public with causes of action. In contrast, the GDPR is omnibus, covering every sector of the economy, every part of society and every single person in Europe from the second they are born (and people out of Europe too), with every single one of us having legal rights of security protection, security transparency (breach communications) and security remedies (we can sue and take complaints to the regulators).
The only qualifiers to this observation, which is why I say "arguably", is that in many respects the GDPR might be regarded as a paper tiger, due to relatively ineffective regulatory enforcement thus far, plus there are significant barriers standing in the way of people who want to sue for compensation.
So perhaps I should say instead that "on paper at least" the GDPR is arguably the most significant piece of security legislation in Europe.
