10 common findings in a NIS2 compliance audit

Key information

• Hardware is rarely the bottleneck: audits more often reveal missing task ownership than a missing system.
• Infrastructure monitoring and security monitoring answer different questions. Server availability says nothing about whether someone is browsing company data.
• An alert does not close the case. An unassessed report remains an event in the console without a decision or record.
• Compliance must be demonstrated. Without registers, records and test results, an auditor sees a gap even where work is being done.
• NIS2 preparation has a cadence: risk reviews, recovery tests and documentation updates recur at agreed intervals and after major infrastructure changes.

An incomplete asset inventory

The first audit question is what the organisation manages, yet asset lists often stop at the server room. EU implementing rules describe an up-to-date, consistent inventory with change history. An unlisted asset remains outside risk analysis and monitoring.

An audit-ready inventory includes:

• Servers and workstations and the systems running on them.
• Cloud services purchased outside IT.
• Network devices and supplier remote access.
• Test environments created for a project.
• Data and its owners on the business side.

Control question: When did someone last compare the asset inventory with the systems actually operating in the company? Missing 24/7 security monitoring

Server availability and breach detection are two different measurements. National rules call for continuous monitoring, while ENISA guidance adds initial report assessment and response under documented procedures. Practical NIS2 security monitoring requirements begin with the person assessing the event.

Before calling an event an incident, we check whether the account normally behaves this way at this time, whether the configuration change has a maintenance ticket and whether other workstations show the same signal. This assessment takes a VigilHorizon analyst a few minutes and ends with referral for response or documentation as a known false positive.

Control question: Who assesses an event reported on Saturday morning, and where is the result recorded?

Missing Incident Response procedures

An administrator’s phone number can help resolve technical issues, but does not answer regulatory questions: is the event significant and who decides? NIS2 incident management combines operational response with classification and reporting within 24- and 72-hour windows from awareness. Without prior agreement, finding a decision-maker consumes time.

Control question: Does the response procedure name who classifies an incident as significant?

No regular vulnerability assessment

A scanner report shows what was vulnerable on the scan date. Value comes next: assessing exposure, prioritising and resolving critical vulnerabilities without undue delay. A scan without task owners and deadlines remains an open list that nobody closes.

The audit asks for evidence: does the previous report have a decision trail , and who verified remediation? A regular IT security audit reveals vulnerabilities recurring through copied configurations.

Control question: Which critical vulnerabilities from the latest scan have an owner and remediation deadline today?

Untested backups

A backup that has never been restored remains an assumption. Implementing rules require regular recovery tests and recorded results. Testing examines two objectives beyond the backup console: RTO, the target service restoration time, and RPO, the tolerable data-loss window. Without documented recovery, the backup schedule is known but the return-to-operation time is not. The audit also checks backup scope.

Control question: How long did the last recovery of a critical service take, and who confirmed the result?

Excessive user privileges

Accounts with more privileges than necessary can turn a minor event into a serious incident. Implementing rules call for least privilege, periodic access reviews and MFA (Multi-Factor Authentication) for privileged accounts. A shared account undermines accountability — after an incident, it may be impossible to determine who performed an operation.

Access reviews easily fall out of step with staff changes: project or previous-role privileges remain unused on an account. Temporary elevation also persists if nobody sets an expiry. Misuse first appears in security events, which someone must review around the clock. This is the purpose of our round-the-clock security event handling.

Control question: Can you identify by name who logged into the administrator account yesterday?

No network segmentation

A flat network can expose the rest of the environment from one compromised workstation, enabling lateral movement. Dividing it into zones makes attack spread more difficult, although it does not eliminate it. Auditors therefore examine inter-zone traffic rules and who can change them.

Slowing movement gives defenders time to notice and block it before it crosses further zones. Traffic rules should follow risk assessment, not the history of accumulated access grants.

Control question: What would an attacker see after compromising one accounting workstation?

No risk management process

Risk management is easy to overlook because it has no dedicated console or notifications. National rules provide for an ISMS and systematic risk assessment, including supplier dependencies. Auditors look for a recurring cycle: when the assessment was last updated and who approved accepting risk without action.

Control question: Which manager approved the latest risk assessment, and what action followed?

Missing documentation and evidence

The Directive requires organisations to demonstrate their measures. Audits therefore assess both actual conditions and the ability to prove them. In this area, NIS2
gap analysis often finds that work happens but leaves no trace. Delegating tasks does not remove accountability.

Common audit evidence includes:

• A policy with a review date and the approver’s signature.
• An incident register with classifications and reporting times.
• Recovery test results and conclusions.
• A history of changes to configurations and permissions.

Control question: If an auditor asked today for evidence of the latest access review, how long would it take to find?

Treating compliance as a one-off project

A typical organisation completes deployments before a deadline, then enters an audit a year later confident of compliance. Findings span event handling, response, vulnerabilities and documentation, often because processes drifted after staff changes. Compliance drifts as the infrastructure changes.

That is why our reviews revisit findings from the previous quarter and check which issues recurred despite fixes. This shows whether recommendations became more than report entries.

Control question: What triggers reassessment: the calendar, an infrastructure change or a letter from the authority?

How to prepare for an audit

NIS2 preparation involves collecting evidence already produced through daily work. In practice, this means four actions: update the asset inventory, review access, test service recovery and organise the incident register. Compliance assessment then proceeds more efficiently. The sequence is described in preparing an organisation for an NIS2 compliance audit.

The material usually exists but lacks organisation and dates. This is often the starting point for audits in companies without a security team. Comparing requirements with evidence of their application — gap analysis — reveals the difference between declarations and reality. A broader scope is covered by a security audit.

Ten assessment areas with indicative risk levels, depending on impact and service exposure:

Area	What audits commonly find	Indicative risk level
Asset inventory	an inventory missing cloud services and test environments	high
Security monitoring	events collected without assessment or response	critical
Incident response	missing classification thresholds and reporting paths	critical
Vulnerability management	scans without priorities or remediation deadlines	high
Backups	no documented recovery tests	critical
User privileges	shared accounts and access retained after role changes	high
Network segmentation	a flat network and unreviewed traffic rules	medium
Risk management	a one-off assessment without a review cycle or approval	high
Documentation and evidence	actions without records or review dates	high
Maintaining compliance	no review cadence after implementation	medium

Recommended remediation in four particularly significant areas:

Area	Most common problem	Recommendation
Monitoring	no assured alert handling	24/7 security monitoring with assigned report handling
Backup	copies made without testing	regular recovery tests with recorded results
Incidents	no response procedure	a documented Incident Response process with thresholds, roles and deadlines
Documentation	outdated policies and registers	periodic reviews with dates and accountable owners

For decision-makers, the pre-audit task is to establish which areas have an owner and which do not. Unowned areas keep reappearing in findings regardless of how many tools operate there.

Missing records become apparent within minutes: I ask for the latest access review date and hear that someone surely did it and will look for an email. The conversation shifts from controls to recollection, and recollection is not evidence.

Summary

These ten areas point to one conclusion: NIS2 compliance lives in daily work, not a list of completed deployments. Start with who handles events and what written record remains. In practice, both answers take the same form: a named person with defined duties and a deputy for absences.

If any point lacks a clear answer, we suggest starting with an NIS2 compliance audit and gap analysis, leading to a remediation plan with priorities and deadlines. Discussing actual conditions takes less time than another deployment made without assessment.

Frequently asked questions (FAQ)

How does gap analysis differ from a compliance audit?​

Gap analysis compares actual conditions with requirements and identifies differences. A compliance audit additionally evaluates whether implementation can be demonstrated. Gap analysis is therefore often a first step.

Does every organisation covered by NIS2 face the same requirements?​

Obligations vary with entity classification and service-related risk. The first step is formally establishing status.

How often should compliance be reassessed?​

The cycle follows risk and environmental change. Major infrastructure or supplier changes also require review. Every scheduled assessment needs a defined scope.

Does an audit cover documentation and evidence?​

Yes. Currency often matters more than a file’s existence. An old policy or unapproved procedure may become a finding just like a missing document.

Does compliance require purchasing an external SOC (Security Operations Center)?​

Regulations specify the capability: continuous monitoring and security event handling. Whether an internal team or external partner delivers it is the organisation’s decision.

Where should you start with a limited budget?​

Organise the asset inventory and establish who handles reports outside office hours. Both mainly require time.

Learn more

• A cyberattack starts earlier than you think: the first signs nobody notices
• A day in the life of a SOC analyst: inside 24/7 security monitoring
• ISO 27001 and NIS2: similarities and key differences