DPA 2018 Part 3 Ch4 - Records of Processing and Logging (s61-s62)

This time out on our continuing journey through the DPA 2018 Part 3 - the UK's Data Protection regime built just for Law Enforcement - we’re going to look at both the Records of Processing and Logging requirements.

These sound kind-of similar, but think of them this way;

• Records of Processing – cover what type of data you are processing, why you’re processing it and how (as well as where)
• Logging - is the detailed breakdown of all processing activities – essentially it’s the information on “who touched what data and for what purpose”

Records of Processing (S61)

A ‘record of processing’ covers both the controller and the processor – with a slightly different content for each – and made available to the ICO on request.

The Controller Record has to include:

(a) Name and contact details of the controller;

(b) Name and contact details of any joint controller(s) (if applicable);

(c) Name and contact details of the Data Protection Officer;

(d) Purposes of the processing;

(e) Categories of recipients to whom personal data has been or will be disclosed (including recipients in third countries or international organisations);

(f) A description of the categories of—

(i) data subject, and

(ii) personal data;

(g) Details of any use of profiling (where applicable);

(h) Categories of transfers of personal data to 3rd country or any international organisation;

(i) Legal basis for the processing operations, including transfers, for which the personal data is intended;

(j) Envisaged time limits for erasure of the different categories of personal data*;

(k) General description of technical and organisational security measures (also referred to in section 66).

 * For Police Forces at least the Supreme Court and ECHR have made clear in their judgement for the Catt v United Kingdom case that the retention and deletion periods must align completely to published Police Policy for the Management of Police Information [MOPI]. They also identified that MOPI (and other policies similarly laid down under a power of statute) are both mandatory and statutory in their own right. Other sectors with similar policies should take note of this ruling and adjust their practices accordingly.

The Processor’s Record has to include:

(a) Name and contact details of the processor and any sub-processors [in accordance with section 59(3)];

(b) Name and contact details of the controller for whom the processor is acting;

(c) Name and contact details of the data protection officer (where applicable);

(d) Categories of processing carried out on behalf of the controller;

(e) Details of transfers of personal data to a third country or an international organisation where explicitly instructed to do so by the controller** (where applicable);

(f) A general description of the technical and organisational security measures (also referred to in section 66).

** My article on s59 & s60 - Obligations of Processors, explained that a Processor is legally obliged NOT to make any 3rd country data transfer unless it is expressly authorised on a case by case "particular" basis by the Controller - this is a record of such authorisations.

This sort of information shouldn’t really be that onerous to compile and hold – and though I’ve noted that a lot of Law Enforcement Competent Authorities don’t actually publish the name of their DPO; its unlikely that giving the name to the ICO should cause any sleepless nights, so this stuff is pretty easy to align to.

The Logging requirement is a little more complicated – and you KNEW there had to be complexity hidden somewhere in this Article (let’s be honest).

Logging (s62)

Now the Logging section itself isn’t very big – it’s just 5 paragraphs – but from my knowledge of existing LE ICT systems (with which I have worked for the past 20 years or so), I know its still going to be hard to fully implement these provisions in some cases.

We can assume that the ICO knows this too, because this section (and only this section of Part 3) has a phased implementation date – you can find it listed in Schedule 20 (Part 4) Para 14 of the DPA 2018, which says this;

“(1) In relation to an automated processing system set up before 6 May 2016, subsections (1) to (3) of section 62 of this Act do not apply if and to the extent that compliance with them would involve disproportionate effort.

(2) Sub-paragraph (1) ceases to have effect at the beginning of 6 May 2023.”

What this means for a CA Controller and their Processor(s) is that whilst every other section of Part 3 came into full effect in May 2018; the requirements for Logging (in Part 3 Chapter 4 Section 62) only came into immediate effect for any system implemented since the 6th May 2016.

Let’s just dig into that a bit – the DPA 2018 itself came into effect in the UK in May 2018; but the underlying EU Directive 2016/679 (The Law Enforcement Directive) was originally signed into EU law on 6th May 2016 and that’s where this date actually comes from.

Now you might thing that a period of phased implementation of something so complex as system and event logging should be provided – that is the 6 May 2023 date.

For legacy systems this is good news (though in some cases will be hardly long enough); but any applications first deployed in your organisation after 6th May 2016 should be meeting the requirements now. Today. No exceptions. OK?

Its assumed (not wholly unreasonably) that you have already had 2 years to phase in this change since the LED itself was formalised into European law; and hence the go-active date of 6th May 2018 for new systems shouldn’t need any more work.

You knew about this and had the s62 Logging requirement specifically included in all your non-functional specifications for all systems you've procured in the past 2 years, right?

This isn’t one of the high tariff offence areass; (but its still a 2% / €10m maximum fine) and the ICO will look unfavourably upon you, if you have a data breach and can’t show them valid logs of activity – so this should be a high priority area for your attention.

The real complexity comes from the fact that this extension to 2023 only applies to old legacy systems you had in place before May 2016; and many CA’s are using the same old tech and applications as everyone else in their sector (many of which are 20 years old - or older). I'm aware that several Forces in particular have deployed case management or Command and Control services (or similar) using this sort of old technology in the past 2 years - and even some 'modernised' applications which have old underpinnings might not meet this requirement well (or indeed at all).

You won’t get any additional time to bring this old tech up to speed – it needs to meet the s62 Logging requirements right now (and that could well be a problem you can't easily fix).

So what do you need to log? 

“A controller (or, where personal data is processed on behalf of the controller by a processor, the processor) must keep logs for at least the following processing operations in automated processing systems—

(a) collection;

(b) alteration;

(c) consultation;

(d) disclosure (including transfers);

(e) combination; and

(f) erasure.”

The section then goes on to explain WHY you need to log some of this activity as follows -

Logs of Consultation must make it possible to establish:

• Justification for, data and time of the consultatio; and
• So far as possible, who consulted the data.

Remember this is “consultation” – i.e. who may have had READ access to the data

Logs of Disclosure must make it possible to establish:

• Justification for, data and time of the disclosure; and
• So far as possible, who disclosed the data, and to whom it was disclosed.

Remember this is “disclosure” – i.e. who may was GIVEN A COPY OF the data.

Section 62 also limits the purposes to which you put all this log data;

(a) to verify the lawfulness of processing;

(b) to assist with self-monitoring by the controller or the processor, including the conduct of internal disciplinary proceedings;

(c) to ensure the integrity and security of personal data;

(d) the purposes of criminal proceedings.

This means that the log data cannot be used for any sort of additional "data analytics" purpose, but does mean that they can be closely aligned to – but perhaps will form a specific sub-set of – wider security logs.

Finally the Controller and/or Processor must provide the logs to the ICO on request.

IMPORTANT NOTE:

Neither the Act (nor the guidance notes) describe or lay down exactly how long these Logs need to be maintained - and it should not be assumed that this is just a 6 month or 12 month obligation: it could foreseeably be for as long as the source record data is held, or indeed beyond. The ICO should be contacted ASAP to confirm their expectations; however I would not be surprised if the decision is that these logs need to be retained for the same duration of the MOPI policy dictates for the source personal data records to ensure that the full lifecycle of the data in the controller can be shown and audited - whilst this would be difficult its not wholly unreasonable or without precedent to do so.

 Guidance and Notes

The DCMS guidance notes for this part of the Act identify that these requirements are completely new from the prior expectations of the DPA 1998; but also suggests that they are neither new obligations in terms of HMG policy security requirements and nor are they beyond the expectations of the IOPC.

“The Independent Office for Police Conduct (formally the Independent Police Complaints Commission) has published guidance on the recording of police complaints and an example of a category of complaint that this may be relevant to is: category Z – Improper access and/or disclosure of information.

If, for example, an officer or member of police staff was suspected of inappropriately accessing the Police National Computer to check on neighbours, family or friends, the logging should show details of when the record was accessed and, where possible, by whom, which would assist the investigation possibly leading to criminal or disciplinary action and possible dismissal.”

As a result then, there is likely to be little justification (or acceptance of excuses) for not maintaining correct logs – and it is after all one of the main means by which the obligation for a Controller or Processor that data is correctly managed can be demonstrated.

The reality however is that many (indeed most) legacy systems do not currently keep this level of logs – either by a limitation on their design, or because the volume and computing overhead of such logs has been deemed superfluous or disabled to gain more system performance.

This Logging requirement does not however have to be delivered from within the data processing application itself of course; third party tools to provide logs suitable for the legal requirement do exist; but they tend to be neither cheap nor easy to implement.

Its also worth identifying that the logs will need to give full coverage across the IT estate if they are to be effective, and whilst they may not introduce a need to collect End User Device logs; its certainly the case that in Cloud or externally hosted services the logging requirement needs to be applied on the underlying infrastructure as well as on the applications processing or holding the personal data which sit upon that infrastructure.

This may or may not be another problem for Cloud services to consider – logs of customer activity are normally well catered for, but logs of Cloud Provider activities, data processing, transfers and access/deletion, etc.) might be harder to come by. Several Cloud service standard T&C's will not disclose thes elogs since they may also disclose exactly how the Cloud platform works or is configured (causing problems for both commercial sensitivity and possible system security issues).

This is another one of the potentially unforeseen complexities of moving infrastructure off-premise; but exactly how hard that may be to address will depend to a great extent on the nature of the outsourced IT service and by whom (and from where) it is provided.

Either way CA's and their Processors need to open up those discussions if they hope to comply with these sections of the Act.