The compliance officer of an energy company receives a letter from the authority competent for cybersecurity. It contains no question about the level of security and no request for an architecture presentation. It is a demand to produce documents: the policy, the records proving it is being followed, and the results of the most recent audit. The IT team reacts reflexively — it launches a vulnerability scanner and starts preparing slides about the tools it has deployed. That is a response to a different question than the one asked.
An audit “under NIS2” is not an audit of systems. It is an audit of evidence. The supervisory authority does not ask whether you are secure — it asks what you prove it with, and it has an explicit power to do so. Preparation therefore starts with a register of artefacts, not with a tool. This text shows exactly what may be demanded, which document closes each of the ten areas named in the directive, and which pieces of evidence most often do not exist even though the security measure itself works.
How does an audit under NIS2 differ from an ISO 27001 audit and from a penetration test?
It differs in the question it answers. A penetration test answers whether it is possible to get in — within a specific scope and on a specific day. An ISO 27001 compliance audit answers whether the information security management system operates in line with the standard. An audit under NIS2 answers a third question: whether, for each area named in the directive, there exists an artefact with which the organisation can demonstrate that the measure has been implemented and is being maintained.
The consequence is practical. A penetration test report with no findings is not evidence of compliance with the directive, because it speaks about a technical segment rather than about the areas in Article 21(2). Nor does an ISO 27001 certificate settle the matter — ENISA itself states this reservation in its technical guidance of June 2025, and we set out the limits of mapping separately in the article on whether ISO 27001 is enough for NIS2. The distinction between an audit and a test is developed in turn in the article on how a security audit differs from a penetration test.
How does a readiness audit differ from a security audit?
A security audit answers a technical question: what can be attacked. A KSC/NIS2 readiness audit answers a governance one: which statutory duties the organisation already meets, which it does not, what closing each gap costs, and who is accountable for it by name. The first ends in a list of vulnerabilities; the second ends in a budget decision and a schedule the board signs.
That is why a readiness audit starts nowhere near a scanner. It starts with three determinations from the governance, risk and compliance side: whether the organisation is an essential or an important entity, who approves the risk treatment, and how an incident report reaches the authority inside the statutory window. Settling those before any investment is what a NIS2 audit in its Readiness Check form is scoped to do.
What exactly does a supervisory authority ask for when it comes for compliance?
It asks for documents and for evidence that they are being followed — and it has that written into its catalogue of powers. Article 32(2) of Directive (EU) 2022/2555 lists what competent authorities must be empowered to subject essential entities to: on-site inspections and off-site supervision, including random checks (point a), regular targeted security audits carried out by an independent body or a competent authority (point b), ad hoc audits following a significant incident (point c) and security scans (point d).
Three further points concern paper alone. Point (e) covers requests for information necessary to assess the cybersecurity risk-management measures adopted, “including documented cybersecurity policies”. Point (f) covers access to data, documents and information necessary to carry out supervisory tasks. Point (g) speaks explicitly of requests to provide evidence of implementation of cybersecurity policies, such as the results of a security audit carried out by a qualified auditor and the supporting evidence.
For important entities, the analogous catalogue appears in Article 33(2), with one significant difference: it applies ex post, once the authority receives evidence, an indication or information about alleged non-compliance with the directive. An important entity is therefore not beyond the reach of inspection — it is outside its planned rhythm.
The key distinction: the directive knows no category called “we proved it verbally”. Each of the powers in points (e), (f) and (g) ends in a document that either exists on the day of the request or does not exist at all. There is no third possibility.
Does NIS2 require a security certificate?
It does not, and it never did. This is the most common error in material written about the directive, worth defusing straight away, because it leads to spending budget on the wrong thing.
The provision around which this misunderstanding has grown is Article 24(1). It allows Member States to require essential and important entities to use ICT products, services and processes certified under European cybersecurity certification schemes adopted pursuant to Article 49 of Regulation (EU) 2019/881. The power therefore concerns certification of the solutions the organisation uses, not the organisation holding a certificate of its own. Paragraph 2 adds that the Commission may, in delegated acts, indicate the categories of entities from which such certification is to be required — a conditional power, triggered once insufficient levels of security are established.
From the point of view of preparing for an inspection, this means one thing: a certificate can be a useful element of the evidence file, but it does not replace the register of evidence. At most it replaces a few of its entries.
When is an audit a statutory obligation, and when is it your own decision?
Under Polish law the audit obligation is specific and applies to essential entities. Article 15(1) of the National Cybersecurity System Act — as amended by the Act of 23 January 2026 (Journal of Laws 2026 item 252, in force since 3 April 2026) — requires a security audit of the information system to be carried out at the entity’s own cost at least once every three years, counted from the date on which the report from the previous audit was drawn up and signed. The first audit must take place within 24 months from the day the entity meets the criteria for being an essential entity (Article 16(2)). The essential entity submits an electronic copy of the audit report to the competent authority within 3 working days of receiving it (Article 15(1a)).
Alongside this cycle there is an extraordinary route. The competent authority may at any time order an essential entity to carry out an external audit, and an important entity — in the event of a significant incident or another breach of the Act (Article 15(1b)). In the decision the authority sets the deadline for submitting a copy of the report and indicates which types of entities may carry out the audit, it may also define the scope of the audit (paragraph 1b), and the decision is immediately enforceable (paragraph 1c). The three-year cycle is therefore a floor that a single event can invalidate overnight.
If you come across a two-year cycle in older material, that is not an author’s mistake but the previous legal state — the two-year audit cycle applied to operators of essential services before the amendment (Article 15(1) in its previous wording, consolidated text Journal of Laws 2026 item 20). With every statement about deadlines, therefore, check the publication date of the material. The frequency of technical testing follows a separate logic, which we set out in the article on how often you should run penetration tests.
Why does preparation start with a register of evidence rather than with a scanner?
Because the assessment of effectiveness is itself one of the measures the directive requires, and its evidence is a document. Article 21(2)(f) lists among the mandatory elements “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. An organisation that has never written down how it checks its own measures does not satisfy that point — no matter how good its tools are.
The second reason is even more practical. Article 21(4) requires an entity that finds it does not comply with the measures in paragraph 2 to take, without undue delay, all necessary, appropriate and proportionate corrective measures. The provision therefore assumes that gaps will be found — and treats finding them as the start of an obligation rather than as a breach. A report with findings, a named owner and a remediation deadline is consequently stronger evidence than a report with no findings, because it demonstrates a working process.
A practical card: before you order a scan, build a one-page table with ten rows — one for each point in Article 21(2) — and in each one write the file name and the date it was last updated. The rows with nothing to write in them are your entire task list for the coming quarter.
Which pieces of evidence most often do not exist even though the measure itself works?
What is most often missing are records of repeatable activities — the ones the team performs as a matter of routine and, precisely for that reason, does not document. Five cases recur with particular stubbornness.
The first is training. Basic cyber hygiene practices and training are listed in Article 21(2)(g), but the evidence is not the platform you bought; it is the attendance list with a date and the topics covered. The second is suppliers: supply chain security (point d) is demonstrated by security requirements recorded in the contract and by an assessment of a specific supplier, not by the mere fact that a contract exists — we described a practical approach to that assessment in the article on the supply chain audit under NIS2.
The third case is backups. Business continuity (point c) is demonstrated by a report from a restore test, with a date, a scope and a measured duration — not by a report that the backup succeeded. The fourth is access reviews: the access control policy and asset management (point i) require a periodic review whose evidence is a signed record of who performed it and when. The fifth is incident handling (point b) — the event is often handled correctly, but nowhere is there a record of the decision to qualify it, nor of the reporting path. That last gap hurts the most, because it is tied to deadlines counted in hours; we described the separation of tool from process in the article on whether SIEM is enough for NIS2.
Who may carry out the audit, and what does “independent” actually mean?
The audit may be carried out by a firm from outside the organisation as well as by an internal auditor — the condition is not where the auditor comes from, but that they do not assess their own work. The directive uses two distinct terms here and it is worth separating them. The targeted security audits in Article 32(2)(b) are carried out by “an independent body or a competent authority” — that is an audit initiated by the supervisor, and its costs are borne by the entity being audited, except in duly justified cases where the authority decides otherwise. Point (g), by contrast, speaks of the results of an audit carried out by a “qualified auditor”, meaning an examination the organisation commissions itself.
In practice, independence means one thing: the auditor does not assess their own work. An internal audit is a fully valid source of evidence, provided it is carried out by someone who does not report to the manager responsible for the area under examination and who did not take part in implementing the measures being examined. An auditor from outside the organisation meets that condition by definition, adds a comparison with other entities and — which matters in a dispute with the authority — issues a document signed by a third party. We discuss the scope and form of such an examination under security audits run by nFlo.
A convenient working grid of areas to check on the technical side is the CIS Critical Security Controls set — eighteen controls, some of which correspond directly to points in Article 21(2): Control 15 “Service Provider Management” to the supplier area, and Control 17 “Incident Response Management” to incident handling. That is a working scaffold, not a legal basis.
Who is liable when the evidence is missing?
Liability is assigned to a named person, not spread across a department. Article 8c(1) of the National Cybersecurity System Act assigns the head of the entity responsibility for performing obligations including those arising from Articles 9 to 12b. This means that a question about a missing record ultimately lands on the desk of the person in charge, even if the activity itself was performed by a technical team.
The Act also provides for a penalty addressed to the head of the entity personally. Article 73a(1)(9) covers with a financial penalty a head who fails to perform at least one of the reporting obligations under Article 11, and Article 73a(4) sets its upper limit at 300% of that person’s remuneration. For the head of a public entity the cap is, as a rule, 100% of remuneration (Article 73a(5)). The construction is clear: an absence of evidence that an obligation was performed and a failure to perform the obligation look the same in proceedings, because the evidence file is all the party has to work with.
Which artefact is the evidence for each of the ten areas in Article 21(2)?
For each of the ten areas the evidence is a different document, and the directive does not name it — the organisation has to. The table below is the skeleton of such a register. The first column quotes the area from the directive, the second indicates the artefact that serves as evidence in proceedings, and the third the gap that appears most often in that row. The table is filled in with file names and dates, not with declarations.
| Area under Article 21(2) | Artefact serving as evidence | Most common gap |
|---|---|---|
| a) risk analysis and information system security policies | approved policy with a date and a risk register with the last review | register drawn up once and never updated |
| b) incident handling | procedure plus records of reports with the qualification decision and times | events handled, decisions undocumented |
| c) business continuity and crisis management | continuity plan and a report from a backup restore test | restore test never carried out |
| d) supply chain security | security requirements in the contract and a supplier assessment | contract without clauses, assessment purely verbal |
| e) security in acquisition and maintenance of systems | change procedure and a vulnerability handling register | vulnerabilities closed without a recorded deadline |
| f) assessment of the effectiveness of measures | audit or review report with findings and deadlines | assessment performed, nowhere described |
| g) cyber hygiene and training | training programme, attendance list, topics and date | platform purchased, attendance never measured |
| h) cryptography and encryption | policy on the use of cryptography and a configuration record | settings live in tools, no policy exists |
| i) human resources, access control, asset management | asset inventory and a signed access review | access review with no record of performance |
| j) multi-factor authentication and secured communications | implementation scope with a list of systems covered | partial rollout, exclusions undescribed |
When should the audit be internal and when external — what rhythm makes sense?
The rhythm is built around the statutory cycle, not instead of it. An external audit is worth planning so that the report is signed with time to spare before three years elapse from the previous one — the deadline runs from the date the report is signed, so a delay on the auditor’s side transfers directly to the statutory deadline. The second natural moment for an external examination is a significant change: an acquisition, a migration of a key system or entry into a new line of business.
Between those points, internal audit does the work, preferably on an annual cycle and on a rotating subset of areas — three to four points from Article 21(2) per year gives a full pass through the register in three years and spreads the workload evenly. Preparation for the first examination, meaning the gap analysis, deserves separate treatment — that is the readiness audit whose scope and output are described above, while the factors that drive the budget depend chiefly on the scope of systems, the number of standards covered and the deliverables expected.
How do you turn audit findings into a roadmap for the board?
The board does not need a 200-page technical report; it needs a plan it can approve. Close the audit with a roadmap that answers three questions: where we are (key gaps and the risk assessment, for example as a heat map), where we need to be (the target level of KSC/NIS2 compliance) and how we get there (a list of specific remediation projects).
Each project on the roadmap gets a priority derived from the risk analysis, an estimated budget and a schedule, for example split into quarters. A document built this way stops being an IT budget request and becomes a plan for mitigating regulatory and business risk — one the board is personally accountable for.
It is worth attaching a cyber insurance readiness assessment to the roadmap. Insurers run their own detailed review of security controls before issuing a policy, so the same gaps the audit reveals translate into the terms and availability of cover. That lets you show the CFO technical risk as financial risk — we cover this in more detail in the article on how KSC/NIS2 compliance affects the cost of cyber insurance.
How do you check in two weeks whether you have evidence or only a conviction?
Ten questions asked in writing and one test are enough. Writing them down is the essence of the exercise: a verbal answer always sounds better than the file looks.
- Which document is your cybersecurity policy and when was it approved?
- When was the risk register last updated and who approved it?
- Where is the record of the last decision qualifying an event as an incident?
- When was data last restored from a backup and how long did it take?
- Which critical supplier was assessed most recently and in which document is it recorded?
- Who performed the last access review for a key system, and when?
- How many people completed training in the past year and how do you know that figure?
- Where is the method for assessing the effectiveness of measures required by point (f) described?
- Which version of the asset inventory is in force and who owns it?
- When was the report from the last audit signed and where is its copy kept?
There is one test: ask for each of these documents as a file, with its modification date, and measure how many arrive within 48 hours. The result of that exercise is the closest approximation of what the authority will see — with the difference that today you can still fill in the missing rows instead of explaining their absence in an inspection record.
Frequently asked questions
What may a supervisory authority demand during a NIS2 compliance inspection?
The catalogue of powers over essential entities is set out in Article 32(2) of Directive (EU) 2022/2555. The authority may conduct on-site inspections and off-site supervision (point a), order regular targeted security audits carried out by an independent body or a competent authority (point b), request a documented cybersecurity policy (point e), request access to data and documents (point f) and — explicitly — request evidence of implementation of cybersecurity policies, such as the results of a security audit carried out by a qualified auditor (point g). For important entities, the analogous catalogue in Article 33(2) applies ex post.
How often must an essential entity carry out a security audit?
At least once every three years, at its own cost, counted from the date on which the report from the previous audit was drawn up and signed — Article 15(1) of the National Cybersecurity System Act as amended by the Act of 23 January 2026 (Journal of Laws 2026 item 252, in force since 3 April 2026). The first audit must take place within 24 months from the day the entity meets the criteria for being an essential entity (Article 16(2)). The essential entity submits a copy of the audit report to the authority within 3 working days of receiving it (Article 15(1a)). The authority may also order an external audit at any time, and the deadline for submitting a copy of the report is then set by the decision (Article 15(1b)).
What should you do if the audit reveals gaps?
Document them and close them. Article 21(4) of Directive (EU) 2022/2555 requires an entity that finds it does not comply with the measures in paragraph 2 to take, without undue delay, all necessary, appropriate and proportionate corrective measures. A recorded gap with a named owner and a deadline is stronger evidence than a report with no findings — it demonstrates a working process for assessing effectiveness, which is exactly what Article 21(2)(f) requires.
