What should a NIS2 gap analysis contain?

Why the question comes up at all

A gap analysis is usually the first piece of work a board buys in once it has established that the organisation falls under the act. A few weeks later an extensive report arrives at a board meeting, with a numerical score and a declaration of compliance somewhere in the tens of per cent. The board cannot approve either the scope of work or the budget on that basis, and the person running the topic cannot allocate tasks, because they do not know who would carry them out.

The reason is simple. The act does not know the concept of a gap analysis and describes neither its method nor its result. That left a definitional gap which every provider fills in its own way — some measure the organisation against the catalogue of statutory obligations, others against an industry standard, others still against their own checklist. The three results look alike and mean different things.

The act does say plainly what the organisation may be asked about. The competent authority for cybersecurity may request evidence that the requirements referred to in Article 8(1) have been implemented, and its supervision of essential entities is preventive in character, not only after the fact. That settles what is genuinely needed in a gap analysis. Not a score, but knowledge of what the organisation has today and what it lacks in order to answer such a request.

Then there is the calendar. Entities that met the qualification criteria on 3 April 2026 implement the obligations under Chapter 3 of the act within twelve months, and the first audit of an essential entity falls due within twenty-four months of that date. An entity that meets the criteria later has the same twelve and twenty-four months, counted from the day it meets them. A gap analysis is supposed to translate that calendar into tasks. If it does not, it remains a description of the state of the organisation.

What to establish before deciding

Against which baseline was the organisation measured

This is the first question worth asking once the result arrives, and the only one that invalidates everything else. A gap analysis measured against an industry standard shows the maturity of the information security management system, but it does not answer the question whether the organisation performs its statutory obligations. The two sets overlap but they are not the same.

The act itself marks out the proper baseline. The provision on the liability of the head of the entity (Article 8c(1)) lists the obligations that person answers for, and that list is the closest statutory equivalent of the scope of the analysis. Beyond the information security management system it covers registration obligations, incident handling and reporting, and security documentation. It also covers three things that are remembered least often. Designating people for contact with the entities of the national cybersecurity system, verifying the clean criminal record of staff admitted to the relevant tasks, and the audit. An analysis that covered only the technical measures in Article 8 describes a single provision, not the scope of the entity’s obligations.

The second dimension is even easier to miss. The baseline is not the same for all entities covered by the act, and it is settled by the criteria for qualifying an entity.

Type of entity	What the risk-management measures are measured against
An essential or important entity to which Article 8(1) applies	The catalogue in Article 8(1), including the technical and organisational measures listed in point 2(a)–(n)
An important entity that is a public entity, and the universities indicated in Article 8(3) in respect of their public tasks	Article 8(1) does not apply; the simplified system in Annex 4 to the act applies instead, together with a review at least once a year and documentation of the actions taken
Digital entities listed in Article 8b(1), including providers of cloud services, data centres and managed services	Additionally the measures in Commission Implementing Regulation (EU) 2024/2690, which applies directly
Electricity sub-sector entities identified as having a high or critical impact	The identification is made by the minister responsible for energy (Article 52a(2)), not by the entity itself. The measures in Commission Delegated Regulation (EU) 2024/1366 — the network code on cybersecurity aspects of cross-border electricity flows — apply in addition
The banking sector and financial market infrastructure	Article 8i disapplies the provisions on the information security management system and on reporting significant incidents. What remains includes qualification and entry in the register, risk assessment together with basic cyber hygiene practices, and the liability of the head of the entity under Articles 8c–8f

If the result does not open by settling which of these arrangements applies to the organisation, the pages that follow describe somebody else’s obligations.

What was in scope and what fell outside it

The act ties obligations to the information system used in processes that affect the provision of the service. That wording calls for a decision, and the decision should be visible in the document: which services were treated as covered, which systems were assigned to them and on what basis. In a group of companies there is a second determination to make, because qualification and obligations are established separately for each company — an analysis covering “the group” leaves the individual entities without a result of their own.

What was not covered matters just as much. Excluding some systems, branches or processes is often justified but it has to be named. A result in which the boundary of the review is invisible turns from a document into guesswork at the authority’s or the auditor’s first question.

How a single gap is described

A usable description of a gap has three layers and separates them clearly. The first is the required state together with a reference to the provision it follows from. The second is the state found together with the basis for that finding: which document was reviewed, which record or configuration was checked and who was interviewed. The third is the difference and its consequence for the organisation, that is, what will happen or what cannot be demonstrated as long as the gap stays open.

The second layer is the one most often missing. The sentence “the incident reporting procedure is incomplete”, without saying which version of the document was reviewed and what was not found in it, is an opinion rather than a finding. Six months on nobody will verify or defend it, and whoever inherits the task will start by repeating the work.

Every gap also needs an owner. Not a department, but a role that can take a decision and answer for its consequences. A gap booked to “IT” in an organisation where the business lines decide priorities will not be closed, because its owner has no mandate to change the process.

Where the order of actions comes from

Priorities are where a gap analysis differs most from a list of shortcomings. A sensible order follows from the risk to the provision of the service, the statutory deadline attached to a given obligation and the dependencies between actions. The order of articles in the act and the ease of doing the work are not criteria, even though in practice they shape plans most often.

Deadlines enter in two ways. Existing entities implement the obligations under Chapter 3 of the act by 3 April 2027, and the first audit of an essential entity falls due by 3 April 2028. A separate deadline runs for the application for entry in the register of essential and important entities, which for existing entities the Minister of Digital Affairs set by announcement at 3 October 2026. Administrative fines may be imposed for the first time after two years from the entry into force of the amending act, but what is deferred is the fines, not the obligations. Preventive supervision of essential entities has not been deferred at all.

Dependencies between actions settle the rest. Business continuity cannot sensibly be described before systems have been inventoried, and suppliers cannot be held to a level of security the organisation is unable to define for itself. A result that does not put this in order leaves the ordering to the board at its meeting.

What the organisation will use to show a gap is closed

The last column of a good gap analysis answers the question of how you know a gap is closed. The act divides security documentation into normative and operational, operational documentation being the records evidencing performance of the activities required by the normative documentation, including automatically generated system log entries. That division is worth carrying straight into the result of the analysis, because it settles what has to be produced.

The practical consequence is that the evidence a gap has been closed is rarely the document alone. A policy without records of its application shows intent rather than action and, under supervision, works against the organisation just as its absence would. So if the analysis identifies a gap in the area of backups, the target evidence is the procedure together with the records of restore tests and not the procedure on its own.

What a gap analysis is not

Three distinctions save the most misunderstandings.

A gap analysis is not the audit referred to in Article 15. An essential entity carries out that audit at its own expense at least once every three years, and it may be performed by an accredited body or by at least two auditors meeting the statutory requirements. The act adds a condition of independence. The audit may not be performed by a person who carries out tasks under Article 8 and Articles 9–13 in that entity. A copy of the report goes to the competent authority within three working days of receipt. A gap analysis need meet none of those conditions and does not discharge the audit obligation.

Nor does a gap analysis replace risk assessment. Systematic assessment of the risk of an incident and the management of that risk are a separate, continuous obligation under Article 8(1)(1). A gap analysis may show that the process does not exist — it does not create it.

Finally, the result does not settle matters that remain open outside the organisation, and the most important of them concerns the thresholds for treating an incident as significant. They are set by the Council of Ministers in a regulation (Article 11(4)), except that the regulation in force dates from 31 October 2018, implements the previous directive and sets thresholds for six sectors in the pre-amendment arrangement, by reference to the essential service. It remains in force until new implementing provisions enter into force, and for no longer than twelve months from the entry into force of the amending act. An organisation outside that scope has no threshold to refer to today, and a gap analysis can only note the fact. The risk-management measures for types of entity other than digital ones remain open in the same way — they are yet to be set by European Commission implementing acts (Article 8b(2)). An honest document lists those points instead of presenting the target state as settled.

Most common mistakes

• A score instead of a conclusion. A declaration of compliance somewhere in the tens of per cent does not say what to do first, and under supervision it means nothing.
• Measuring against a standard instead of against the act. The result is often valuable in substance, but it does not answer the question whether the statutory obligations have been performed.
• Leaving out obligations from outside Article 8. Registration obligations, designating at least two contact people, documentation and incident reporting drop out of the analysis most often, and it is precisely those that have the nearest deadlines.
• Treating a gap analysis as the Article 15 audit. An essential entity that considers the matter closed discovers the error only when the audit falls due.
• Gaps without an owner. The document then describes the state of the organisation but triggers no action.
• Postponing the work because fines have been deferred. The deadlines for performing the obligations run independently of the date from which fines may be imposed.

Conclusions and next steps

The value of a gap analysis is measured by how many decisions can be taken on its basis without additional work. A document in which every gap has a legal basis, an established finding of fact, an owner and target evidence turns into an implementation plan without being rewritten. A document with a score requires that work to be done all over again, usually in-house and without a budget.

The sequence after accepting the result is short. First the board settles what the analysis could not settle: the accepted level of risk, the split of work between the in-house team and the provider, and the resources. Then the gaps have to be grouped into tasks with deadlines tied to 3 April 2027, with those that condition the others set apart — the inventory of systems, the naming of process owners and the incident escalation path. Finally the review rhythm is set, because a gap analysis describes the state on the day of the review and the organisation keeps changing.

If, after reading the result, you cannot answer the question of what the organisation would show the authority in response to a request for evidence that the requirements have been implemented, the analysis needs completing before implementation starts.

Related materials

• Does every organization fall under NIS2? — qualification criteria, size thresholds and the split into essential and important entities; the determination the baseline of a gap analysis depends on.
• Where should the board begin preparing for NIS2? — the decisions that have to be taken before a gap analysis makes sense.
• What should NIS2 training for the board cover? — the scope of the head of the entity’s responsibility and how to document it.
• When and how to apply for entry in the register of essential and important entities — deadlines, the data required and the declaration of the head of the entity.

Sources

• Act of 5 July 2018 on the National Cybersecurity System, consolidated text (as at 7 July 2026) — ISAP, Chancellery of the Sejm: isap.sejm.gov.pl (in Polish; accessed 19 August 2026)
• Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252) — transitional provisions, Journal of Laws: dziennikustaw.gov.pl (in Polish; accessed 19 August 2026)
• Regulation of the Council of Ministers of 31 October 2018 on the thresholds for treating an incident as significant (Journal of Laws 2018, item 2180) — ISAP: isap.sejm.gov.pl (in Polish; accessed 19 August 2026)
• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex: eur-lex.europa.eu (accessed 19 August 2026)
• Commission Delegated Regulation (EU) 2024/1366 of 11 March 2024 establishing a network code on sector-specific rules for cybersecurity aspects of cross-border electricity flows — EUR-Lex: eur-lex.europa.eu (accessed 19 August 2026)
• Announcement of the Minister of Digital Affairs of 8 April 2026 on the timetable for submitting applications for entry in the register of essential and important entities (Official Journal of the Minister of Digital Affairs, item 7) — Ministry of Digital Affairs: gov.pl (in Polish; accessed 19 August 2026)