NIS2 is often introduced as a legal or compliance topic. In practice, it is also an operational and management topic. The organisations that cope best are usually not the ones with the most paperwork or the most tools. They are the ones that can explain what happened, when it happened, which systems were affected and what evidence supports their decisions. That is where logging, retention and traceability become central.
For many mid-sized organisations, the challenge is not whether cybersecurity matters. It is how to move from fragmented controls to a defensible operating baseline. NIS2 raises the bar because it brings governance, risk management, incident reporting and evidence together. A policy may describe how your organisation should behave. Logs help demonstrate how it actually behaved.
This material does not constitute legal advice. It is a practical guide for executives, IT managers, infrastructure leaders, MSPs and security or compliance roles that need to understand the operational implications of NIS2.
Who this page is for
This page is written for:
- executives, managing directors and business owners,
- IT managers and heads of infrastructure,
- external administrators and MSPs,
- security, risk and compliance teams,
- organisations unsure whether they are directly in scope or indirectly affected through regulated customers.
What you should take away
By the end, you should have a clearer view of:
- what NIS2 is and why it matters beyond legal interpretation,
- which organisations are typically affected,
- why documentation alone is not enough,
- why logs matter for audits, incidents and traceability,
- which log sources usually matter first,
- why local logs are a weak point during compromise,
- when a centralised or SaaS model is a sensible next step.
What NIS2 changes in practice
NIS2 is the EU directive designed to raise the common level of cybersecurity across Member States. It extends the scope of the original NIS framework, introduces stronger supervisory and enforcement mechanisms, and places more explicit accountability on top management. It also strengthens incident reporting expectations and formalises a risk-based approach to cybersecurity measures.
That matters because NIS2 is not limited to a narrow class of “critical infrastructure” operators. It reaches a wider set of sectors and a larger number of medium-sized organisations. It also changes the quality of the conversation inside the business. Cybersecurity is no longer something leadership can safely treat as a purely technical concern delegated to IT.
At EU level, Member States were required to transpose the directive by 17 October 2024. In the Czech Republic, the new Cybersecurity Act was published on 4 August 2025 and took effect on 1 November 2025. For organisations operating in Czechia, that means NIS2 is no longer a future requirement. It is part of the current regulatory landscape.
Why NIS2 matters to management as well as IT
Executives tend to ask whether NIS2 creates extra cost, more paperwork and more personal exposure. IT teams tend to ask what has to be implemented, what evidence is needed and how quickly the organisation has to respond during an incident. Both perspectives are valid, and both lead to the same conclusion: NIS2 is about operating maturity, not only formal compliance.
From a management perspective, NIS2 matters because:
- leadership is expected to oversee cybersecurity risk management,
- the organisation must be able to justify decisions made during incidents,
- reputational and operational impact now sits closer to board-level accountability,
- audit readiness is no longer only a documentation exercise.
From an IT perspective, NIS2 matters because:
- controls need to be demonstrably operational,
- evidence and traceability matter as much as policy wording,
- incident timelines have to be reconstructed quickly and credibly,
- fragmented local logging is hard to defend under scrutiny.
The management angle is covered in more detail on NIS2 for company leadership.
Which organisations are typically in scope
NIS2 applies to organisations operating in sectors considered important for the economy, society or public services. Typical examples include energy, transport, healthcare, digital infrastructure, public administration, certain manufacturing segments, ICT service management, digital services, wastewater and waste management, and other sectors named in the directive or national implementation.
In practice, however, scope is rarely determined by one factor alone. Organisations usually need to consider:
- the type of service they provide,
- the sector they operate in,
- their size,
- whether they are part of a group,
- whether they play a meaningful role in a regulated supply chain.
That is why the question “are we critical infrastructure?” is often too crude to be useful. A better first question is whether the organisation provides a regulated service and whether the combination of sector, size and role places it in scope.
For a practical first-pass assessment, continue to Does your organisation fall under NIS2?.
Lower and higher obligations are not just legal labels
In the Czech context, organisations will often hear about lower and higher regimes. For a wider European audience, it is better to think in terms of different supervisory intensity and obligation depth rather than assume one universal naming convention. What matters operationally is that some organisations will face stricter supervisory expectations, stronger evidence demands and a greater burden of proving that governance and security controls are functioning.
That distinction is not just a legal nuance. It affects:
- how deeply management oversight needs to be structured,
- how formalised processes and records need to be,
- how much evidence the organisation should expect to retain,
- how quickly technical and organisational decisions must be defensible.
More on that is covered in Different NIS2 obligation levels.
What NIS2 does not automatically mean
It is easy to overreact to NIS2 and assume it requires an enterprise-scale security programme from day one. In most cases, that is the wrong interpretation.
NIS2 does not automatically mean:
- you need to build your own SOC,
- you need a full SIEM platform before you can start,
- a policy pack on its own will be enough,
- local event logs and device-local syslog are a sufficient evidence base,
- responsibility can be outsourced away simply because an MSP runs part of the environment.
For many organisations, a realistic minimum is far more valuable than an ambitious architecture they cannot sustain. The goal is not to collect everything or buy every tool. The goal is to achieve a defensible level of traceability, incident readiness and audit support.
Why documentation alone is not enough
Policies, procedures and assigned roles are essential. But they only describe the intended model. They do not answer the questions that appear during a regulatory review, an internal investigation or a major incident:
- Who accessed the affected system?
- When did the suspicious activity begin?
- What changed before the issue escalated?
- Which accounts were used?
- Which systems were affected, and in what sequence?
- What evidence supports the organisation's understanding of the event?
Without logs and operational records, the response becomes guesswork supported by memory and partial screenshots. That is weak from both an engineering and a governance perspective.
Why logs matter for audits, incidents and traceability
Logs are not just technical exhaust. They are the raw material for evidence.
For audits
Auditors and regulators do not just want a statement that controls exist. They want to see whether key activities can be traced:
- access attempts,
- privilege changes,
- administrator actions,
- critical configuration changes,
- relevant security events over time.
Without that evidence, an organisation may have controls in theory but struggle to prove they were active and effective in practice.
For incident response
When an incident occurs, time matters. A centralised evidence trail helps teams answer basic questions quickly:
- what happened,
- when it started,
- where it spread,
- which systems and identities were involved,
- whether the issue is still ongoing.
If evidence exists only on the affected systems, the investigation is immediately more fragile.
For internal investigations
Not every issue is a headline cyber incident. Many organisations need to investigate administrative errors, unusual access, failed changes, unexpected service disruption or signs of insider misuse. Logs help distinguish between user error, process failure and genuine compromise.
For defensibility
NIS2 incident reporting requirements are time-sensitive. Article 23 of the directive describes early warning within 24 hours of becoming aware of a significant incident and incident notification within 72 hours, followed by later updates and a final report. Organisations do not need a perfect picture in the first hours, but they do need a credible evidence base for their initial assessment. Centralised logs materially improve that position.
Which logs organisations typically need first
A sensible logging baseline usually starts with a handful of evidence-rich systems rather than blanket collection from every device.
Identity and access
Identity systems such as Active Directory, Entra ID and other IAM layers are often the most valuable log source. If you cannot reconstruct authentication, privilege changes and administrator actions, many investigation paths become much weaker.
Key Windows servers and selected endpoints
Not every endpoint has to be in the first wave. But domain controllers, management hosts, core application servers and other privileged systems usually should be.
Firewalls, VPNs and network controls
External access, remote administration and network movement are central to both incident analysis and audit support.
Hypervisors, storage and infrastructure appliances
Virtualisation platforms, NAS devices and specialised appliances often contain highly relevant evidence, especially when they sit close to critical services.
Cloud and SaaS systems
For many organisations, the evidence trail already spans Microsoft 365, Google Workspace, cloud platforms, identity providers and business SaaS tools. Ignoring that layer creates a blind spot.
The practical prioritisation model is covered in Which logs you need for audit.
What a realistic minimum looks like
For most SMB and mid-sized organisations, the right first step is not “collect everything”. It is to establish an evidence baseline that is maintainable.
A practical minimum usually includes:
- centralised collection outside the source systems,
- coverage of identity, core servers, firewalls, VPNs and selected cloud services,
- retention aligned with audit and incident needs,
- routine checks that log collection is actually working,
- the ability to retrieve evidence quickly during investigations.
This approach accepts a simple reality: a smaller organisation still needs traceability, but it may not have the people or budget to run a full-scale in-house analytics stack. That is not a reason to do nothing. It is a reason to prioritise.
Why local logs are a weak point
This is one of the most important practical messages in the whole topic. Logs stored only on the local server, device or application are vulnerable during compromise.
Attackers commonly try to:
- alter local records,
- delete them,
- overwrite them through normal system churn,
- disable or reduce logging,
- make the affected system unavailable before investigators can extract evidence.
When the evidence trail is stored outside the affected system, the organisation materially reduces the risk of losing its most useful records at exactly the wrong time. Centralised collection and retention outside source systems therefore improves audit readiness, incident reconstruction and regulatory defensibility all at once.
That point is explored in more depth in Audit, traceability and evidence.
When a centralised or SaaS approach makes sense
Self-hosted logging and analytics can be the right model for organisations with strong internal capabilities and clear operational reasons to run their own stack. For many mid-sized organisations, however, the more immediate need is to establish dependable retention and traceability without launching a large infrastructure programme.
A centralised or SaaS-oriented approach can make sense when the organisation wants to:
- move quickly,
- reduce operational burden,
- avoid building a full SIEM capability too early,
- retain evidence outside the systems being protected,
- create a usable foundation for later monitoring or reporting improvements.
This is not a product pitch. It is a practical observation: many organisations need an achievable first layer before they can sensibly consider a broader security operations model.
Official sources and further reading
If you are assessing your obligations, start with primary sources and official guidance.
Useful references include:
- the NIS2 directive text on EUR-Lex,
- the European Commission's official NIS2 policy pages and FAQs,
- national guidance from the relevant regulator,
- in the Czech context, the NÚKIB portal, guidance materials and official calculator for the new Cybersecurity Act.
Within this hub, the most useful next pages are:
- Does your organisation fall under NIS2?
- Different NIS2 obligation levels
- NIS2 for company leadership
- Audit, traceability and evidence
- Which logs you need for audit
FAQ
Do we need to collect logs from every system?
No. Most organisations benefit more from focused priority than from indiscriminate collection. Start with identity, key servers, firewalls, VPNs, selected cloud services and other systems with strong audit or incident value.
Does NIS2 mean we need a SIEM immediately?
Not necessarily. You need evidence, traceability and usable retention. For some organisations that will eventually lead to SIEM. For others, centralised collection and retention is the right first step.
Are local logs enough if we keep them for a long time?
Not on their own. Long retention on a compromised system does not solve the core issue: the records are still vulnerable to tampering, deletion or loss of access.
Is this only relevant if we already know we are in scope?
No. The same principles matter for suppliers to regulated organisations and for businesses performing a first internal assessment.
Is there one correct retention period under NIS2?
No single number suits every organisation. Retention should be driven by audit requirements, incident handling needs, risk profile and operational practicality. What matters is that the period is defensible and the data remains usable.
Next step
If you want to turn this into a concrete starting point:
- Download the checklist for an internal first-pass review of NIS2 relevance and current logging maturity.
- Request an initial consultation to define what a realistic evidence baseline looks like in your environment.
- Join early access and updates for a minimum logging standard focused on audit support, incident response and traceability.