“He’s making it up as he goes along!”

The Monty Python film, The Life of Brian, contains some fantastic quotes which those who have attended my training and presentations know, occasionally end up in my materials! “He’s making it up as he goes along” (announced by John Cleese as Brian is telling a parable) sprang to mind this week whilst I reviewed and then re-drafted the data subject rights procedure for a client for whom I am the Outsourced DPO.

The existing procedure was inherited when Data Protection People took on the Outsourced DPO contract, but as it gave absolutely no guidance and no instruction at all to the reader as to what to do with subject rights requests, it pretty much left them make it up as they went along.

This echoed an observation I made during last week’s audits where the two sites I audited had reasonably good procedures for handling subject access requests, but absolutely nothing in place for other types of rights requests i.e. no procedure at all for handling erasure, rectification, objection, restriction etc. requests. It seemed to me that for some reason these other rights were being totally overlooked leaving the recipient in the dangerous position of “making it up as they go along”, which is the last thing you want your people to do with these things.

So, what made my procedure better than the one I inherited and fit for purpose?

Procedures need to be action oriented and they should:

• Set out who is responsible for doing what.
• Define, in writing, the specific actions that must be taken by specified individuals (or roles) in a certain order/manner and they should cater for every reasonable eventuality including exceptions.
• Not contain questions or statements – there should be no ambiguity in a procedure. It was on this premise that I re-drafted the data subject rights procedure of my client.

I always start drafting a procedure with a flow chart – if I can draw it – I can draft it and so the new subject rights procedure sets out a series of steps in writing supported by a flow chart.

Identifying a request

All employees are responsible for identifying a request and need a degree of training in this. One interesting aspect of the procedure was to ensure the drafting accommodated the various channels through which rights requests may be received. The introduction of verbal requests as well as those made through “technical specifications” (Article 22(5)) in the GDPR needed to be thought through and woven into the procedure

Reacting to a request

The procedure sets out the action that everyone receiving a rights request must do, which of course meant thinking through the procedural variations in the event that “plan ‘A’” doesn’t operate (e.g. holidays, sickness etc. of the DPO).

Logging a request

Requests should be logged in a central register of rights requests. Far too often I find spreadsheets with different tabs for each type of request or (even worse) different workbooks for each year. Anyone who knows anything about Excel knows that this is not a great way to structure a register/database. What is needed is a centralised and consolidated register of rights requests which accommodates every different type of request and all of the various nuances.

That’s why Excel is not suitable for rights requests record-keeping and you are far better off using a properly built data base system such as DPP’s DataWise which has a customised process for handling each type of request, is properly multi-user, cloud-based, contains audit trails of user activity and logic which means that the database has an awareness of the concept of time and can issue reminders and escalate requests if they are not acted on quickly enough.

Initial actions

The procedure details the initial actions to take such as verifying the identity of the requestor, clarifying the request, and agreeing the format in which the requestor would like the response.

Responding to the request

This part of the procedure provides a series of defined steps for each type of request. Work methods common to different types of requests are identified, documented and referred to in the procedure so, for instance, as it is necessary to undertake an information search to fulfil a subject access request, a portability request, and erasure request and a correction request it seemed sensible to define one information search methodology which can be utilised in each of these 4 request types. Another example of common practices would be in the DPO issuing “stop now” instructions for both processing restrictions raised under Article 18 and objections to processing raised under Article 21.

Stepping through this part of the procedure was the fun part of the work – designing and documenting the way to fold the qualification criterion and evaluation processes into the procedure. For example, an erasure request is only valid in certain circumstances and so the procedure takes the reader through the steps to determine if the request is a valid request. Only certain data fall within the scope of a portability request and the procedure provides the reader with the specific steps to narrow the information search. The right of restriction of processing may be applied temporarily or indefinitely to data processing activities and the procedure sets out how to handle this.

The end result

The end result is, I have to say, a very practical piece of work setting out a procedure to cater for every eventuality envisaged by the GDPR in relation to data subject rights.

Next week, the Outsourced DPO is travelling all the way to Sussex to deliver a couple of training sessions and has a two-day site audit in Surrey, so these will probably be the focus of next week’s blog.

Philip Brining

7th December 2018