One of the most practical NIS2 questions is also one of the easiest to answer badly: what exactly should we log? Many organisations respond in one of two weak ways. They either start collecting almost everything without clear priorities, or they leave logging in local defaults and hope it will somehow be enough during an audit or incident. Neither approach works well.
The goal is not to generate the largest possible volume of data. The goal is to retain useful records from the systems that matter most for audit traceability, incident timelines and defensible decision-making. That is why prioritisation matters more than volume.
This material does not constitute legal advice or a definitive checklist of obligations. It is a practical framework for identifying a sensible logging minimum in SMB and mid-sized environments.
Who this page is for
This page is intended for:
- IT managers and infrastructure leads,
- external administrators and MSPs,
- leadership teams that need to understand why logging priorities matter,
- security roles building a minimum audit and incident evidence baseline.
What you will take away
After reading, you should be clearer on:
- why prioritised logging is more valuable than indiscriminate collection,
- which infrastructure layers usually matter most for audit and incidents,
- how to separate a sensible minimum layer from broader coverage,
- how to make trade-offs when budget and capacity are limited,
- why critical records should be retained outside source systems.
Why collecting everything is not the answer
When organisations collect logs without priorities, they often run into three problems:
- they drown in volume and lose visibility,
- they spend budget on low-value data,
- they still miss the records that matter most for identity, privileged change or remote access.
For SMB and mid-sized organisations, it is usually far more effective to start with a simple question: which systems and events will matter most when we face an audit, an incident or an internal investigation?
How to think about critical systems
The most important systems are not always the noisiest ones. The priority systems are usually those that determine:
- identity and access,
- privileged changes,
- remote connectivity,
- network movement,
- delivery of critical services,
- management of virtualisation and storage,
- access to cloud and SaaS platforms.
In practice, it helps to think in two layers:
- a minimum layer without which the audit and incident picture is weak,
- an extended layer that adds wider context and analytical value.
It also helps to test each source against a small set of questions:
- does it show who made a change,
- does it show who gained or used privileged access,
- does it help explain remote access or lateral movement,
- does it clarify what happened just before an outage or suspicious event,
- does it confirm or challenge an incident hypothesis.
If a source does none of these things, it is often a second-phase candidate rather than part of the first logging baseline.
Minimum layer: identity and Active Directory
If the organisation runs Active Directory or another central identity platform, this is almost always the first priority. Identity events are often the backbone of the evidence trail.
Priority records typically include:
- successful and failed sign-ins,
- password changes and resets,
- account creation and deletion,
- group and privilege changes,
- changes to administrative accounts,
- MFA and conditional access events where applicable.
Why this matters:
- identity tells you who did what,
- many attack paths hinge on identity abuse,
- without identity records, privilege escalation and administrative change are much harder to reconstruct.
Minimum layer: Windows servers and selected endpoints
Not every endpoint needs to be in the first wave. But some systems usually do:
- domain controllers,
- jump hosts,
- admin workstations,
- key application servers,
- servers hosting sensitive data or critical services.
The most useful records often include:
- sign-in activity,
- privileged actions,
- service and scheduled task changes,
- disabling of security controls,
- system events related to operational anomalies.
These systems often define the incident timeline.
Minimum layer: firewalls, VPN and network devices
The network layer is essential because it helps show:
- where access came from,
- what remote connectivity existed,
- how administrative access was performed,
- whether traffic patterns were unusual,
- when rules or configurations changed.
Typical priority sources include:
- firewalls,
- VPN gateways,
- reverse proxies and edge gateways,
- selected switches and routers,
- segmentation controls around critical systems.
Without this layer, it is much harder to understand spread, exposure and boundaries during an incident.
Minimum layer: hypervisors, NAS and infrastructure appliances
Virtualisation, storage and infrastructure appliances are often logged too late or not at all. Yet they can hold highly relevant evidence.
Useful records often include:
- administrator logins,
- configuration changes,
- creation, deletion and movement of virtual machines,
- snapshot and datastore activity,
- security and system events from the appliance itself.
This becomes especially important where virtualisation and storage underpin critical business services.
Minimum layer: cloud and SaaS systems
Many organisations no longer run critical services only on-premises. Without cloud and SaaS records, the audit and incident picture is incomplete.
Priority examples include:
- identity and sign-in records from Microsoft 365 or Google Workspace,
- tenant-level administrative changes,
- audit and security records from cloud platforms,
- privileged activity in business-critical SaaS tools,
- key control-plane events in IaaS and PaaS environments.
Ignoring this layer creates a serious blind spot.
What organisations most often underestimate
The most overlooked sources are often not the obvious business servers, but the control points around them:
- management interfaces for firewalls and appliances,
- administrative accounts in cloud tenants,
- VPN configuration and access changes,
- hypervisor and storage events,
- records from remote administration tools used by internal teams or suppliers.
These layers often explain how an intrusion or administrative mistake actually spread. Without them, an organisation may collect a large amount of technical data and still miss the decisive evidence.
Extended layer: where broader coverage makes sense
Once the minimum layer works, broader coverage can be added based on risk and capacity. Typical examples include:
- wider endpoint coverage,
- application logs from important internal systems,
- richer network telemetry,
- specialised security appliances,
- correlation and analytics layers with longer-term context.
This extended layer should follow real risk and use cases, not the abstract desire to “log everything just in case”.
How to prioritise with limited budget and capacity
If budget is constrained, use a simple filter.
1. Does this source help explain who did what?
If yes, it is a high priority.
2. Does this source help build an incident timeline?
If yes, it is a high priority.
3. Does this source help support an audit claim?
If yes, it is a high priority.
4. Is this source currently risky because the records exist only locally?
If yes, it should move up the centralisation list.
This usually leads to the same first wave: identity, firewalls, VPN, key servers and cloud identities.
Good prioritisation also means consciously delaying some data sources. A common mistake in SMB and mid-sized environments is to start with broad endpoint telemetry, verbose application logs or large network datasets before the organisation can reliably answer basic questions about identity, privileged change and access history. That creates volume without defensible clarity.
Why logs need to be centralised outside source systems
Even the right log sources are not enough if the records stay only on the local system. During compromise, attackers often try to alter, delete or disable local records. That is why critical logs need to be sent and retained outside the systems they come from.
Centralised collection outside source systems materially reduces the risk of:
- losing critical records,
- history being manipulated,
- important events being overwritten,
- the evidence trail becoming unavailable during an incident.
The audit and defensibility angle is explored further in Audit, traceability and evidence.
What a practical minimum looks like for SMB and mid-sized organisations
If you need a pragmatic starting point, a sensible minimum often means:
- centralising identity, firewall, VPN and key server logs,
- adding cloud identity and major SaaS administrative logs,
- verifying that the sources are actually delivering data,
- retaining the evidence outside source systems,
- being able to search by time, system and identity quickly.
That is often much more valuable than launching a broad project without clear priorities.
It is just as important to verify that this minimum actually works. A source is not truly covered just because it was added to a configuration. You should know:
- that records arrive consistently,
- that they remain readable over time,
- that a concrete login, change or alert can be retrieved,
- that broken collection will be noticed quickly,
- that critical evidence is not trapped in a local file on the affected system.
That operational validation is what turns a logging design into a defensible baseline.
Practical recommendations
If you want to bring order to the topic quickly:
- list your critical services and systems,
- identify which records carry the highest audit and incident value,
- define the first-wave minimum,
- centralise retention outside source systems,
- verify that you can reconstruct a concrete scenario from the data rather than merely confirming that logs are “being sent”.
If you need the wider strategic context, go back to NIS2 and log retention.
FAQ
Should we collect every Windows event?
Usually not. Start with events that matter most for identity, privilege, change and security anomalies.
What is the first priority if budget is limited?
For most organisations: identity, firewalls, VPN and key servers. These sources tend to define both audit quality and incident traceability.
Is it enough if we can pull logs from devices when needed?
That is still a weak model. During compromise or outage, access may be delayed and the records may already be incomplete or altered.
Internal links
- Back to the NIS2 overview
- Does your organisation fall under NIS2?
- NIS2 for company leadership
- Audit, traceability and evidence
Next step
- Get the minimum logging standard for SMB and mid-sized organisations.
- Get a readiness assessment of priority sources and retention.
- Request an initial consultation on mapping the first-wave logging baseline for audit and incidents.