Insight Local Government Lawyer Insight February 2018 29 (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 The Information Commissioner’s Office’s view We understand the motivation for this is for government departments in particular to be sure of their legal bases for processing and that is important especially given the greater focus on this for public authorities under GDPR. Our concerns are: ●The provisions as drafted are potentially much wider than this as they cover any processing activity and also other bodies doing public tasks. ●Given the potential breadth there is potential for regulatory confusion given other statutory guidance such as the ICO code on data sharing, the codes under the Digital Economy Act, etc. ●We think a draft of the framework guidance should be published so parliament can understand the extent and ensure no regulatory confusion before the Bill is passed. ●The provisions requiring the Commissioner to take the guidance into account when undertaking her statutory functions is unnecessary. We take account all statutory and sectoral guidance as we would be judicially reviewed if we didn’t and this would be exposed on appeal where we take enforcement action. For example there are no provisions requiring us to take account of the DEA codes, the SoS Surveillance Camera Code or Ministerial National Fraud Initiative data matching Code even though these can also affect matters that the Commissioner is required to consider. ●Including this aspect runs the risk of calling onto question the independence of the national supervisory authority as required by Article 52 of GDPR. We have updated our briefing for parliamentarians to reflect this and other matters considered at Report Stage on 11th and 13th December. This can be accessed from the Data Protection Bill pages of our website website at protection-bill/ Jonathan Bamford, Head of Parliament and Government Affairs, The Information Commissioner’s Office (ICO).