Part 3.2 – Law Enforcement Processing
Here’s our second pass at the Law Enforcement part of this legislation. I wonder what goodies are in store for us as we look at the controller and processor in Part 3.2?
Chapter 4 – Controller and Processor
Section 55 – Overview and scope
This is as you guessed just like each overview and scope section before it a basic description of what is about to come. Whoever wrote this legislation really likes to adhere to the rules we learned in high school. Tell them what you’re going to tell them, tell them and then tell them what you told them.
There is a wee titbit that when a controller needs to implement technical or organisation changes to meet requirements in this chapter they must adhere to, “the latest developments in technology.” I’m expecting this not to be a legal term, but I like the idea of this vague term setting someone up for a task of evaluating the entire scope of the latest technological advancements. I wonder if there is rhyme and reason to why some aspects of this legislation are written in minute detail while others are extremely vague. I bet there is a hidden art that I just haven’t glimpse yet.
Section 56 – General obligations of the controller
The Controller has to uphold the rules already set out.
Section 57 – Data protection by design and default
I’m sure this could be more succinct. But if you are a controller then use of data in processing needs to be designed so that the least amount necessary is used by default.
Section 58 – Joint controllers
This is neat, this section lays out a process where two controllers can effectively get joint custody over data. They have to set up their own agreement though. And if American TV has taught me anything it’s that law enforcement agencies like to squabble over jurisdiction and ultimately the FBI get to call the shots. And to a further degree save the day. Unless of course, the man on the inside is John McClane.
The best example of this I could find was when you have an instance where the national government has a database of children within the UK that is made up from contributions of local authorities (which are responsible for quality and data subject rights). Local authorities can use the entire database as long as they adhere to data protection principles. This would be joint between the National Government and Local Authorities.
Section 59 – Processors
Essentially there is just the normal description of how a processor works with a controller. There were two gems in the section though:
First Subsection (4) listed in parenthesis a clarification of why something was a part of the legislation. It’s notable because this seems to rarely happen. Quoted here:
“Where the controller gives a general written authorisation to a processor, the processor must inform the controller if the processor proposes to add to the number of sub-processors engaged by it or to replace any of them (so that the controller has the opportunity to object to the proposal).”
Second, unless I’m completely missing the point this reads near identical to the original GDPR unless there are slight changes in small words such as articles and pronouns I don’t see why this legislation can’t just point to the GDPR and go, “see that we’ll have all of that.” Then only list the changes within this document. If you did this you’d cut like 80% of this legislation out.
Section 60 – Processing under the authority of the controller or processor
Only process data if the controller allows it or it’s a legal requirement.
Section 61 – Records of processing activities
Just like GDPR you need to keep records regarding personal data processing.
Section 62 – Logging
Details must be logged for each processing activity regarding data. These are meant to be kept confidential and really only there to demonstrate lawfulness of processing and catch people that are doing evil things.
Section 63 – Co-operation with the Commissioner
The commissioner gets to tell people what to do and they have to do what the Commissioner says.
Section 64 – Data protection impact assessment
When processing is likely to result in high risk to data subjects a data protection impact assessment needs to be carried out. Of course, ‘High Risk’ has not been defined, that would be way too convenient.
Section 65 – Prior consultation with the Commissioner
Law enforcement needs to ask permission from the Commissioner if they are going to create a filing system that includes personal data.
Section 66 – Security of processing
Controllers and processors will ensure that any processing will be protected with appropriate security. Inadvertently this is an example of vagueness I can get behind, perhaps an example of what a threshold might look like, but essentially security is a fast-paced concept that will drastically change by the end of the year let alone the lifespan of this legislation.
Section 67 – Notification of a personal data breach to the Commissioner
If some data is compromised then you gots to tell the Commissioner.
Section 68 – Communication of a personal data breach to the data subject
You have to tell the data subjects affected. Here’s something I didn’t catch when working on GDPR. You don’t have to tell data subjects if you had all the appropriate measures in place. That makes me wonder if the aim of this part of the legislation is meant to be a deterrent to the controller rather than a measure to inform and protect data subjects.
Section 69 – Designation of a data protection officer
You got’s to have a data protection officer.
Section 70 – Position of a data protection officer
You can’t have a token data protection officer.
Section 71 – Tasks of data protection officer
A minimum list of tasks that the data protection officer should be able to do. There is nothing really surprising here.
I took an introduction to world governments at university and I remember getting frustrated with how some of the governments ran. I once commented that the creators of dungeons and dragons could write a better set of rules and laws to run a country (I believe we were studying Mexico at the time which has/had a large element of freedom, read corruption, at its core). I never really got an answer why we allowed this much reliance on interpretation or leeway. I understand the requirement to be adaptable to future changes, but I believe that being vague and being adaptable are not synonyms.
I’m wondering if I should have a go at re-writing GDPR and DPA 2018 more succinctly with language that is more clear and direct. That would confuse everyone if I posted that online and started working on SEO so it ranked as high as other publications of the actual law.