GLD Vacancies

A Framework to undermine the ICO’s ability to enforce the new Data Protection Bill

Data highway 63025938 l 146Chris Pounder asks whether the government’s new Framework for Data Processing could inadvertently impede the regulator’s efforts to enforce the GDPR.

The government has just inserted clauses into the Data Protection (DP) Bill that allows the Secretary of State to issue a “Framework for Data Processing”, initially for each Government Department. This Framework has the status of statutory guidance and “will set out the manner in which government should process (personal) data”.

In effect the Framework is like a statutory Code of Practice; its aim is to “improve the transparency and clarity of existing government data processing”.

The Framework, according to the official explanation, “does not allow the government to create any new data processing powers” (but it does describe how the law applies).

Indeed “the Framework should provide reassurance to data subjects about the approach government takes to processing data and the procedures that it follows when doing so. It will also help further strengthen the government’s compliance with the requirements of the GDPR and contribute to the provision of a clear, precise and foreseeable basis for government’s processing of data”.

So apple pie and honey all round? Well I am sure the provisions are well intentioned, but as the proverb goes, “the way to hell is paved with good intentions”. This article seeks to traverse this “pathway to hell”.

In summary, the clauses are defective as the content of the Framework is left to the Secretary of State to determine. In addition, the ICO cannot easily challenge the Framework text if there is a dispute as to how it describes how personal data should be processed.

Taking the road to nowhere

First, the assertion is that the Framework provides improved “transparency and clarity” (i.e. more transparency than the details provided by the “right to be informed” in Article 13 and 14 of the GDPR).

Remember the details that have to be issued to each data subject, by each Government controller, in accordance with the ICO’s revamped Privacy Notices code of Practice? They include: details of retention times, recipients, purposes of the processing, legal basis for the processing, use of public sources etc etc? In short, I have difficulty in identifying what is more transparent than that.

However, the real problems arise when the Framework contains details of how a government controller processes personal data which runs counter to the Information Commissioner’s view of how the data protection law should work.

For instance, if there were to be a disputed view on data protection procedure, it is surprising to discover that the government can ignore the Information Commissioner’s view. This is because clause 175(5) states that before preparing a Framework, the “Secretary of State must consult the (Information) Commissioner” (my emphasis).

Note the operative word is “consult” as in “Mrs Thatcher consulted widely about the superb brilliance of the Poll Tax prior to implementation”. In other words, the Secretary of State having consulted the ICO, is free to ignore the ICO’s concerns (which history shows has often occurred; e.g. in relation to the custodial element of the section 55 offence).

Clause 176 sets out how Parliament approves a Framework; it is a negative resolution procedure which means Parliament has to vote the Framework down. A House of Commons Library report states that the last occasion that the House of Commons used a negative resolution procedure to vote down a Statutory Instrument was on 24 October 1979 – forty years ago. (Older readers may recall that this involved the notorious, evil and dastardly “Paraffin (Maximum Retail Prices) (Revocation) Order 1979”).

In other words, Parliament is unlikely to object to a Framework produced by the Secretary of State even if the ICO has objections; this is especially the case if the ruling party has a Parliamentary majority. So, could the ICO enforce her view of the legislation, when a government department is processing the personal data in accordance with a Framework that the ICO has a problem with?

Well such enforcement is made difficult by new Clause 178; for instance:

● Clause 178(1): “When carrying out processing of personal data” (which is subject to the Framework) “a person must have regard to the (Framework) document”. Comment: if you were a data protection officer in a government department do you follow the ICO or your Secretary of State given the Framework says you must have regard to the Secretary of State’s view of the state of data protection in his Department?
● Clause 178(3): Compliance with a Framework document “is admissible in evidence in legal proceedings”. Comment: processing in accordance with a Secretary of State’s Framework for his own Government Department is evidence that the controller is doing the “right thing”. Worst case scenario is that the ICO has to take enforcement action to counter the Framework.
● Clause 178(4): “In any legal proceedings before a court or tribunal, the court or tribunal must take into account a provision of the (Framework) document...”. Comment: this could reverse the burden of proof on appeal, as any ICO enforcement has to overcome the Framework’s provisions. Normally when the ICO uses enforcement powers, it is the controller that has to show that the ICO enforcement is wrong; the ICO does not have to prove that enforcement was correct.
● Clause 178(5): “In determining a question arising in connection with the carrying out of any of the Commissioner’s functions, the Commissioner must take into account a provision of a (Framework) document”. Comment: this is clearly another additional barrier that the ICO has to consider before using enforcement powers. It is a barrier that places Government controllers in a special position when enforcement is considered.

To be honest, one wonders whether erecting barriers to the ICO enforcement damages the notion that the UK Information Commissioner is independent of government (with all that means for adequacy).

Finally, the official document explains that “The government has chosen to draw the application of the Framework as narrowly as possible”. But then Clause 175(1)(b) extends the Framework to “a person with functions of a public nature who is specified or described in regulations made by the Secretary of State” (i.e. to any public body the Secretary of State chooses in future). Yep, it appears the Secretary of State uses a very novel definition of “narrowly”.

In summary, the Secretary of State can:

● produce a Framework that applies data protection to his own Department;
● ignore what the Information Commissioner says about the Framework;
● lay his own Framework before Parliament using a procedure that guarantees that it is very unlikely to be scrutinised;
● raise barriers or fetter the ICO’s enforcement mechanism, and
● extend or introduce Frameworks to include any other public sector body.

Seen in this light, these clauses are not a recipe for “transparency and clarity” as claimed in the official (propaganda) document; they are a recipe for ensuring that a future Secretary of State can subtly modify the impact of the new data protection provisions on his own Department and make it difficult for the ICO to challenge.

If a Secretary of State wanted a Framework, he could produce a Code of Practice for his department and ask the ICO to approve it; alternatively, he can task the ICO to produce a Statutory Code. Such a Code produced by the ICO, like the Framework, can be laid down before Parliament and can balance any conflicting processing interests in a considered way.

The main difference is that the ICO has control of content of a Code of Practice whereas it is the Secretary of State that controls the text of the Framework.

Public trust in the Framework ultimately depends on who is in control of the text. The fact that these Clauses do not allow the ICO to veto and/or modify the text of the Framework permits it to contain provisions that could skew data protection in favour of a government controller (in this case, this includes any present or future Secretary of State).

It is the longevity of these Clauses, the ability to ignore the ICO and the ICO’s lack of control over the text combined with the unknown nature of our future political masters which makes them unacceptable; there is, quite simply, no counter-balance.

There appears to be an assumption the Secretary of State will produce a Framework where the ICO is in agreement; history shows that this assumption is false. Without a change to allow the ICO to have independent control or final say on the content the Framework, the Framework should be seen as dangerous.

#Fakedataprotection.

Chris Pounder is director at Amberhawk Training and Amberhawk Associates. He is a member of the Identity Assurance, Privacy and Consumer Advisory Group (advising the Cabinet Office on “privacy friendly” use of identity assurance techniques) and the Data Protection Advisory Panel (advising the Ministry of Justice on its approach to the EU’s Data Protection Regulation and Directive in the field of law enforcement).
www.amberhawk.com

References
Official explanation of the powers: https://publications.parliament.uk/pa/bills/lbill/2017-2019/0066/18066-DPMsupplementary.pdf

Insight 2 Cover 450 300dpi

This article was first published in the February edition of Local Government Lawyer Insight, which can be accessed at http://www.localgovernmentlawyer.co.uk/insight

Insight is published four times a year and is circulated free-of-charge to all Local Government Lawyer newsletter subscribers (click here to subscribe) in electronic format. A single hard copy is also circulated to all local authority legal departments in England and Wales.

Additional printed copies are available for just £49.95 for four issues. Multiple copies are also available at £149.95 for five or £249.95 for 10. Payment can be made by purchase order/invoice or by credit/debit card. To order, please call 0207 239 4917 or email This email address is being protected from spambots. You need JavaScript enabled to view it..