NIS2 compliance audit — how to prepare your organisation
28 July 2026

An NIS2 compliance audit assesses the organisation’s ability to manage risk, detect incidents and respond quickly. When management asks 'Are we ready?’, the answer lies in those capabilities and their supporting evidence. The audit structures them against requirements introduced on 3 April 2026 through the amendment to Poland’s National Cybersecurity System Act implementing NIS2. Its value emerges in the action plan; the report is only the beginning.
Key information:
- The audit assesses capabilities, not purchases. It examines risk management, detection, response and operational evidence.
- People, processes and prompt response determine the outcome. Technology supplies a signal; roles and procedures turn it into a contained incident.
- Not every company has the same obligations. Essential or important entity status depends on sector, size and statutory exceptions.
- An ISO 27001 certificate does not settle the question. The standard provides a foundation, but the legal scope of Poland’s National Cybersecurity System Act requires a separate check.
- Value comes from the remediation plan. A gap reduces risk only when it has an owner, a deadline and evidence of closure.
What is an NIS2 compliance audit?
For management, an NIS2 audit clarifies accountability: it checks legal scope, risk management and evidence that organisational, operational and technical measures work. The outcome depends on whether tools are supported by prepared people, structured processes and prompt-response capability, which turn detected signals into contained incidents. The market commonly calls this an NIS2 compliance audit or simply NIS2 compliance.
| Criterion | An IT security audit | NIS2 / Polish National Cybersecurity System compliance audit |
|---|---|---|
| Main question | Do controls effectively reduce technical risk? | Does the organisation meet its obligations and demonstrate that they work? |
| Typical scope | architecture, configuration, vulnerabilities, access and technical resilience | governance, risk, people, processes, incidents, continuity and suppliers |
| Outcome | technical findings and risks | a requirements matrix, gaps, risk, priorities and an action plan |
A comprehensive technical assessment is provided by the security audit, while NIS2 compliance requires a perspective beyond infrastructure.
Who is subject to NIS2 requirements?
First establish whether the organisation is covered at all: NIS2 does not automatically apply to every company. Poland’s National Cybersecurity System Act distinguishes essential and important entities, with status determined by activity, sector, size and statutory exceptions. ’50 employees’ is not a universal test. Start by assessing status and listing the covered services.
Companies outside direct scope can face contractual requirements: supply-chain security obligations mean suppliers to essential entities receive requirements through contracts. Management does not relinquish accountability by delegating tasks; it decides on the security management system and oversees implementation. An NIS2 audit therefore begins with scope and ownership before configuration.
What does a professional NIS2 audit cover?
Restricting an audit to one layer is a common way to miss gaps. Assessment is simultaneously organisational, operational and technical, so a vulnerability scan alone does not cover statutory requirements. The following table shows key assessment areas and supporting evidence.
| Area | What is assessed | Example evidence |
|---|---|---|
| Governance and accountability | decisions, budget, owners, oversight and management training | resolutions, role descriptions and review minutes |
| Risk management | methodology, review cycle, acceptance criteria and treatment plan | risk register, asset assessments and acceptance decisions |
| Monitoring and logging | system coverage, correlation, triage and escalation | log sources, detection rules, alerts, tickets and duty rosters |
| Incident handling | roles, classification, communication, containment and recovery | IR policy, playbooks, escalation matrix and exercise records |
| Continuity and recovery | service priorities, RTO/RPO, backups and recovery tests | BIA, continuity plans and recovery test results |
RTO (Recovery Time Objective) and RPO (Recovery Point Objective, the tolerable data-loss window) are defined using business needs and impact analysis. Recovery tests verify whether those objectives are achievable in the tested scenario.
Similarly, for NIS2 security monitoring, the Act requires continuous oversight, while the audit checks coverage, detection and timely response. This is explored further in NIS2 and security monitoring, because NIS2 incident management begins where a raw alert ends. Continuous oversight is commonly provided by a SOC team operating 24/7, although the Act does not prescribe that model.
What does an audit involve, step by step?
A predictable audit process gives decision-makers an assessable cost and clear outcome. This is a methodological model, not a statutory form; it structures the work and separates facts from recommendations.
Six audit steps:
- Organisation and scope analysis — services covered by Poland’s National Cybersecurity System Act, critical processes, systems and suppliers.
- Requirements identification — obligations under Poland’s National Cybersecurity System Act and NIS2, sector-specific implementing rules and contractual requirements.
- Gap analysis — comparison of actual conditions with criteria using documents, interviews and sampled records.
- Risk assessment — gap likelihood and impact, and compensating controls.
- Findings report — criterion, evidence, actual condition, gap, risk and owner.
- Remediation action plan — priority, owner, deadline, closure evidence and reverification.
The report records the diagnosis; its value emerges when each significant gap enters an action plan with an owner and evidence of closure. At VigilHorizon, we ask who will close each gap, by when, and how we will know the risk has been addressed. We treat NIS2 preparation as a continuing process, not a one-off procurement project. These details determine whether an audit changes anything.

Common nonconformities found during audits
Audits show where money has been spent but risk remains. Similar categories recur, arising directly from statutory requirements, although percentages cannot responsibly be given without a representative sample.
Recurring gap categories:
- Incomplete scope and asset inventory — the management system omits processes affecting the service, and dependencies lack owners.
- A static risk assessment — a one-off assessment that does not lead to a treatment plan.
- Unrehearsed response — incident roles are unclear and escalation paths have not been tested.
- Monitoring without response — detection works, but alerts have no assigned person, triage path or response deadline.
- Backups without recovery evidence — copies exist, but nobody has documented restoration against RTO and RPO.
- Documentation disconnected from practice — policies describe a target state while logs show something else.
A composite illustrative scenario demonstrates this, rather than data from one company: an organisation in a covered sector began preparation by buying tools. Its NIS2 gap analysis revealed that key systems were not linked to the service catalogue, alerts lacked consistent escalation and recovery tests were undocumented. Remediation therefore began with scope, owners, risk and playbooks, with monitoring aligned afterwards.
Many gaps emerge only during structured incident response, step by step. A common cause is believing detection alone is enough: deploying SIEM alone does not improve security, because SIEM (Security Information and Event Management) collects and correlates event data, while a person makes the decision.
NIS2 audits and ISO 27001
Organisations with an information security management system naturally ask whether certification is sufficient. ISO/IEC 27001:2022 provides a mature framework and common audit language, accelerating preparation, but is not automatic confirmation of NIS2 compliance.
| Criterion | NIS2 / Poland’s National Cybersecurity System Act | ISO/IEC 27001:2022 |
|---|---|---|
| Nature | a legal obligation for entities within the Act’s scope | a voluntary standard; certification is the organisation’s decision |
| Incidents | regulatory notification deadlines for incidents meeting the criteria | requires a process but does not establish NIS2 deadlines |
| Monitoring | expressly requires continuous monitoring within scope | monitoring and effectiveness assessment within the defined scope |
| Outcome | demonstrating fulfilment of specific legal obligations | confirming the system’s conformity with the standard’s scope |
A well-implemented system covers much of the foundation. NIS2 assessment adds checks of statutory scope, management accountability and sector requirements, often using the same evidence. Certification shortens the path but does not remove the need for verification.
How should an organisation prepare before an audit?
Good preparation can shorten the audit and reduce the cost of closing gaps. Start with the fundamentals: who owns the service, which procedure describes it and how quickly someone responds to a signal.
The following list shows practical NIS2 preparation:
- Status self-assessment — determine whether you are an essential or important entity and which services are covered.
- Service and asset catalogue — a register of processes, systems, data and dependencies with owners.
- Roles and decisions — management accountability and formal decisions on risk and funding.
- Operational evidence — logs, tickets, recovery test results and exercise records.
- Response procedures — documented and rehearsed playbooks and escalation paths.
We begin preparation with processes and responsibilities, rather than a shopping list, because that is where audits often find gaps. First we establish scope, owners and risk, then organise evidence, and finally add technology to close a specific gap. Tools address a real problem rather than expanding unused functionality.

Is your organisation ready for NIS2?
This checklist helps you assess NIS2 compliance before an auditor does:
- Asset register — is there a catalogue of services, systems and dependencies with owners?
- Risk analysis — is assessment recurring and does it lead to a treatment plan?
- Response procedures — are playbooks and escalation paths documented and rehearsed?
- Monitoring — does someone analyse alerts continuously, not only during working hours?
- Management awareness — does leadership understand its obligations and decide on security resources?
Evidence-backed 'yes’ answers indicate progress towards readiness. Every 'I don’t know’ identifies where gap analysis should begin before deadline pressure arrives.
’Audit problems rarely come from missing tools; they come from missing records. A company can show a policy and a licence, but less often a log from a day when someone actually responded to an alert. We therefore ask about a specific event: who noticed it, what decision they made and where that decision was recorded.’
— VigilHorizon Expert
What really determines NIS2 compliance
NIS2 compliance neither begins with buying tools nor ends with documentation. It depends on understanding actual maturity, identifying gaps and planning action. Maturity appears in management decisions, work records, rehearsed procedures and response times — in people, process and prompt response, supported by the signals technology provides.
A professional audit structures this journey around risk. To assess your organisation’s position, we suggest starting with NIS2 compliance audit or a gap analysis with VigilHorizon experts. Where an audit identifies missing continuous alert oversight, a natural next step may be a SOC 24/7 team. The goal remains to turn findings into measurable tasks that reduce risk.
Frequently asked questions (FAQ)
Is an NIS2 audit mandatory?
Essential entities are subject to statutory audits at least every three years, and an authority may order one for an important entity after a significant incident. Voluntary gap analysis remains useful before deadlines.
Who can perform a statutory audit under Poland’s National Cybersecurity System Act?
The Act provides for an accredited conformity assessment body, at least two qualified auditors or the relevant CSIRT.
Can an internal team perform the audit?
An internal gap analysis helps prepare the organisation and organise evidence. A statutory audit must meet requirements for providers, qualifications and independence.
How long does an NIS2 audit take?
The law does not specify a single duration. It depends on the number of services, systems and suppliers and documentation maturity. Fixed ranges without project details would be misleading.
What is NIS2 gap analysis?
It compares actual conditions and evidence with applicable requirements, producing a gap matrix and risk-prioritised treatment plan. Gap analysis alone is not a statutory audit.
How does an NIS2 audit differ from a cybersecurity audit?
The practical distinction becomes clear when asking whether the outcome can serve as evidence that a statutory obligation has been fulfilled.
Is ISO 27001 sufficient for NIS2?
ENISA publishes mappings between NIS2 requirements and ISO/IEC 27001, while noting that mapping does not establish equivalence
Does NIS2 require 24/7 monitoring?
The provision calls for continuous system monitoring, not a specific staffing model. An audit checks the outcome — whether alerts reach the right person in time — rather than just the tool inventory.
Is documentation enough for a positive assessment?
Policies alone are insufficient: operational records must also demonstrate execution. Auditors sample logs, tickets, tests and decisions to compare declarations with practice.
Can a small company fall under Poland’s National Cybersecurity System Act?
Yes. In certain categories, status does not depend solely on size. This should not be generalised: the applicable provisions and sector annexes determine coverage.
Learn more
- NIS2 and security monitoring: which requirements must actually be met?
- Penetration testing: how does it differ from vulnerability scanning?
- Incident Response: responding to a cyberattack, step by step
- MTTD and MTTR: why detection time determines incident scale
- SIEM in business: why deployment alone does not improve security
- What is SOC 24/7, and why is monitoring not enough?
Related articles
Not sure which plan is right for your business?
Complete a short questionnaire
Complete the form and we will help you select monitoring, incident handling or availability support for your organisation. We will agree the scope and service conditions before work begins.


