GDPR controls frameworks - how do you know if they are any good?

It might be surprising to know that despite a very long history of laws, regulations and operational practices - nearly 50 years in Europe - there is no consensus on what a good controls framework for Personal Data Protection actually looks like. 

This blog attempts to shine some light on what good looks like, or more accurately where a good one comes from. It also attempts to show the difference between controls frameworks and Privacy by Design.

The need for a controls framework

Back to first principles, the law says that controllers and processors of Personal Data have to take "appropriate technical and organisational measures" to deliver good outcomes for these data (see GDPR Art. 24, 28 & 32). This is legal language for a controls framework.

Applying this to the GDPR, a good controls framework will deliver the Data Protection Principles (fairness, accuracy etc); the Data Subject Rights (subject access, portability etc); and the new "build requirements" of the law (accountability, PIAs, PbD etc). 

Obviously, a GDPR controls framework that doesn't address all these matters will have restricted or limited value. 

The hierarchy of controls, their origins and their legal strength

When building or commissioning a controls framework, it is important to understand that there is a natural "hierarchy" of controls, which is based on the origins of the controls. 

Basically, the legal strength of the controls framework is linked to the hierarchy. 

The hierarchy is:

1. Controls that originate from the language of legislation.

2. Controls that originate from judicial decisions.

3. Controls that originate from regulatory work programmes.

4. Controls derived from "the consensus of professional opinion".

5. Controls derived from "custom, practice and experience".

This idea of a natural hierarchy isn't limited to data protection, or GDPR. It is a general point of law. 

Why is the legal strength of a controls framework important?

The legal strength of a controls framework matters because the GDPR is a piece of law and therefore the resolution of any questions or disputes about compliance is ultimately a legal matter. Putting this slightly differently, if there is a dispute, which cannot be resolved by agreement, only a judge can make a finding about the quality of the controls. 

A good way of looking at this would be to think about how data protection audits work and where they sit in the overall hierarchy of things. Basically, auditors will form judgements about compliance based on the presence or absence of particular controls. Therefore, the quality of controls seems to be an audit point. However, if the organisation suffers operational failure, say a personal data breach or an inability to properly deliver subject access, the issue of compliance will not remain an audit matter. It will move up the hierarchy. The issue moves up the hierarchy, to the regulator and then to the judges, if need be, who will be guided by the legislation and precedent (previous binding case law).

Therefore, controllers and processors will want to know how strong their controls frameworks are in a legal sense. 

This is not a disguised play to make lawyers the most important people in the world of the GDPR. Controls that originate from the consensus of professional opinion and from custom, practice and experience are developed by a much wider pool of experts, including risk professionals, management consultants, engineers and scientists. Further, this view recognises that the contents of legislation, the basis of court judgments and the trajectories of regulatory work programmes are all influenced by the wider pool of expertise. 

So, returning to the previous example, the auditor's positions may be relevant in the conclusion of the regulatory investigations and perhaps highly compelling if the auditor is truly expert. However, the regulator is not obliged to agree with the auditor. This is because the auditor is subservient to the law. And the regulator is subservient to the judges. 

Therefore, all experts have to acknowledge the legal framework in which they operate. 

A practical example is as follows: 

Example - how professional negligence cases are resolved

Imagine the situation of a medical accident, say where surgery goes wrong. The patient argues that the operating surgeon breached his duty of care, because he should have used a different medical procedure, but the patient needs expert evidence from another surgeon to be able to make out his case. The operating surgeon says that his choice of procedure was right, that the accident was an unavoidable risk, that the other surgeon's opinion is wrong and that there was no breach of the duty of care. The dispute can only be resolved by the judge in court, who listens to the expert medical evidence from both sides and then decides which expert he prefers.

This example proves three things:

- In the event of an intractable dispute relating to a breach of a duty of care, the process of resolution is always a legal one.

- All experts (surgeons, in this case) are subject to the judgement of the law.

- However, the law will always take into consideration the opinions of genuine experts. 

Hopefully, the implications for the design of controls frameworks for the GDPR are clear, but I will spell them out anyway. If a controls framework is not drawn from the top three layers of the hierarchy, then its strength will rest on the expertise of its creator. If the creator is not expert, the controls framework is valueless. 

So let's look at the fourth and fifth layers of the hierarchy.

Industry and professional standards - controls within the consensus of professional opinion

The fourth layer is controls derived from industry and professional standards, such as ISO standards and codes of practice issued by professional bodies. 

These standards are intended to represent the "consensus of professional opinion" on the subject matter at their heart. In other words, they are a meeting of the minds of a community of experts, in contrast to the views of one person. Their legal strength draws from this expert meeting of minds. And the law accords them recognition as a result. I cannot overplay the significance of this point: it is the meeting of expert minds that creates consensus. Returning to the medical world, this is why serious researchers always publish papers for peer review. 

In an "influence sense", controls from the consensus of professional opinion may be afforded more weight in business than the other layers of the hierarchy, perhaps because they operate in a larger zone of understanding and acceptance than the others (there are a lot more security professionals than lawyers, for example). 

However, in the data protection world, it is very much the case that the influence of these standards is lower than would otherwise be expected. This is because the consensus of professional opinion hasn't really coalesced around standards and codes for data protection, save for a few notable attempts such as GAPP in the US and PIMS in the UK, but it has to be stressed that they haven't been designed for GDPR. Moreover, even examples like GAPP and PIMS are not yet recognised by EU law: they are not baked into legislation and they never will be, nor have the judiciary opined on their worth. They currently live in an unhappy grey area of uncertain strength. 

Instead, what is going on is that people working in data protection are now trying to borrow and stitch together non-data protection standards and codes to form GDPR controls frameworks. This is a helpful endeavour, but the strength of these controls frameworks may be considerably weaker than perhaps has been thought, due to them not having been tested by the legal system, or, in fact, having been accepted by the consensus of opinion in the data protection field. If they are stitched together by one person, rather than a consensus of people, they have to be treated with caution: remember, it is the meeting of expert minds that creates strength.

Controls from custom, practice and experience

Finally, there are controls derived from custom, practice and experience. They have a role to play, but their strength is at the lower end of the spectrum. 

Ultimately, their value turns on the expertise of the people behind them, which necessarily causes a debate about the meaning of the expertise. There is case law on this issue, which shows that the concept of expertise is highly nuanced. However, what is crystal clear is that expertise is not a self declared concept. Nor does it flow simply from passing exams, or from having held an office. And being an expert in one area, doesn't constitute expertise for every area.

Things that are not a matter of record - confidential and danger zones

An expert will have experience and insights that are not matters of public record. For example, an expert management consultant will operate within conditions of client confidentiality, which prevents them from disclosing particular facts and matters to the wider world. However, those confidential matters will inform their opinions and the value of them. Therefore, a controls framework based upon custom, practice and experience does not have to flow completely from matters of public record. 

However, the presence or absence of matters of public record can signal a "danger zone", where the strength of the controls framework is called into question. The most obvious danger zone is where the controls framework purports to derive from the legislative, judicial or regulatory zones, but where the origin of the controls cannot be identified. In other words, a person who says that they have knowledge of the top three layers of the hierarchy should be able to pinpoint with accuracy the origins of any controls derived from those layers.

For example, imagine a situation where a controls framework purports to be built upon regulatory practice. This could point legitimately to documents of public record (such as publicly available enforcement cases, which underpin the PwC Privacy and Security Enforcement Tracker, for example, or guidance documents, such as ICO codes of practice). It would also be legitimate for a person to say that they have insight into regulatory positions as a result of acting in real regulatory cases, albeit that the details would be confidential. In these situations the "safety net" against distortion is the fact that the others can attest to the truth of the claims being made.

In contrast, a controls framework based upon what the regulator has told someone off the record, for instance in a social environment, would be of no value whatsoever, because of the lack of verifiability and the inherent ambiguity of the ad hoc situation. 

I would advise any lone expert who is trying to build a controls framework to build a consensus of professional opinion around their work, wherever possible. That would be minimum good practice. 

Origin, origin, origin (and for good measure, origin)

In conclusion, the only way a controller or processor can have full confidence in a controls framework is if it states its origin, in the sense of describing from which part of the hierarchy it derives and the materials that underpin it. If the origin is limited, then the limitations have to be stated. This statement of limitation provides the only benchmark against which the strength of the controls framework can be judged independently.

But why does any of this matter? 

Ultimately, this matters if you feel that the GDPR may create legal exposures for your organisation. If you don't sign contracts, if you're not publicly listed, if you don't think that individuals will pursue compensations claims against you, or if you don't believe that regulators will take action under the GDPR against you, then it might not matter at all. 

But if you think that there is a chance of legal exposure for your organisation, then you need to understand your controls framework and the strength of it. If you do not know the origins of the controls framework that you are applying, then you should try to find out. Otherwise, you are carrying unascertained and non-quantified risk.

Controls frameworks and Privacy by Design

Finally, a few words about controls frameworks and how they interact with Privacy by Design. Putting it bluntly, they are not the same thing. Controls frameworks provide a relatively blunt instrument for looking for the presence or absence of things that are consistent with attempts to deliver good outcomes, in this case for data protection. They are not intended to be, nor can they be a blue print for actually delivering good outcomes. 

Let's take the idea of pseudonymisation in the pharmaceuticals sector, which is an important issue for pharmacovigilence (PV). A controls framework may test for the presence or absence of a PV Policy, a policy owner and perhaps a coding strategy. However, to deliver pseudonymisation in practice, scientists, engineers and programmers will have to be engaged alongside other experts. They will operate at a level of detail and granularity that a controls framework cannot replicate. 

In other words, controls frameworks and PbD are different things, with different purposes, albeit they work together with the same overall aim, namely delivering good outcomes for personal data.

This article was written by Stewart Room | Solicitor (Partner) | Global Head of Cyber Security and Data Protection Legal Services; UK Data Protection National Lead | PwC - UK. If you need more help with any areas of your business concerning GDPR, then please don't hesitate to get in contact.