‘Living and Breathing’ Accountability

The General Data Protection Regulation (‘GDPR’) was born with the aim to be technologically neutral (Recital 15 GDPR). The upside of this tech neutrality is that it will (hopefully) award a long lifetime to GDPR, regardless of technical innovation. The downside: it makes the accountability principle seem very broad and with practical challenges. But there is light in this space too: operationalising accountability is possible.

Accountability: It is not all about the policies

Although accountability is seen as such a key concept in the GDPR it is surprising to see that there are only a limited number of specific references to this term (Recital 85 and Article 5.2 GDPR). If you find yourself presented with the view that accountability only refers to Articles 5.2 and 24 GDPR, you would be justified in challenging that view. Accountability is the GDPR.

Article 5.2 GDPR states that the controller shall be responsible for and be able to demonstrate compliance with the processing requirements in Article 5.1 GDPR (“accountability”) including (i) lawfulness, fairness and transparency, (ii) purpose limitation, (iii) data minimisation, (iv) accuracy, (v) storage limitation, (vi) integrity and confidentiality.

At a first glance, it could appear that businesses need to address an innumerable amount of different issues in order to comply with these principles: DPIAs, policies, Data Subject rights, conditions for consent, lawfulness of processing, prior consultation, Data Protection by Design and Default, etc… However, the obligations become less daunting when you take a step back and realise that all the pieces fit in the same puzzle.

A holistic accountability structure can be summarised to these three interconnected layers:

1. Paper Layer (drafting policies, notices and working plans)
2. People Layer (creating an organisational structure, monitoring, training, processes)
3. Technology Layer (software and hardware to automate some of the processes; record the activities, etc…)

All companies will recognise the paper layer and many of them will already have it in place, over time this may have even turned into large piles of documents, which, on the face of it, demonstrate that the organisation complies with data protection principles.

However, the rationale behind GDPR’s principle of accountability is to protect personal data beyond a paper layer. Of course, policies are useful and, to most ways of thinking, essential to demonstrate compliance, but is this enough? Not really. The GDPR states that “the controller shall (…) implement appropriate technical and organisational measures” (Articles 24.1 and 25.1 GDPR); the Working Party 29 (known as the European Data Protection Board after the GDPR) already underlined it in 2010 (“Data protection must move from “theory to practice”)¹, and we at PwC are heavily invested in that journey (“We are on a “The Journey to Code”).

So, where to start?

1. Revisiting your organisational measures and being honest in your observations

Organisations which deal with personal data need not only to generate ‘on paper’ designs through policy and guidance, but to understand how things work day-to-day in operations where data protection outcomes (be they good or bad) are achieved.

By stepping from the policy layer into operations you can understand: (i) how tasks need to be performed or decisions taken in practice, (ii) by whom, and (iii) where the inter-team and task connections need to happen. There is no use in performing a step in a process if the connection to the next step, or team, does not exist or is broken. Accountability cannot be achieved in isolation within the data protection team or any other team.

2. Business process modelling: finding your accountability issues

Straightforward business process modelling can help you to create not only a set of operational process designs which contribute to your ‘set play’ accountability documentation, but also to discover where processes aren’t working as expected. That is, you may find operational accountability issues.

These issues may include that a task or team handover isn’t in place, or that the team or individual who is responsible (according to policy) for a task or a decision isn’t equipped to perform that role and needs training, or any number of other issues. These problems can, and must be solved, in order to properly demonstrate operational accountability.

3.  Accountability records

Throughout your day-to-day operations your teams are constantly creating accountability records, which should include records of decisions taken during governance meetings, a system record of a data extract or a file sent, the transmission of a risk assessment conclusion to an operational business team to implement, etc.

If within those processes the tasks are well defined, understood, are performed by individuals and team with the right knowhow to perform their roles, and operational process flow and connect end-to-end, then you are likely to have a positive set of operational accountability artefacts to call upon should the need arise. If tasks are performed or decisions taken by those without sufficient skill, or processes stop half way through, then the opposite is true.

How you ‘live and breathe’ in terms of accountability is not proven by your policy, but through the operational records of what goes on day-to day.

4. Using Technology

As explained in the previous blog “The Journey to Code through the lens of Accountability”, technology is an enabler for demonstrating accountability. Of course, the technology you use needs to ensure the good (and not bad) Data Protection outcomes. To do so, make sure to build the right workflows and controls into the technology deployed. The technology must not be programmed in such a way that it automates incorrect action, or to say it another way, to cause a user to perform a potential action that they otherwise would not, but they do it because the computer forces them to (you could consider this “the automation of stupidity”).

As you can see, the process itself forces the creation of accountability artefacts (and data protection outcomes). When done well, these accountability artefacts will help you to tell a positive story to anyone who may be interested.

A cultural change, a Journey to Ethics

In the words of the European Data Protection Supervisor, Giovanni Buttarelli: “the concept of accountability - now put at the heart of the data protection reform with the GDPR - goes beyond compliance with the rules, it implies a cultural change from inside organisations”². This view was also reiterated at the 40th International Data Protection Commissioners conference (ICDPPC) in Brussels in October 2018, focussing on moving beyond mere compliance and the importance of Digital Ethics. This cultural change needs to happen within the technology layer too, to ensure that the results that data protection technology delivers within the organization are not only legal, but also ethical. This is what we, at PwC, call “Journey to Ethics” (see our blog on “The Journey to Code”, final section) and it reflects our firm’s purpose to build trust in society.

¹ Article 29 Data Protection Working Party, Opinion 3/2010 on the principle of accountability (adopted on 13 July 2010), p. 3. 
² Buttarelli, G. 2017. Hitting the ground running: How regulators and businesses can really put data protection accountability into practice (Keynote speech at European Data Protection Days (EDPD) Conference), 15 May 2017 , Berlin.