3.2 Monitoring and logging

Requirement

The relevant entities shall lay down procedures and use tools to monitor and log activities on their network and information systems to detect events that could be considered as incidents and respond accordingly to mitigate the impact.

Guidance

• Identify one or more objectives of monitoring and logging (indicative, non-exhaustive list):
  • threat detection,
  • compliance assurance,
  • incident response support,
  • performance optimisation,
  • anomaly detection,
  • monitor for new vulnerability reports issued for any free and open source software components (21) used by the entity,
  • data loss prevention,
  • forensic investigations support and
  • network health monitoring.
• Procedures should describe (indicative, non-exhaustive list):
  • objectives,
  • data for collection and relevant tools,
  • description of data algorithms and
  • mechanisms for notifying the relevant personnel.
• Select tools that serve the objectives of monitoring and logging according to specific criteria (indicative, non-exhaustive list):
  • ease of use,
  • integration with the existing network and information system, including cross-border operations and the associated regulatory, security and performance considerations,
  • minimisation of manual intervention,
  • capability of collecting data from various sources, for example networks, systems and applications,
  • security features offered, for example encryption and access control and
  • costs and licencing.

Examples of evidence

• Procedures in place.
• Tools in place.
• Configuration settings of the logging function that serve the identified objectives.
• Configuration settings of the logging function in line with documented standards and/or good practices.
• Safeguards to protect the confidentiality, integrity and availability of logs.

Requirement

To the extent feasible, monitoring shall be automated and carried out either continuously or in periodic intervals, subject to business capabilities. The relevant entities shall implement their monitoring activities in a way which minimises false positives and false negatives.

Guidance

• To minimise false positives and false negatives, to the extent feasible, consider one or more of the following (indicative, non-exhaustive list):
  • establish network traffic patterns;
  • use analytics and machine learning algorithms;
  • continuously update the automated monitoring tools to adapt to new threats and changes in the environment; and
  • fine-tune the parameters and thresholds based on the latest data and feedback.
• Where appropriate, ensure that all potential risks are properly covered by relevant use cases, for example use case for access to critical data, use case for data exfiltration or use case for ransomware infection, so that no critical threat goes undetected.

Examples of evidence

• Acceptable log monitoring, collection, storage and analysis tools, in line with the state of the art.
• Security Incident and Event Management (SIEM) systems used to analyse data and identify deviations from established patterns.
• Endpoint detection and response (EDR) and Extended Detection and Response (XDR) tools in place.
• Mechanisms that aim to minimise false positives and false negatives are in place.
• Where appropriate, mapping use cases to potential risks to ensure comprehensive and effective monitoring.

Requirement

Based on the procedures referred to in point 3.2.1., the relevant entities shall maintain, document and review logs. The relevant entities shall establish a list of assets to be subject to logging based on the results of the risk assessment carried out pursuant to point 2.1. Where appropriate, logs shall include: (a) relevant outbound and inbound network traffic; (b) creation, modification or deletion of users of the relevant entities’ network and information systems and extension of the permissions; (c) access to systems and applications; (d) authentication-related events; (e) all privileged access to systems and applications and activities performed by administrative accounts; (f) access or changes to critical configuration and backup files; (g) event logs and logs from security tools, such as antivirus, intrusion detection systems or firewalls; (h) use of system resources, as well as their performance; (i) physical access to facilities; (j) access to and use of their network equipment and devices; (k) activation, stopping and pausing of the various logs; (l) environmental events.

Guidance

• With regard to critical configuration, consider the settings and parameters that are vital for the proper functioning, security and performance of the entity’s network and information system. These configurations are vital because any changes or misconfigurations might have a significant impact, including system outages, security vulnerabilities or reduced performance of the entity’s network and information system.
• Consult the risk assessment results to determine which network traffic needs to be logged. For example, if certain assets are identified as high risk (e.g. due to being potentially vulnerable or crucial to the business operation) their inbound and outbound traffic should be logged for monitoring and analysis.

Examples of evidence

• Samples of log files containing the elements referred to in point 3.2.3 of the Annex to the regulation.
• Samples of log files containing current and historical domain name system (DNS) and dynamic host configuration protocol (DHCP) logs.

Requirement

The logs shall be regularly reviewed for any unusual or unwanted trends. Where appropriate, the relevant entities shall lay down appropriate values for alarm thresholds. If the laid down values for alarm threshold are exceeded, an alarm shall be triggered, where appropriate, automatically. The relevant entities shall ensure that, in case of an alarm, a qualified and appropriate response is initiated in a timely manner.

Guidance

• Consider the use of anomaly detection or adaptive alarm thresholds to complement traditional static rules.
• Make sure that procedures are designed to detect network-based attacks based on anomalous inbound and outbound ingress or egress traffic patterns and/or denial of service (DoS) attacks, in a timely manner.
• Make sure that alarm thresholds, where appropriate, have been set in alignment with the results of the risk assessment carried out pursuant to point 2.1, covering at least the situations in point 3.2.3 of the Annex to the regulation. An indicative, non-exhaustive list of examples with thresholds (22) follows:
  • relevant outbound and inbound network traffic: traffic volume spikes exceeding 50% of normal traffic in a 10-minute period on a specific port;
  • access to systems and applications: three or more account lockouts within 15 minutes;
  • privileged access: two or more instances of privilege escalation (e.g. normal user to admin) within 24 hours (23);
  • antivirus: malware is detected on multiple endpoints within a short timeframe;
  • use of system resources: installations of unauthorised software within a short timeframe.

Examples of evidence

• Regular reports that summarize log data and highlight any anomalies detected.
• Alarm thresholds set.
• Records from past alarm triggers when thresholds were exceeded.
• Existing workflows that trigger event reporting (section 3.3).

Requirement

The relevant entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes.

Guidance

• Make sure that the log retention period is defined in accordance with business needs, the risk assessment results and legal requirements/obligations.
• The backup logs’ maintenance period shouldn’t be shorter than the logs’ review period, referred to in point 3.2.4 of the Annex to the regulation.
• The retention period should be in line with what is referred to in point 4.2.2 (f) of the Annex to the regulation.
• Delete data when the retention period ends.
• Consider mechanisms to protect logs from unauthorised access or changes (indicative, non-exhaustive list):
  • encryption,
  • access control,
  • hashing (section 9.2) and
  • logging of all access and changes to log files.
• The access control should be in line with what is referred to in point 4.2.2 (d) of the Annex to the regulation.

Examples of evidence

• A retention period is set.
• The retention period is in line with what is referred to in point 4.2.2 (f) of the Annex to the regulation and is shorter than the logs’ review period, referred to in point 3.2.4 of the Annex to the regulation.
• Log management is in place.
• Logs do not contain data about which retention periods have expired.
• Access control mechanisms are in place.
• Access control is in line with what is referred to in point 4.2.2 (d) of the Annex to the regulation.

Requirement

To the extent feasible, the relevant entities shall ensure that all systems have synchronised time sources to be able to correlate logs between systems for event assessment. The relevant entities shall establish and keep a list of all assets that are being logged and ensure that monitoring and logging systems are redundant. The availability of the monitoring and logging systems shall be monitored independent of the systems they are monitoring.

Guidance

• Consider the following for time synchronisation:
  • Utilize Network Time Protocol (NTP) servers or Precision Time Protocol (PTP) for accurate and reliable time synchronization (24).
  • Use authenticated NTP to prevent malicious entities from tampering with your time synchronization.
  • Configure a central time server within the entity (25). This server should synchronize with a reliable external time source and then distribute the time to all other systems within the network.
  • Use multiple time sources to avoid a single point of failure.
  • Plan how time synchronization is handled across on-premises systems (for example servers in a company's own data centre), cloud services, and software-as-a-service (SaaS) platforms - especially if the organization uses a hybrid environment (a mix of on-premises and cloud-based systems).
• Assets being logged should be marked as such in the asset inventory, in line with what is referred to in point 12.4 of the Annex to the regulation.
• Implement measures to protect log data against loss, including but not limited to redundant storage across multiple locations (e.g. cloud, secondary servers), retention of processed log events in structured systems and preservation of derived security insights (e.g. alerts, metrics) in line with what is referred to in point 4.2 of the Annex to the regulation. These complementary approaches ensure both data integrity and operational continuity in security monitoring and incident response.
• Deploy separate tools to monitor the capacity and availability of the entity’s primary monitoring and logging systems.

Examples of evidence

• Mechanisms for logs’ time synchronisation.
• Mechanisms for logs’ redundant storage.
• Logs from the activity of the tools that monitor the capacity and availability of the entity’s primary monitoring and logging systems.

Requirement

The procedures as well as the list of assets that are being logged shall be reviewed and, where appropriate, updated at regular intervals and after significant incidents.

Guidance

• Determine the frequency of reviews based on the risk assessment results related to the criticality of the assets, ensuring that reviews are conducted at least annually.
• Include the t esting of monitoring and logging procedures in security testing (section 6.5).
• Review a random sample of logs to verify that all the assets that should be subject to the log are actually considered.

Examples of evidence

• Review plans or schedules.

Tips: guidance

• In addition to the elements mentioned in point 3.2.3 of the Annex to the regulation, last login for every account should be logged.
• Document monitoring and logging procedures.
• Assess the frequency of monitoring activities to ensure they are sufficient to support risk-based security decisions for adequately protecting the entity’s network and information systems.
• Make sure that personal data that are included in the logs is not processed unnecessarily. When required, an additional level of protection is deployed after performing a data protection impact assessment.
• Determine the log baselines in line with the needs and the capabilities of the business (indicative, non-exhaustive list):
  • structured or semi-structured, if possible, instead of unstructured format;
  • consistent data format in line with the selected tools and well-known standards, for example JavaScript Object Notation and extensible markup language (XML);
  • log level in line with the classification level of the asset being logged – the entity should assign a higher log level, for example ‘error’/‘fatal’, to highly classified assets while the lower log levels, for example ‘info’/‘debug’, should be used for assets with a lower classification; and
  • the standard for the timestamps, for example ISO-8601 (26), RFC 3339 (27) or RFC 9557 (28).
• Each log entry should contain necessary metadata such as (indicative, non-exhaustive list):
  • log level;
  • timestamp;
  • source identifier, for example the application or the device relevant to the entry; and
  • a unique identifier for the entry.
• Correlate data from different sources, if applicable.
• Select tools that monitor and protect end point devices.
• Select tools that can collect and analyse network traffic in real time to detect anomalies, data exfiltration and even the most advanced threats, while offering the option of automatic remediation.

Tips: examples of evidence

• Documented procedures.
• Log baselines in place.
• Logs (samples) containing necessary metadata.
• EDR tools.
• Network detection and response (NDR) tools.