control

logging and monitoring

Keeping records of what happens on your systems and watching them for signs of trouble. NIS2 does not list monitoring as a measure of its own. It is the part that makes incident handling and access control possible to show.

last checked 2 November 2026
what it protects
your ability to notice trouble and to reconstruct what happened afterwards
who owns it
head of IT
start with
list the five systems whose logs you would need first and check how long each keeps them

what it is

Logging records what happens on your systems: who signed in, what changed, what was blocked. Monitoring is the watching of those records, and of the systems themselves, for signs of trouble, with an alert when something crosses a line you set.

NIS2 does not list monitoring or logging as a measure of its own. Its text asks for incident handling and for access control, and both need logs to exist: you cannot notice an incident, reconstruct one or show who had access without them. DORA names detection and monitoring directly. For listed digital providers, the Commission’s implementing regulation spells out what to log and how to protect it, and others may use it as a reference.

So the question for most companies is practical. Which systems must be logged for you to answer the questions the rules ask, who looks at the logs, and how long you keep them. No text sets a retention period, so choose one and write the reason down.

basis NIS2 Art. 21(2)(b), 21(2)(i); DORA Art. 10(1); IR 2024/2690 Annex 3.2 as a reference. The log list and the periods are practice.

how a log becomes something you can use

  1. 1systemsservers, cloud, network, identity and email
  2. 2one clockthe same time source, so events can be put in order
  3. 3separate storeits own access limits and a retention period per source
  4. 4alerta threshold and a named person who receives it
  5. 5reviewsomeone looks, and a note records what was found

the same logs help answer

  • an incidentnoticed in time and reconstructed afterwards
  • an access questionwho had access, who used it, when it changed
  • a breach recordwhat was reached, so the facts can be written down

basis NIS2 Art. 21(2)(b), 21(2)(i); DORA Art. 10(1); GDPR Art. 33(5). The stages and the periods are practice.

an example

Picture a company of 150 people that turned logging on everywhere.

weak

Every server keeps its own logs on its own disk and they roll over after a few days. The clocks disagree. Alerts go to a mailbox nobody reads at night. After a break-in, the administrator who got in clears the logs on the machine he used.

solid

The systems that matter send logs to a separate place with its own access limits and one time source. Retention is chosen per source with the reason written down. Each alert has a named recipient, and a monthly review leaves a short note.

An illustration. It is not a real case.

what it has to do for each rule

rulewherewhat the text askswhat the control has to do
NIS2NIS2 Art. 21(2)(b)Incident handling. The article does not name monitoring or logging.Decide which logs you need to notice an incident and to reconstruct one afterwards.
NIS2NIS2 Art. 21(2)(i)Human resources security, access control policies and asset management. The article does not name logging.Keep records of who was given access, who used it and when it was changed.
IR 2024/2690IR 2024/2690 Annex 3.2Listed digital providers: procedures and tools to monitor and log activity on network and information systems to detect events that could be incidents. Logs are kept for a predefined period and protected from unauthorised access or changes.Use the list of event types as a starting point for your own list of what to log.
IR 2024/2690IR 2024/2690 Annex 11.2.2(f)Listed digital providers: log the management of access rights.Keep the log of grants, changes and removals of access.
DORADORA Art. 10(1)Mechanisms to promptly detect anomalous activities, regularly tested. Detection sets alert thresholds and automatic alerts to the staff in charge of response, and gets enough resources to monitor user activity.Set alert thresholds, name who receives the alert and test that it arrives.
DORADORA Art. 17(3)(b)Procedures to identify, track, log, categorise and classify ICT-related incidents.Keep the incident record in the same place as the logs that triggered it.
GDPRGDPR Art. 33(5)Document every personal data breach with facts, effects and action taken.Keep logs long enough to show what was accessed when a breach happens.

basis NIS2 Art. 21(2)(b), 21(2)(i), neither of which names logging or monitoring; IR 2024/2690 Annex 3.2 and 11.2.2(f) as a reference for listed digital providers only; DORA Art. 10(1), 10(2), 10(3), 17(3)(b); GDPR Art. 33(5). What the control has to do is practice.

what to look for when you choose

  • Can it collect from every system you named, such as servers, cloud services, network equipment, identity and email, and how do you add one?
  • Does it keep the time stamps consistent across systems, so that events can be put in order?
  • Does it let you set alert thresholds and send an alert to a named person, by phone or message, at any hour?
  • Who reads the alerts? If the answer is nobody outside office hours, what is the plan?
  • How long does it keep logs, can you set the period per source, and can it hold them where they cannot be changed?
  • Who can read, change or delete logs, and is that access itself logged?
  • Does it tell you when a source stops sending, or when someone switches logging off?
  • Where are the logs stored, and does that location fit your rules on personal data?
  • What does it cost as data volume grows, and what happens to the logs when you leave?

basis working practice. No legal text sets this.

three levels, from first step to strong

Each level adds something visible. Stop where the risk you accepted allows.

  1. start

    List the systems you would need logs from first. Turn logging on there and check how long each one keeps the records.

  2. solid

    Send logs to a separate place, use one time source, set alert thresholds with named recipients and write down the retention period per source.

  3. strong

    Detect when a source goes silent or logging is switched off, restrict who can read or delete logs, and test that an alert reaches a person after hours.

basis working practice. No legal text sets this.

where it goes wrong

logs nobody reads

Collecting everything and reviewing nothing leaves the logs useful only after the damage. Decide who looks at what, how often, and what triggers an alert.

too short a memory

Logs that roll over after a few days cannot answer what happened last month. No text gives a number, so choose a period per source and write the reason down.

logs on the system they describe

An attacker with administrator rights can clear logs kept on the same machine. Send them to a place with separate access.

clocks that disagree

If systems keep different times, events cannot be put in order. Use one time source across the estate.

personal data in the logs with no rule

Logs of user activity are personal data. Say who may read them, for what purpose and for how long.

basis working practice. No legal text sets this.

the proof it leaves

what you can showwho owns itrefresh
list of systems that are logged, with the event types and retention for eachhead of ITtwice a year
alert rules, thresholds and the name of who receives each alerthead of ITtwice a year
sample log extract for one past event, showing who did what and whenhead of ITquarterly
record of a review of the logs or alerts, with what was found and donehead of ITmonthly
settings showing who can read, change or delete logshead of ITyearly

basis practice. The rhythms and retention periods are your choice.

09

check it yourself

your next step

List the five systems whose logs you would need first in an incident, and check today how long each one keeps them.

open the incident reporting work