DPA 2018 Part 3 Chapter 4 : S.55-58

I was about to publish my 'Six Tests' results article when I realised that I haven't actually finished going through all of the DPA 2018 Part 3 provisions and what they mean for Law Enforcement Competent Authorities [LECA] (and their suppliers and partners).

I DID discuss this previously (here), now over a year ago...but I think this one is more current.

Because one of those tests makes specific reference to the legal obligations that exist for Controllers and their Processors I thought it wise to quickly bash out this article (setting the scene of Chapter 4 "Controller and Processor") and then another covering the specific elements that a Processor has to be able to do in order to have a valid contract with a Law Enforcement Controller (mainly contained in s.59 through to s.63, plus s.66).

So THIS article, then THAT article and I will then be ready to publish the Six Tests results comfortable in the knowledge that I've actually explained the '13 Elements' relating to legal obligations that I included in my Test 6 "Contract T&C's".

Make sense? OK lets carry on...

Chapter 4 - What its about and what it basically says...

Chapter 4 of the Data Protection Act 2018 Part 3 [DPA'18 Pt3] is one of the most important and impactful parts of the Act for Law Enforcement Controllers and their supply chains, since it sets out their respective legal responsibilities (hence the 'Obligations' logo above) and gives most of the information needed to form a suitable contract and processing agreement (in fact the first part of Chapter 4 (s.55) says exactly that:

If (as a LECA) you were to try to process any Personal Data for a Law Enforcement purpose without taking into account the provisions of this Chapter then you (and any processor you engage) would be facing some serious potential legal penalties (although they are in the Standard Maximum Amount tier of €10m rather than the higher tier).

So anyway - Section 55 (above) is all about scoping - it 'does what it says on the tin' in the main but the important part is s.55(2) : where it makes clear that Chapter 4 relates only to the processing of personal data for a law enforcement purpose.

This means that in real terms you are going to be operating multiple (or at least two) regimes for your personal data both internally (as a Controller) and with any processors you may engage. It is THIS provision that makes clear that GDPR alignment alone is not enough (and as we will see when we look at the Six Tests and then things like National Enabling Programme activities or other supplier arrangements that's really very important indeed).

The ICO covers this really well and even gives nice examples of how regimes should apply and one of how data can change from GDPR to DPA 2018 Part 3 during its lifetime. Because they've been so very clear it always surprises me when folks don't understand this or try to apply GDPR rules to what is clearly a Law Enforcement purpose.

S.55(3) is also important - it is the clause that lays down the broad obligation on Controllers that allows for proportionality in selecting controls and processing arrangements. Its important to recognise here however that this isn't just going to come down to some selective finger in the air activity - s.64 (which we will cover in a later article) identifies and places on controllers the obligation of a Data Protection Impact Assessment, and the last few sections of Chapter 4 talk about security incident handling and the need - and the organisational placement and skill requirements - of a DPO for THIS part of the Act (and which is quite distinct from the GDPR obligations for a DPO - with a different skill set in many respects).

So we've done S.55, let's have a look at S.56 through 58

Sections 56 to 65 collectively fall under something called 'General Obligations' - essentially these are the things that have to be applied by all relevant parties as part of their day to day operations.

To be absolutely honest this is the bread and butter stuff - the basics that every single Law Enforcement DPO will (hopefully) have already made sure are in place in every Competent Authority; because if they aren't then its quite likely there is no effective lawful governance reigme in place at all... its that fundamental.

Section 56 is pretty small and fairly simple:

It places an obligation on all Controllers to implement technical and organisational measures and to be able to evidence them, to review them and that they must include suitable policies. See, I told you this was basic stuff - lets move along to S.57/58.

Section 57 is the first one where real work might be needed - and although it mirrors GDPR Article 25 in some respects (i.e. the Section title - "Data protection by design and by default") it would be an error to simply think it mirrors Article 25, because whilst its very similar it doesn't quite match it exactly.

The differences are quite subtle to readily distinguish in a comparison of requirements that are sequenced differently, but in essence whilst Article 25 GDPR (1) talks about 'pseudonymisation', S.57 makes no such parallel. Similarly there is no provision under S.57 to accept a certification mechanism to demonstrate compliance in the way that it can under GDPR.

Having said that, the DCMS explanatory notes which accompany the legislation DO refer to pseudonymisation - so it might be something considered by Controllers and Processors who feel they could convince a court (or ICO) that it was both a good, relevant measure to apply and that they had applied it effectively...

What is interesting in both of these sets of texts - and still hasn't been all that well established in any case law is the effect of the clause s.57 (5) - "In particular, the measures implemented to comply with the duty under subsection (3) must ensure that, by default, personal data is not made accessible to an indefinite number of people without an individual’s intervention."

This is interesting for Law Enforcement processing in particular because the established practices and most of the systems that are used do in fact allow for access on demand to a lot of the personal information they hold (especially on National systems like PNC) to a lot of individuals - but whilst that's not necessarily an 'indefinite number' (there are about 150,000 serving Police Officers across the UK who can legitimately access most PNC records on demand) the key element may be the 'individuals intervention'.

This term is not discussed at all in the DCMS interpretative guidance for Part 3, and not really covered by the ICO with regard to DPA'18 Part 3 either (though their generic data privacy by design guidance for GDPR is valuable reading). It may not actually matter massively however because as we will see when we look at S.62 in our next Article, the controller and processor need to keep detailed logs of exactly who has looked at, modified or disclosed personal data and the justification for that 'consultation or disclosure'.

(I actually think a lot of Policing systems and some of the newer services they are now trying to consume will struggle with that need to capture the 'justification for' as well as the event of actually looking at a piece of data, but only if they can do both could it really be remotely asserted that the S.57 obligation can be met or audited.

Section 58 is quite interesting... especially to me personally as someone who for many years was involved with, and for a period responsible for, the technical and security architectures of National Police Systems.

Section 58 is about 'Joint Controllers', essentially what happens when multiple Data Controllers put their personal data into a shared pot and collectively (or jointly) determine how it will be processed and for what reasons.

Most Police National Systems (PNC, PND, PentiP, ViSOR, CAID, etc.) operate on the basis that individual Forces upload information to share with other Forces (and sometimes with selected partners), but where the uploading Forces remains Data Controller.

In effect then these National systems are (mostly) under 'Joint Control' - I say mostly because some systems look like National Systems but work in quite different ways and may well not be under 'joint control' even when data is shared (its a bit complicated).

It is further complicated by the fact that some of these systems - like PNC or PND or ViSOR are sometimes referred to as 'Home Office Systems'. That's worth looking at for a second because actually the relationship with Home Office is somewhat more complex...

Home Office do provide funding for Policing in England and Wales (not for ALL the forces but most of them), and they do therefore fund (or claw back funding from Forces) for systems such as PNC - but they are not necessarily the same type of data handling entity as a Police Force - sometimes they are really just a Processor (for example Home Office run some systems to which they upload no data, and have no direct input into the reasons for which it is processed or how) and sometimes they might award a contract and thereafter do some governance but its really hard to establish if they are a Controller, a Processor or nothing defined at all under the DPA 2018 - an example of that being CAID, which they fund and assure but don't actually operate or actively use in a Law Enforcement activity - though they do a lot of governance work on it. Its often quite a complex landscape...

Getting back to the point of s.58 however - all these National Systems which have 'Joint Controllers' should by now have established which of those controllers is actually going to be 'designate' for each system, and given its supposed to be a "transparent" process ought to publish that really (in fact they kind of HAVE to do so to act as contact point for a Data Subject seeking to exercise their rights).

Now the primary system that many Data Subjects want to exercise their rights over is PNC - colloquially the UK Police criminal records system (though in fact it holds information from lots of entities beyond just Police Forces, and other systems exist which perform this and similar functions in parallel or separately in Scotland).

If you approach a Police Force asking for information that Force has uploaded to PNC about you (and for which they are still the Controller), they probably SHOULD send your request to the Designated Controller and inform you that they've done so. That Designated Controller (which should typically be another Police Force Data Controller if you've read the legislation above) would then help you to exercise your rights (in this case a Data Subject Access Request [DSAR].)

EVERY National System should operate that way - you should be able to contact the Force that is the Controller for your personal data and they should pass it on to the Designated Controller, or a list o Designated Controllers for each and every system should be published so you can do this yourself. 'Transparent' and 'contact point for data subjects' remember - but I don't think a list exists (i.e. I can't find it...)

If you read most Police Force web pages on DSAR's however that is not how it currently works (in fact quite a few still refer to DPA 1998, or to GDPR and suggest that you NEED to fill in a form for a DSAR - both not true). what you will often see on these DSAR forms is that the Force will only provide information it holds in local systems and that requests for PNC information should be directed to ACRO (who whilst they are a Competent Authority under Para 17 of Schedule 7 of the DPA 2018 might not be a true 'Joint Controller' for PNC data and who don't appear to present themselves as 'Designated Controller for PNC' in any of their materials).

Here is the problem - if a Force won't revel what information they have uploaded on to one of the (35 or so) National Systems about you, and can't identify a Designated Controller to assist then how are you supposed to be able to exercise your rights as a Data Subject?

The end result is that it is currently really hard to even work out as a Data Subject how you could seek access to the information a Police Force (might quite legitimately) be holding in a National System other than PNC, and there appears to be little means of effective relief. That should really never have been allowed to happen and S.58 clearly lays out all the steps that ought to have been taken - or should still be taken - to make sure it is addressed.

Summing Up

That's it for this time round - I just felt I had to get this (and the next one explaining Processor obligations) out into the open before I seek to explain the specific problems arising from the Six Tests. The next article laying out those Processor obligations will be along just shortly...