Intelligible Data Protection Legislation: A Procedural Approach

1. Introduction

To make a sponge cake, bakers know what they will need as ingredients: white flour, sugar, baking powder, eggs and potato flour. And they know that in order to avoid disastrous results, they must start by whipping eggs and sugar. In law, the situation is often similar: when applying the law, it is not enough to know which facts and assessments that are input in the case; one also needs to know which procedures to follow to reach a legally acceptable result. The average citizen with very limited knowledge, or none at all, pertaining to statutory interpretation, needs a ʻlegal recipe’ to avoid flawed results.

More fundamentally, legislation in democracies under the rule of law must be intelligible, not only to professionals, but to all persons who have rights and obligations pursuant to it. What causes intelligibility – or the lack thereof – is a large and complex issue far beyond the ambitions of this article. The more modest remit of this article is to discuss the significance and desirability of legislation that operates with clear ʻprocedures’, i.e. legislation that is designed to make clear to those applying it how they should act in order to attain legally correct and valid results.¹ The discussion here focuses on data protection legislation. Such legislation is a response to the increasingly extensive and intensive computerised processing of personal data in the modern world. It has been enacted with the formal aim of protecting individual persons by giving them particular rights as data subjects, and by introducing obligations for controllers and processors of personal data.² At the same time, this legislation has been rightly criticised for its poor intelligibility.³

This short and explorative article has its background in studies of eGovernment and the automated application of legislation and other legal sources.⁴ It assumes that legislators may learn something from a very basic quality of computer systems: most current government computer systems are ʻprocedural’ in the sense that they process data pursuant to predefined instructions that are fixed and formalised in algorithms. In order to reach legally correct results, computers need programs giving the correct instructions in the correct sequence. Similarly, I assume that people need to find ʻinstructions’ telling them how the legislator has intended the various provisions to be applied. Data protection legislation, however, tends to follow a very different approach. Its structure is typically non-procedural and ʻfragmented’, leaving it up to those applying the law to interpret and ascertain which procedures are to be followed so as to solve legal problems. In this article, I argue that data protection law – even though it is not a type of legislation suited for full-scale automation – should adopt a procedural law-making style. In principle, I assume such a ʻprocedural’ style is applicable to every part of such legislation.⁵ However, it is probably best suited and justified when applied to those parts giving rights and obligations to citizens and SMEs.⁶

The following discussion is based on two observations:

Putting the pieces of legislation together requires legal knowledge. The first observation is based on the idea that legal knowledge concerning how rule fragments must be patched together could be embedded and made explicit in the text of the law. This would reduce the legal knowledge required of lay data subjects and data controllers and would make it easier for them to understand the legislation. The second observation is intuitive, namely that the less difference there is between the logical structures of laws and the programming code in systems implementing these laws, the easier it is to transform the latter to programming code and thereby facilitate their computerisation. Although the automated application of data protection legislation is of little practical importance, there are great possibilities and a need to develop computer systems that provide support to people applying the law.

In sections 3 and 4 below, I try to demonstrate the difference between a fragmented and procedural statutory structure, using elements of the European Union (EU) General Data Protection Regulation (GDPR)⁷ as example. The instances of pseudo-code that I present in this context also illustrate how relatively simple it is to computerise the law, provided a procedural statutory style is applied.

2. Procedural clarity and predictability

Legislators usually pass laws with a view to having an impact on the lives of ordinary citizens. To have an effect, the law must communicate. To that end, legislative acts must be drafted clearly, simply and precisely.⁸ This follows also from the general principle of legal certainty that is central to rule of law ideals. Legislation usually attempts to contribute to legal certainty, but the mere existence of legislation does not necessarily contribute much. In unfortunate cases when statutory texts are unclear, legislation functions more as an ʻinventory of legal uncertainty’ than as a source of intelligible legal solutions. Indeed, some go so far as to claim that ʻwell-intentioned laws that are badly drafted or not readily accessible are also a form of tyranny’.⁹

Here, I refrain from attempting to specify the numerous quality aspects of legislation that influence the degree of its intelligibility. Instead, I narrow the discussion to a very basic distinction inspired by computerised processing: some statutory interpretation problems could be said to concern data (ʻwhat’)¹⁰ and others concern procedures (ʻhow’). In this context, I choose to understand provisions of the law as descriptions of how legally relevant data input must be processed in order to arrive at legally acceptable results.

By ʻprocedure’ I refer to a series of actions conducted in a certain order or manner for a certain purpose. The purpose can be, for instance, to clarify the kind of legal basis for processing of personal data that is required or, further, to establish whether there is valid consent from data subjects. Procedures create coherence. Procedures may follow explicitly from the provisions of the law, but are often only implicit and hard to discover for laypersons.

Procedural questions encompass, for instance, whether or not conditions of the law are alternative or cumulative, the sequence in which conditions should be assessed, or how age and time should be calculated. Logical operators¹¹ in sentences like ʻIF data subject’s age is 18 years OR (data subject’s age is 16 – 18 years AND processing relates to information society services) OR (data subject’s age is less than 16 years AND processing is authorised by parent) […]», constitute necessary links between concepts describing data (cf. phrases between the operators).

On the basis of the above-mentioned distinction, we may ask to what extent uncertainty regarding statutory interpretation of procedural questions is acceptable. The question implies that certain problems of legal interpretation should be acceptable and even desirable because they produce effects that are positive and defensible when seen, for instance, from the perspective of legislators or officials applying the law. On this point, I presume that a clash of interest typically exists between, on the one hand, ordinary citizens who would like to understand the law even though they have no legal competence, and on the other, legislators and professional stakeholders. The latter may find it desirable and even necessary that legislation contains vague terminology, room for discretionary expert assessments etc. The view may be that such ʻpoor quality’ provisions (from the citizen’s viewpoint) must be accepted in order to attain sufficiently flexible, adequate and effective regulation.

In this respect, I will merely point out that, given the multifaceted and rapidly changing character of our societies, there are often good reasons for adopting legislation that operates with vague terminology and discretionary expressions of expert opinions, to the extent that it creates reasonable flexibility in its application. The decisive question, however, is whether unclear or undecided procedures are necessary to attain such flexibility. My assertion is that, in the great majority of cases, procedural uncertainty represents ambiguity that is neither necessary nor legally acceptable. In other words, my presumption is that there rarely exists a legitimate rationale for legal uncertainty regarding how rule elements must be joined together to reach legally valid results. Refusal to accept procedural legal uncertainty is not incompatible with the acknowledgment of the need for flexible and dynamic legislation. Such need may be fully met through the use of vague terms, expressions giving room for expert assessments etc. connected to input data.

The examples from the GDPR in the next two sections concern legal matters that many ordinary citizens need to understand, namely, the legal basis for the processing of personal data where consent, in particular, constitutes one such basis. I am well aware that the following examples do not constitute a general proof that a procedural approach is fruitful, but hopefully they will cause further discussions.

3. Procedures: examining the GDPR’s main structures of conditions

It is useful to regard the procedural aspects of legislation as questions of main procedure and sub-procedures.¹² The initial main procedure embedded in the GDPR may be described in the following seven steps:¹³

For each of these steps of the required main procedure, the regulation contains scattered provisions regarding sub-procedures that must be carried out (regarding scope, legal basis, purpose specification, etc.). Determination of the legal basis of planned processing, for instance, must be conducted pursuant to Article 6 regarding lawfulness of processing. Basically, Article 6 identifies the data subject’s consent and several types of ʻnecessary’ or statutory grounds as alternative legal bases for processing personal data. Here, I do not treat this rather comprehensive and complex Article in detail, but limit discussion by identifying one basic structural-procedural issue about which the provision is silent. This issue concerns the choice of legal basis for processing of personal data.

If we go deeper into this issue, we have the following problem structure (abbreviated as pseudo-code):

Sub-procedure to main procedure, step II (determine the legal basis of planned processing):

These various types of legal bases are apparently of equal priority, and there are no guidelines in the Regulation regarding which of them to choose. As a practical matter, this is primarily a problem concerning the choice between using consent or necessary grounds as legal basis. If a procedural drafting approach is followed, it is required that the legislator clarify whether or not those who apply the law have free choice between consent and necessary grounds. Alternatively, the legislator could specify situations where one of the legal bases should be selected before the others.¹⁵

One of the necessary grounds as stated in Article 6(1)(e) comprises situations where national parliaments pass legislation that makes processing of specific personal data necessary.¹⁶ The provision requires that processing of personal data is ʻnecessary for the […] exercise of official authority vested in the controller’. When such a legal basis exists (e.g. pursuant to national legislation), it will have priority over consent and the other necessary grounds listed in Article 6(1)(b) – (f). In the Regulation, however, this priority is not made explicit.

I fail to see any justifiable reason why the legislators should be silent about the fundamental choices regarding the alternatives referred to in Article 6. These choices are decisive for possible application of the consent arrangement. Even if the legislators were unable to establish clear procedures on this point, it is hard to see why the legislators have refrained from specifying relevant arguments, thereby strengthening ordinary citizens’ ability to identify and understand the basic structure of these problems. When uncertainty exists regarding the type of legal basis required for the processing to be lawful, people applying the law will need to understand all provisions constituting the potential legal basis, i.e. statutory law of the relevant Member States, consent of the data subject or necessary grounds as stated in the Article. Lack of structural clarity on this level arguably weakens the traction of the law.

4. Establishing sub-procedures

Choice of legal basis makes it necessary to examine sub-procedure II in section 3 above. For instance, in cases when a controller has decided to base processing of personal data on consent from data subjects, there needs to be clarity about which detailed sub-procedures are to be followed in order to end up with valid expressions of consent.¹⁷

Basic rule fragments concerning consent can be deduced from the following provisions:

The Regulation does not indicate any procedure regarding how obtaining consent should be carried out; it is up to each person reading the text to find out where to start and how to proceed. These procedures could have been made visible in at least two ways – either one by one or in combination. The most direct way would be to organise a cluster of all provisions determining how consent must be carried out, and place these provisions in a sequence showing step by step what to assess in order to arrive at a legally valid result. An alternative method could be to introduce internal references between relevant provisions.¹⁸ To readers of the Regulation, the first method mentioned is probably best, but in some situations it may be difficult to compile every relevant provision in sequence. Thus, a combination of the two methods is probably preferable.

In the following, I demonstrate that it is possible to redesign the relevant fragments of the Regulation regarding consent and transform them into – what I believe to be – a much clearer described procedure. First, to inform the reader, I have cited a relevant selection of provisions from the Regulation. Thereafter, I restructure these text elements by defining a consent procedure.

The provisions that are chiefly relevant are formulated in the Regulation as follows:

Article 4

Definitions

For the purposes of this Regulation:

[…]

(11) ʻconsent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;

[…]

Article 6

Lawfulness of processing

1. Processing shall be lawful only if and to the extent that at least one of the following applies:

(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;

[…]

Article 7

Conditions for consent

1. Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.

2. If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration that constitutes an infringement of this Regulation shall not be binding.

3. The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.

4. When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.

Article 8

Conditions applicable to child’s consent in relation to information society services

1. Where point (a) of Article 6(1) applies, in relation to the offer of information society services directly to a child, the processing of the personal data of a child shall be lawful where the child is at least 16 years old. Where the child is below the age of 16 years, such processing shall be lawful only if and to the extent that consent is given or authorised by the holder of parental responsibility over the child.

Member States may provide by law for a lower age for those purposes provided that such lower age is not below 13 years.

2. The controller shall make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology.

3. Paragraph 1 shall not affect the general contract law of Member States such as the rules on the validity, formation or effect of a contract in relation to a child.

Although these cited provisions are placed close to each other in the Regulation, they are not compiled into a procedure. Very important provisions regarding consent are placed as parts of Articles regulating definitions (Article 4) and lawfulness of processing (Article 6). The legislators have not grouped or made references between provisions regarding the same topic. For instance, one implicit main rule concerning power to consent is that the age of consenting persons must be 18 years or more (cf. Article 4). Articles 8(1) and (2) contain exceptions to this rule, but no reference is made to Article 4. Withdrawal of consent is partly regulated in Article 7(3), but the preceding and succeeding provisions in paragraphs (2) and (4) are not related to withdrawal.

If we try to redesign these provisions to design a consent procedure without making changes in terms of content, it seems to follow from the Regulation that the rule fragments referred to above may be grouped under four legal issues, each with an appurtenant procedure. In the example below, I have expressed relevant rules in pseudo-code style. The aim of this first phase is only to establish procedure. Concepts and phrases of the referred Articles are addressed later, when the pseudo-code is transformed back into natural language (see further below).

For each of these elements A–D, I have identified a structure of conditions. These conditions are joined together by a simple logical structure. The natural language that determines the substantive contents of these conditions is not necessarily affected by establishment of procedures.¹⁹ Although the wording of my example in natural language above differs from the original text of the GDPR, establishment of procedure does not limit possibilities of reintroducing vague concepts and expert assessments. My defragmentation experiment, in other words, has only strongly reduced legal uncertainty regarding procedure. All other possibilities of flexibility regarding inputs are intact.

Transformation from fragmented structure – where it is required that those who apply the law have background legal knowledge so as to understand which procedure to follow, to a defined procedure where such knowledge is unnecessary – is similar to what we would do to develop a computer system that supports the application of provisions regarding consent. However, instead of taking the next step of formalisation by programming the rules here expressed in pseudo-code, I transform such code back into natural language. Thus, the next phase is to write procedures in full plain language, using phrases and concepts similar to those in the original text. Here, I only illustrate this transcription by showing a full text version of the first sub-procedure (A) regarding power to consent:

Art. (A) Data subjects’ power to consent

Art. (B) Power to consent on behalf of the data subjects

[…]

Art. (C) Conditions for valid consent

[…]

Art. (D) Collection of consent

[…]

The regulation is largely silent on the procedures for withdrawing consent. Probably, however, similar rules apply as in cases of collecting consent.²⁰ Thus, relevant provisions could possibly be extended by, for instance, adding an Art. (E) stating that Art. (A) – (D) should be applied in cases of withdrawal of consent, if applicable.

As shown, it is quite possible to redesign these provisions of the GDPR, by defragmenting the text and exposing implicit procedures. If a computer tool is developed to support application of these provisions, it could obviously not be designed to express the authentic fragmented structure of the Regulation. Instead, it would have to rest on a clear understanding of the interrelationships between the relevant provisions. Thus, if we were to make a decision-support system, we would have to go through this process anyway.

One anticipated objection against such procedurally designed legislation is that it would lead to larger volumes of text. This has been, for instance, one of the consequences of restructuring tax legislation in the Tax Law Rewrite Project in the United Kingdom. However, the view has been taken that this increase in volume is more than outweighed by the gains in clarity.²¹ By making each procedural step explicit, more text is often unavoidable. Increased text volume should not be a cardinal factor; the degree to which texts have qualities enabling citizens better to understand and apply legislation correctly should be of greater importance. If twenty minutes’ study of a fragmented brief text could be reduced to five minutes’ study of a more comprehensive and structured text, most people would agree that the latter alternative is preferable. Moreover, in choosing between these statutory designs, time spent to reach a conclusion is not the only critical factor; the degree of certainty/uncertainty in conclusions is crucial too. Typically, laymen’s conclusions based on a fragmented Regulation will be more uncertain compared to conclusions arrived at through a clearly defined procedure.

5. Conclusion

I have no specific knowledge as to why the provisions of the GDPR have been structured in the fragmented and incomplete way they are. There are reasons to assume that this law-making style is largely the result of tradition rather than conscious reflection over desirable structure, and that this tradition is possibly combined with a belief that lawyers have the ability to decipher the text of the law. The legislators have probably not considered it important that ordinary citizens should be able readily to apply the Regulation.

Yet, this fragmented style of statutory drafting must be abandoned if the legal system is to become an integral part of a computerised society. The high cost in time and money of transforming laws into computer systems that support or automate application of the law is likely to make the development of such systems improbable. In addition, the chances of incorrect transformation very likely increase if there is a high degree of fragmentation of legislation.

In this article I have discussed a realm of law that is currently not well adapted for automation. Many other laws resemble the GDPR: thus, digitisation must be conducted primarily by developing systems that support those who apply the law. If legislators desire more computer-supported application of the law (cf. the ideals of ʻdata protection by design’ as expressed in, inter alia, GDPR Article 25) and more automated legal decision-making, the only logical conclusion is that they must prepare the ground for this to happen – or at least avoid making it more difficult than necessary.²² If computer systems are to be designed to support data protection, legislators cannot continue to pass legislation that does not live up to the very basic requirements of computerised information systems: i.e., provision of clear, detailed procedures.

Many of us will reject the idea of computers replacing legal assessment. We see the value of manual assessments involving the richness of natural language, expert reasoning, and so on. Yet, even if legislation were to be applied completely manually, clear procedures expressed in legislation should have high priority. The example of how the consent procedure could be more clearly defined illustrates that a procedural law-making style also makes it easier for people to gain an overview and understanding of legal matters.