Introduction
This blog discusses the DCMS proposal: to remove the obligation to maintain a register of processing activities (ROPA; A.30); to remove the requirement to undertake DPIAs (A.35 and A.36); and to reduce the circumstances when a data breach is reported to the ICO (A.33). These will be replaced by far looser requirements that form part of a controller’s privacy management programme (see last blog).
As before, the Consultation’s arguments for change are wholly unconvincing and there are significant errors in its analysis. Additionally, European Commission awarded the UK an adequacy agreement on the assumption that GDPR accountability standards would be maintained; they are not.
This is the second blog dealing with the UK’s proposals to change the accountability requirements in the UK_GDPR towards the levels found in OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. The proposals can be found at Chapter 2 of the DCMS Consultation document (“Data: a new direction”) paragraphs 165 to 184.
Reducing accountability – no Controller ROPA
The Consultation’s argument to remove the Register of Processing Activities (ROPA) is incomplete, omits the ROPA associated with processors, and contains a major fundamental error which undermines its argument for removal of the ROPA.
A ROPA under A.30(1) requires the controller to compile an inventory of all the controller’s processing which is couched in data protection terms (e.g. an inventory of the controller’s processing purposes, recipients, transfers, retention times, security arrangements, and a description of the personal data processed).
Such a ROPA should not be conflated or confused with an Asset Register which contains a description of the controller’s assets, its location, details of asset owner, software licences etc. Such conflation exists in specification of an inventory for a privacy management programme (para 156(a)(III)(i) of the Consultation).
All processing purposes have to be described in the controller’s ROPA. If the processing is not described in a ROPA it is tantamount to the admission that the controller is not wholly in control of all the processing of personal data. That is why ROPA forms part of the accountability arrangements; accountable processing is that described in a ROPA.
One of the Government’s main argument for removing the ROPA is that its content “largely duplicates … the requirement to provide information to data subjects in Articles 13 and 14 of the UK_GDPR”. This statement is wholly incorrect for a number of reasons:
- There are many exemptions from the right to be informed (A.13, A.14) and the related transparency Principle (A.5(1)(a)) when the data subject is not provided details of the processing; there are no exemptions from the A.30 ROPA so details of the exempt processing are captured in the ROPA.
- The A.30(1) ROPA contains a complete description of ALL personal data processed for ALL processing purposes; the A.13 and A.14 obligation is limited to personal data processed for a specific purpose (i.e. the Privacy Notice for one service does not describe all the data items used for all services).
- The retention criteria is an obligatory part of the A.30 register; this retention criteria is not an obligatory requirement to be disclosed by a controller to the data subject (see A.13(2); A.14(2)).
- The A.30(1) ROPA contains a complete list of ALL actual purposes of the processing; the A.13 and A.14 obligations only relate to the intended purposes (i.e. the purpose might not happen) that is associated with the collection of personal data about the data subject.
- In the case of processing of sensitive personal data justified in terms of Schedule 1 of the DPA2018, the A.30(1) ROPA contains details of the policies that apply towards such data; this detail is not provided in relation to A.13 and A.14. (As an aside, this provision is mentioned approvingly in the Adequacy Agreement at para 38).
As explained above, the Consultation is not getting rid of the need for an inventory, as inventories forms part of the proposed privacy management programme. However, as each controller can decide what to put into its own inventory, there is a significant risk is that inventories become inconsistent across all controllers (e.g. one bank’s inventory might be different to that of another bank).
In summary, there is no substance to the Consultation’s argument, based on the fact that such information is provided to the data subject, that the controller’s A.30 ROPAs should be removed.
Reducing accountability – no Processor ROPA
Wholly omitted by the Consultation is mention of the ROPA compiled by processors(A.30(2)); so one assumes this requirement will also be removed from the UK_GDPR without justification or evidence for its removal.
A ROPA for a processor (A.30(2)) is an inventory of the clients of the processor, and for each client: what processing is being undertaken; where personal data are transferred outside the UK; and a general description of the security measures employed to protect the personal data. A controller using a processor therefore should know where its processors are transferring its personal data, as each processor has compiled a list of such transfers for each of its clients.
At least one can say: “Because there is no evidence, the Consultation cannot be challenged or accused of being wrong”.
Reducing accountability – no to DPIA
Under the UK_GDPR, the requirement to undertake a DPIA is triggered when a controller processes personal data that the ICO has identified as high-risk processing (e.g. large scale processing of health records, large scale surveillance). The ICO maintains a public list of such high risk processing (see references).
The Consultation’s proposal is to remove this requirement “so that organisations may adopt different approaches to identify and minimise data protection risks that better reflect their specific circumstances”. In other words, it is the controller who decides when to do a risk assessment (i.e. not the ICO) and the controller adopts whatever risk methodology is deemed appropriate by it.
Note that the requirement to do a risk assessment is not being removed. For example, the “requirements of the privacy management programme” include a requirement for a controller “to have in place risk management processes, including the processes which allow for the identification, assessment and mitigation of data protection risks across the organisation.”
By subsuming the replacement for DPIA as part of the controller’s privacy management programme, any failure to do perform a credible risk assessment cannot be enforced directly by the ICO unless the privacy management programme is, in-itself, deficient. The proposed change thus protects the controller from being subject to enforcement for a failure to perform a risk assessment.
The change also effectively substitutes the criteria that the ICO has published with respect to a DPIA with criteria determined by each controller; as noted previously this devolution of responsibility is a recipe for an inconsistent approach to risk assessment.
If there is high risk processing identified in a DPIA, the controller has no need to involve a DPO to get data protection advice, as required by A.39(1)(c), because the post of DPO could well be abolished (see last blog); the fact that the DPIA and DPO proposals are linked is absent from consultation.
In summary, the proposed change is likely to protect controllers that adopt a lackadaisical approach to risk assessment.
Reducing accountability – no to prior consultation
The Consultation also removes the “prior consultation” provisions in A.36; this arises when the controller identifies high risk processing that cannot be mitigated and approaches the ICO for “permission to process” (which can be refused). The Consultation states that as very few controllers consult the ICO, the provision can be removed.
The reason for the low uptake is that prior consultation with the ICO is, in itself, a high risk exercise. Approaching the ICO for prior consultation would be tantamount to asking the ICO: “Dear ICO, we have high risk processing where adopting GDPR procedures does not mitigate the high risk. Can we have permission to process?”.
Such an approach would have to go through the risk assessment procedures of an organisation, and in my view, the most likely outcome would be a decision not to process personal data until the unmitigated high risks can be reduced to acceptable levels.
That is why the provision is not used; it exists as a back-stop that allows the controller to make an approach to the ICO if there were extenuating circumstances which required the processing to occur despite the existence of residual high risks to data subjects.
The provision is in the controller’s interests if such circumstances arise as processing could get the go-ahead. It is also in the data subjects interests as there is an independent assessment of whether or not such extenuating circumstances, claimed by the controller, should prevail. The provision is designed as a provision of last resort and last resort provisions are rarely used.
The removal of the requirement for prior consultation with ICO will therefore increase the risk that such processing occurs without any consultation at all.
For example, suppose a Minister of the Crown sets mandatory high risk processing objectives for certain public bodies without providing these bodies with the resources to mitigate the data protection risks arising from the set processing objectives.
Without prior consultation, such processing can go ahead unabated. And I suspect it will.
Reducing accountability – less data breach reporting
The Consultation proposes to remove the data breach reporting mechanism because there is over-reporting of data breaches to the ICO. This over reporting is, in effect, being used as an excuse to raise the barrier for such reporting so that only material data breaches will be reported.
In further detail, the Consultation states that “organisations must report a breach unless the risk to individuals is not material”. Note that the “risk to individuals” could be a low risk, medium risk or high risk (i.e. there is no change from the risk based assessments in the current arrangements for data breach reporting).
The only change relates to what “material” means. For instance, a “material fact” is some piece of information important or relevant to an argument or debate.
Personal data material to the data subject therefore carries a connotation that the personal data is of “some importance” to the data subject. In other words, breaches that the controller deems to be unimportant (e.g. involve non-material personal data) are not reported.
Does the Consultation explain how the controller identifies a data breach involving non-material personal data? Answer: “No”.
Does the Consultation give examples of what kind of data breaches are to be reported. Answer: “No”.
The Consultation avoids these important questions by passing the buck to the ICO who is expected to provide examples of what is material and not material, and when to report and when not to report.
This is exactly the position as with the current data breach reporting regime.
Improve data breach guidance
I will now show how the current legislation is perfectly clear on the subject of data breach reporting to the ICO – and that no change is needed.
A data breach has to be reported to the ICO “unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons” (A.33(1)). Part of that breach report to the ICO includes a description of “the likely consequences of the personal data breach” [for natural persons]; (A.33(3)(c)).
The best way to get a handle on “unlikely to result in a risk to … natural persons” is to identify “the likely consequences of the personal data breach” [for natural persons]”. Note that “likely consequences” of a breach is not what “could happen”; it means reasonable foreseeable consequences.
If one cannot identify any “likely consequences” for natural persons then it follows there is “unlikely to result in a risk to … natural persons” and the breach is non-reportable.
Unlike the Consultation, Recital 89 provides illustrative examples of likely consequences: “physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned”.
If the likely consequences involve none of the above, then the arguments for non-reporting to the ICO are likely to be established.
The way to overcome the problem of over reporting data breaches to the ICO is for the ICO improve her guidance. The above shows there is no need to raise the threshold of data breach reporting so that only “material” impacts on individuals are reported.
Concluding comment: adequacy
Another significant omission in the Consultation is the impact of the proposed changes on the UK’s Adequacy Agreement with the European Commission. The relevant part of the Agreement reads:
“The principle of accountability …has been retained … in the UK GDPR without material change and the same applies to Article 24 on the responsibility of the controller .. Article 30 on records of processing activities, Articles 35 and 36 on data protection impact assessment and prior consultation of supervisory authority have also been retained. Articles 37-39 of Regulation (EU) 2016/679 on the designation and the tasks of the data protection officers have been retained in the UK GDPR with no material changes”. (Para. 84)
Clearly, the assumption of that the Commission made, namely that there is to be no material change to the accountability arrangements, is completely misplaced. It is surprising that this problem is unworthy of mention in the Consultation.
The fact that UK standards are going down to the OECD level will, one assumes, not go unnoticed especially as the Consultation’s arguments for change are wholly unconvincing.
Data Protection Practitioner Course (Autumn)
Because of continued COVID uncertainty, fuel crisis, or the results at Barnsley FC the course can be attended in person, or via Zoom, or as a mixture if you something untoward happens: it's up to you.
- The Data Protection Foundation Course is in London, and starts Tuesday, November 16 (3 days); Full details on http://www.amberhawk.com/DPFoundation.asp or by emailing info@amberhawk.com
- The Data Protection Practitioner Course is in London, and starts Monday, December 6 (5 days); Full details on amberhawk.com/StandardDP.asp or by emailing info@amberhawk.com
References
The list of when there is a need to perform a DPIA is on https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/#when4).
ICO on Accountability: https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2017/01/gdpr-and-accountability/
ICO privacy management programme is part of her Accountability Framework: https://ico.org.uk/for-organisations/accountability-framework/
ICO response to the DCMS Consultation: https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2021/10/response-to-dcms-consultation-foreword/
Comments