Skip to main content

Log data policy

Tampere University and TAMK

Introduction 

This document describes the general principles and requirements for the collection, processing, and management of log data in the University Group. The purpose of the Log data policy is to ensure that the Group has an appropriate procedure for supervising data processing, to support a secure and healthy environment, and to provide tools for developing the operations.

Log data refers to event-specific information collected on the procession of data (including, among other things, systems, applications, servers, terminals, and devices). Log data can be used to determine what, why and when something has happened or is likely to happen in the information systems. Log data collection and processing must have a legal basis. 

The principles of processing log data apply to the entire life cycle of data. Processing includes collecting, viewing, analysing, reporting, storing, disclosing, and destroying data. 

The principles described in this document must be applied to all services owned, operated, or managed by the University Group. They must also be applied to outsourced services where possible. The adequacy and usability of log data processing in an outsourced service are ensured by the terms of service agreed at the time of procurement and the agreements made about the service.

Ownership 

The ownership, content and maintenance of this document is the responsibility of the University Group's information security management. Information security management is defined in the information security policy.

Purpose

The collection and processing of log data is justified to safeguard the University Group’s missions and their continuity.

The main purpose of collecting and processing log data is to ensure the maintenance and smooth operation of data processing and data processing environments. 

In the event of a malfunction, log data are needed to identify the parties involved and the extent, causes and impact of the malfunction, and to restore the situation back to normal.

Collected log data are typically used to

  • investigate technical failures or malfunctions 
  • ensure data security 
  • detect non-compliant activities 
  • monitor data protection 
  • develop IT services 
  • collect user statistics 
  • in billing and cost allocation 
  • supporting the legal protection of users and administrators 
  • verification of compliance 
  • managing changes 

Principles of processing log data

The collection and processing of log data is planned, justified, and accords with these principles.

The following principles apply to the management of log data: 

  • Log data processing is defined on a log source basis and the lawfulness of processing is ensured throughout the lifecycle of the data. Special attention is paid to communication logs and logs containing personal data. 
  • Access to log files is only granted based on a need.
  • Log files are protected in such a way that they cannot be accessed by anyone else than authorised persons.
  • Log files are protected which means that they cannot be altered.
  • Log files are stored and transferred in such a way that their user value is not compromised.
  • Hazardous task combinations of those involved in log data processing are identified and the risks are managed. 
  • The management of log data must be described in writing.
  • The storage and handling of log data consider the data protection requirements of the log source.
  • As a rule, centralised log management must be used. Centralised log management does not need to be used when it is not appropriate.  
  • In each log file produced, a minimum amount of information must be saved to fulfil the log’s purpose of use. 
  • If the log contains personal data, an assessment of the risks to the rights of the data subjects, including a data protection impact assessment (DPIA) if necessary, is carried out as required by data protection legislation.
  • The clocks of all log sources and processing systems must be synchronised to ensure the accuracy of the time stamps in log data. 
  • Log data have a predefined retention period after which they are destroyed. 
  • Log data may only be used to protect the technical environment, system, application or user, to detect security breaches and to improve the technical environment, system or application. 
  • In other cases, the exception procedure is applied to monitor compliance with the data protection principles.

Roles and responsibilities in log processing 

The roles and responsibilities of those involved in the processing of log data must be well defined and based on necessary tasks. Each person who has a role in log processing should understand the responsibilities and obligations associated with their role. Special care must be taken when handling log data.

The roles and responsibilities involved are set out in the annex “Log management roles and responsibilities”.

Exceptions

Exceptions from these principles are possible based on documentation and risk assessment. Such deviations are approved by the owner of this document.

Annex 1: Log management roles and responsibilities 

The purpose of this Annex is to set out the roles and responsibilities unique to log management which are not part of the responsibilities already defined elsewhere. 

 President 

  • Approves the log data policy. 
  • Is responsible for the conditions under which the policy is implemented.

System owner 

  • Is responsible for the design, definition, implementation, and documentation of the logs in the systems he or she owns.
  • Is responsible for the implementation of the previous point with the assistance of experts. Outsourcing an implementation does not remove the responsibility. 

Chief Information Officer 

  • Is responsible for the technical and administrative requirements of log management. 

Information Security Manager

  • Is responsible for monitoring the information security of log management and compliance with log data policy.
  • Is responsible for drafting log management policies. 

Data Protection Officer

  • Oversees the implementation of data protection principles. 
  • Participates in the handling of security breaches related to personal data. 

Person responsible for a system

  • Is responsible for processing the log generated by the system in accordance with the policies. 

Annex 2: Types of logs 

This annex supports the log data policy by describing different log types and their recommended minimum contents. The list of logs is not exhaustive, and the recommendations are not prescriptive. Changes to the recommendations are possible if the system/application is unable to produce what is recommended or it is otherwise not sensible to collect the information mentioned. It is recommended that changes are recorded as part of log documentation.

The annex is intended for log designers, log collectors, staff working with logs and those interested in logs. 

Maintenance log 

A maintenance log is used to collect information on changes to the system’s operations, updates, or configuration, on changes in the access rights to system maintenance and to manage malfunctions. The maintenance log is necessary for version control and monitoring the overall architecture of the system environment. 

Recommended 

  • time stamp 
  • logins and logouts 
  • username or other identifier, role, IP address or terminal device (eg from a console, remote connection, UserAgent) 
  • unsuccessful logins and their reasons 
  • changes to maintenance user accounts 
  • things that have been done (eg measures/changes/additions to the device/operating system/application) 

It may also be necessary to log 

  • malfunctions related to maintenance, changes or upgrading 
  • data read with a device or retrieved data eg for reporting purposes (eg diagnostic data, configuration data, etc.) 
     

Event log 

The event log is the most common and necessary log type. It records user logins and logouts, normal system operations and operations performed by applications running on the system. Modules in the system may leave a trace in the event log when calling other modules. 

Recommended 

  • logins and logouts 
  • username or other identifier, role, IP address or terminal device (eg from a console, remote connection, UserAgent) 
  • unsuccessful logins and their reasons 
  • login and logout times 
  • changes of users or user rights 
  • creation and removal of files and data 
  • editing files or data when they are personal data or confidential information 
  • viewing, copying, printing or downloading files or data in the case of sensitive personal data or confidential data 

 In addition, it may be necessary to log 

  • the module that called or was called 
  • information relevant to using the system 
  • error/failure/performance events resulting from use 
     

Change log 

The change log records the additions, deletions and modifications of data and changes to the systems. The origin of changed data must be traceable from the log entries so that its accuracy can be traced and verified if necessary. Information in the change log may be part of the maintenance or user log.
 

Error log 

An error log is useful for resolving problems. When the cause of an error is recorded in the log as precisely as possible it is easier to correct. 

Recommended

  • error/failure/performance events resulting from use 

In addition, it may be necessary to log 

  • volume, capacity, and their anticipated changes 
  • event and capacity information generated by the device or system about its operations 
     

Communication log 

A communication log may contain information about forwarded messages: the origin of the message and where it is targeted, and other information such as time, quantity, unique identifier and status. Communications traffic data are such communication log data. Email, group working, and instant messaging services produce a communication log 

 Recommended 

  • parties to communication 
  • start and end times or the duration of communication 
  • unique identifiers 
     

Holder log 

The holder log tells whom a certain internet address, telephone number or web domain has belonged to at a certain time. Holder data may be directly associated with a person, organisation, or system. 

Recommended 

  • IP address
  • identifier of the holder of an url 
  • contact details 
     

Access control log 

The access control log records both successful and unsuccessful logins and logouts. By analysing the access log, information security breaches can be identified: have there been attempts to crack passwords or to log in with an already expired user account. Access control log data can be collected in maintenance and access logs. 
 

Debug log 

The debug log contains additional information logged separately for troubleshooting the system or an application running on the system. The aim is to direct the data in this log to separate files and to delete it immediately after debugging.  

Log data policy is part of the Terms of use of IT systems

This Log data policy and its annexes have been discussed in the Universities community’s co-operation group on 18 September 2020 and TAMK’s co-operation group on 26 October 2020. The Log data policy is part of the Terms of use of IT systems in the Universities community.

Published: 23.9.2020
Updated: 19.1.2022