Security, fines, and systems-based regulation—the UK’s new legal battleground

The regulation of data protection in the UK enters a new era on 6 April when the Information Commissioner’s power to levy fines of up to £500,000 for breaches of the Data Protection Act (DPA) comes into effect. While the legislation introducing the fine refers to breaches of the data protection principles, we can expect that the fine will be targeted mostly at security breaches and data loss and the other terrors addressed by the seventh data protection principle.

Most data controllers operating in the UK do not understand the true nature of the emerging battleground for security. This article seeks to address this problem by focusing on the concept of “systems-based regulation.”

Controllers who understand the ideas and philosophies within systems-based regulation will be well equipped to defend regulatory action. Those who do not may condemn themselves to punishment and adverse publicity.

The fine in context
The commissioner’s power to fine controllers is contained in section 55A of the DPA, which was inserted by the Criminal Justice and Immigration Act 2008 (CJIA). The catalyst for change occurred in November 2007 when Her Majesty’s Revenue and Customs, a government agency, revealed that it had lost two optical disks containing a database relating to 25,000,000 UK citizens. The amendments within the CJIA form part of the official reaction to this event, which has resulted in the building of a new legal framework for data security in the UK. Other developments include new rules on breach disclosure and legislation for compulsory inspections and audits (see the Coroners and Justice Act 2009).

The catalyst and context help to explain why the fine will be targeted mostly on security breaches and data loss, but there are other reasons for this conclusion, including the choice of words in section 55A, which gears the fine towards security, and the fact that these incidents continue to attract significant press, public, and political attention.

The statutory framework for the fine
The legal advisors to a data controller that is facing a fine will wish to look very closely at the wording within section 55A. Breaking the section down to its constituent parts, a fine can be imposed on a controller if:

• The Information Commissioner is satisfied that there has been a serious contravention of the data protection principles, and
• He is also satisfied that the contravention was of a kind likely to cause substantial damage or distress, and
  The contravention was deliberate, or
• The controller (a) knew or ought to have known that (i) there was a risk that the contravention would occur and (ii) the contravention would be of a kind likely to cause substantial damage or distress, but (b) it failed to take reasonable steps to prevent the contravention.

The wording within section 55A does not limit the fine to security breaches and data loss, so in theory it would be possible for the commissioner to impose one for any kind of breach of the DPA. However, when the implications of the words “satisfied,” “serious,” and “substantial” are understood, it soon becomes clear that section 55A is mostly about security; from an evidential perspective these words are highly significant and it is difficult to see how the fine will attach itself to non-security-related matters, albeit it is recognized that many controllers have shown a clear tendency to capitulate in the face of regulatory action irrespective of the merits of the case, indicating that they many not challenge fines for non-security-related breaches of the principles.

Systems-based regulation—when the commissioner investigates
Systems-based regulation is the preferred approach to regulation of the DPA. Understanding systems-based regulation enables the controller to focus on the issues that really count and to predict the course of regulatory action from the commencement of an investigation through to its final conclusion. In the field of data security, controllers that master the ideas and philosophies within systems-based regulation can defeat regulatory action, even when they have suffered an operational failure.

Systems and operations
A system is a rule. Controllers that are operating on the right side of the law will be able to point to a legally compliant, fully documented set of rules or systems, covering the regulated area. In the area of data security the legally compliant controller will have documented rules about management responsibilities, culture, employee risks, third-party risks, technological controls, the handling of security breaches, and so on.

Operations are the actual processes and steps taken by the controller during the course of its business and everyday activities. As far as the law is concerned, operations should be conducted in accordance with the systems. If they are, they too will be legally compliant. So if, for example, the systems say that employees shall be trained on the safe use of computers, operational processes will have to be put in place to achieve this and to enable retrospective verification that this has been done.

The focus of systems-based regulation is therefore rules and paperwork and as far as the UK is concerned, regulation of data security has been and will continue to be overwhelmingly systems-based. There are three key reasons for this.

• First, the legislation itself skews regulation towards a focus on systems. While it is true to say that there are regulatory tools in the DPA that are operationally focused, the primary tools are systems focused.
• Second, the commissioner has limited resources, but many cases to investigate. Focusing on systems is much more efficient than focusing on operations.
• Third, the natural human tendency to take the easiest path applies as much to regulators as it does to everyone else. It is easier for regulators to reach unimpeachable conclusions about systems than it is about operations, due to the clarity of the benchmarks against which systems are judged.

These factors help to explain why the commissioner focuses mainly on systems during the course of regulatory action concerning security. Those who have experienced regulatory action in this area will recognize that after the commissioner has taken a decision to investigate he will ask the controller to explain itself and deliver up security policies and related documents. This is systems-based regulation in action. At this point in the investigation it is the quality of the controller’s systems for data security that are in focus.

Operational failures and legally compliant systems
In the area of data security it is operational failure that brings controllers to the commissioner’s attention. However, due to the way in which the legal obligations for security are structured in the DPA, a controller can suffer a security failure without being in breach of the law. Not every security breach constitutes a breach of the seventh data protection principle.

The reason for these conclusions is found in the wording of the seventh data protection principle, which says that controllers shall take appropriate technical and organizational measures to keep personal data safe and secure. The use of the word “appropriate” is highly significant because it tells us that as far as security is concerned the law does not create a no-fault regime. The word “appropriate” tells us that the law will tolerate operational failure. This is a very special characteristic of the seventh data protection principle, which is not present within the other principles.

In other words, the seventh data protection principle contains wiggle room for the controller which, with an understanding of systems-based regulation, can be exploited. Provided that the controller’s systems pass muster, the controller can seek to repel regulatory action and the fine by channeling the case to the conclusion that the operational failure was one of those things that can happen to a legally compliant organisation, in the sense that it fell within the tolerances of the law.

These advantages may not accrue to a controller with a non-compliant system, leaving such a controller in the invidious position of having to accept a penalty following an operational failure that would otherwise be excused. Putting the same point differently, a non-compliant system can result in the controller grasping defeat from the jaws of victory.

Example – the rogue employee
The presence of the rogue employee is a situation that is catered for within data security law. For example, the seventh data protection principle focuses on the reliability of employees.

The legal obligation is to take appropriate measures to identify, reduce, and contain the risk, not every measure. If the controller takes appropriate measures, but the rogue is still successful in achieving his malevolent ambitions, the controller should not be punished.

The legal obligations and the fact of systems-based regulation require the controller to create a documented set of rules for the identification, reduction, and containment of the risk of the rogue. Reflecting the benchmarks within the law, the systems will include rules about pre-employment vetting, the content of employment contracts, the process of induction, the process of ongoing training, the process of ongoing monitoring, the process of ongoing assessment, disciplinary processes, the management of exit, and so on. The presence of these rules should bring the regulatory investigation to a swift conclusion, with the controller being acquitted of the charge of non-compliance. The fine is avoided, despite the operational failure. Conversely, if the systems are silent on some or all of these rules, the controller will be punished despite the fact that the rogue’s achievement of his ambitions could not have been prevented.

Benchmarking
This analysis reveals that the critical exercise within systems-based regulation is the measurement of the systems against the legal benchmarks. Ultimately, the commissioner’s legal right to fine may be determined by a tick-boxing exercise, with the controller’s safe harbour being found in the number of ticks they achieve.

Consequently, the controller needs to understand the benchmarks—what they are about and where they are found. Unfortunately, the full range of benchmarks is not contained in legislation. Rather, they are found in an amalgam of legislation, regulatory guidance, government policies, standards for best practice, professional obligations, decisions in enforcement actions, case law, and private law arrangements.

The wise controller—the one that appreciates all of the implications of the new legal framework for data security, the consequences of being fined, and the law’s trajectory towards disputes and litigation—will seek to identify the benchmarks and test its systems against them, making necessary adjustments in areas found lacking. The very wise controller will understand these issues better than the commissioner, which will put it at a distinct advantage in the event that regulatory action ensues.