You are here

Logging policy: data protection, interception and Freedom of Information

This policy applies to both centrally-managed and self-managed systems. It concerns information logged by services running on these machines. This document does not address data-protection, freedom-of-information or interception issues other than as they impact on logging.

This document is in two parts. The first part is the Policy itself. This is followed by an explanation and discussion.

Policy

In this policy a "service manager" is anyone who operates a service accessible to others, including on a self-managed machine. Note that this also includes personal machines (e.g. laptops) connected to the School network, by virtue of the University's Computing Regulations.

The terms "personal data" and "interception" are as defined in legislation. See the discussion below for details.

Service managers must document the purpose or purposes for which logs are produced. For each purpose:


  1. service managers must check whether personal data might be logged; if so, a justification must be given and steps to ensure compliance with data protection law noted, a Data Protection Impact Assessment ("DPIA") undertaken unless one already exists, and a Privacy Notice written unless one already exists
  2. service managers must check whether interception might be taking place; if so, the "authorization" must be noted
  3. service managers must ensure that retention periods are appropriate

Logs maintained ONLY for the purpose of debugging the operation of the service by that service's manager are normally "authorized" implicitly by the RIP act, but must still meet any UK GDPR requirements. Any other use requires the permission of the Head of School or their nominee, to ensure that the University's statutory obligations are discharged.

Examples

The following are just some examples of personal data. Bear in mind that the University, as a whole, is the data controller.


  • Usernames are clearly personal data, as they directly identify the individual users.

  • IP addresses are also explicitly covered by the UK GDPR Article 4.

  • Anonymised data are not personal data, as in this case it is not possible to identify any individuals. Bear in mind, however, that it is actually quite difficult to anonymise data sets such that individuals can't be identified even with "other information", particularly when individuals may appear more than once.

  • Web page names are unlikely to be personal data in most cases, as they would not normally identify individuals. However, the logging of page names is "interception" under the terms of the RIP Act, and so must be "authorized" under the terms of that Act.

Discussion

In terms of the regulatory framework in which our logging has to operate, the main influences are the Human Rights Act 1998, the UK GDPR and the Data Protection Act 2018, and the Regulation of Investigatory Powers Act 2000 (see links below). In addition, the information we log will (subject to the usual exemptions) be available on request under the Freedom of Information (Scotland) Act 2002.


  1. The Human Rights Act incorporates the European Convention on Human Rights and its various Protocols into UK law. Everything the University does must be in accordance with the ECHR. Working within the constraints of the Data Protection Act and the Regulation of Investigatory Powers Act, which were set up in part as a result of ECHR issues, and following established industry practice should allow us to argue that we are indeed in accord with the HRA, though we should always bear in mind its underlying principles.

  2. The UK GDPR and the The Data Protection Act 2018 impose constraints on how we process personal data, as well as providing statutory rights of access and correction for data subjects.

    "'Personal data' means data which relate to an "identified or identifiable natural person (UK GDPR Article 4). In addition, various specified types are known as "special categories of personal data" (UK GDPR Article 9) and are subject to much more stringent processing constraints.

    In terms of the definitions the issue is not just whether the log entries identify individuals per se. If it is possible for us to identify to whom the entries relate, possibly using other information available to us, then the log entries are by definition personal data and must be processed accordingly.

    All processing of personal data must be done in accordance with the UK GDPR Article 5 principles.

    (Fortunately it's unlikely that any special categories of personal data would be logged in most cases, but it would be as well to be aware of the possibility. It's hard to see which of the Article 9 conditions we could possibly meet!)

    The effective requirement here, then, is that processing must be in accordance with the Article 5 principles. In particular, data must be: processed lawfully, fairly and in a transparent manner; obtained only for specified, legitimate and explicit purposes; not excessive; not kept for longer than necessary; protected against unauthorised processing; and not exported outside the EEA. This doesn't mean that such processing can't happen, rather that when it does it is done according to the UK GDPR's rules.

  3. "Interception" is subject to the Regulation of Investigatory Powers Act 2000. The definitions are somewhat convoluted, but essentially interception is making "some or all of the contents of the communication available, while being transmitted, to a person other than the sender or intended recipient of the communication." There is a limited exclusion for "traffic data", which amounts to header, addressing and routing information, but it is stated explicitly in the Act's Explanatory Note ¶34 as well as rather obliquely in the Act itself that the traffic data "may identify a server but not a website or page."

    The upshot of all this is that logging associated with a service which has the "purpose of facilitating the transmission of communications", such as a web service or a mail or messaging service, is likely to constitute "interception", and must therefore be "authorized" by the Act or its associated Regulations (in particular the Lawful Business Practice regulations). It is therefore necessary to identify for each service the purpose for which logging is being undertaken to confirm that it is in accordance with the Regulations (or indeed §3(3) of the Act, which allows for interception "connected with the provision or operation" of a service; but note that this must be interpreted tightly).

The University does notify all users fairly regularly that interception and processing of personal data may take place for the purposes given in the notification.

Note that logging must in each case comply with all of the statutory requirements which are relevant. The UK GDPR and RIPA rules must all be followed as required, and following one does not obviate the need to also follow the other.

Note also that just because logs are allowed for one purpose, it does not necessarily follow that they can be used for some other purpose. Each case must be assessed separately on its own merits. It may be that some form of redaction or anonymisation is required before they can be used for a secondary purpose. The simple act of passing raw data to someone counts as "processing", and so even in this case the UK GDPR conditions must be met.

There is currently no statutory requirement for us to undertake data retention, and in any case there is no requirement to collect data additional to that needed for normal operational purposes. However, for our own purposes and to allow us to monitor compliance with, for example, the JANET AUP, we would likely want to keep some logs for some period. The LINX Best Current Practice on traceability suggests keeping such data for at least 3 months but no longer than 6 months; and once no longer required for this purpose such data should be anonymised or deleted.

The question of backups and archives is discussed elsewhere. Generally speaking, though, data on archives is likely still to fall under the UK GDPR and FoI(S)A provisions, while backups held for disaster-recovery purposes and regularly rotated as part of an exist schedule might not. As a rule, logs containing personal data should not be archived, owing to the difficulty there would likely be in complying with the subject-access rights.

Useful Links

Last reviewed: 
29/04/2022

System Status

Home dirs (AFS)
Network
Mail
Other services
University services
Scheduled downtime

Choose a topic