{"id":4074,"date":"2026-07-28T09:15:00","date_gmt":"2026-07-28T07:15:00","guid":{"rendered":"https:\/\/www.lablogic.pl\/?p=4074"},"modified":"2026-09-13T22:48:55","modified_gmt":"2026-09-13T20:48:55","slug":"what-should-a-nis2-gap-analysis-contain","status":"publish","type":"post","link":"https:\/\/www.lablogic.pl\/en\/what-should-a-nis2-gap-analysis-contain\/","title":{"rendered":"What should a NIS2 gap analysis contain?"},"content":{"rendered":"\n

Micha\u0142 Rutkowski<\/strong><\/a> \u2022 for boards and senior management \u2022 published July 28, 2026 \u2022 updated August 19, 2026 \u2022 9 min read<\/p>\n\n\n\n

\n
\n
\n\n\n\n<\/div>\n<\/div>\n\n\n\n
\n
\n

Short answer<\/h2>\n\n\n\n

A NIS2 gap analysis (also called a gap assessment) has to let the board take three decisions. What the organisation must meet, where it falls short and in what order it closes the difference. Every gap should therefore be tied to a specific obligation under the Polish Act on the National Cybersecurity System (KSC), described together with what was checked, and completed by naming the evidence with which the organisation will demonstrate that the gap is closed. The act does not require a gap analysis and does not prescribe its form, so one thing decides the value of the document. It is whether an implementation plan can be built from it and its findings shown during supervision.<\/p>\n<\/div>\n\n\n\n

Why the question comes up at all<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u2014 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Then there is the calendar. Entities that met the qualification criteria on April 3, 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.<\/p>\n\n\n\n

What to establish before deciding<\/h2>\n\n\n\n

Against which baseline was the organisation measured<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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\u2019s obligations.<\/p>\n\n\n\n

The second dimension is even easier to miss.<\/p>\n\n\n\n

\n\n

Remember<\/p>\n\n\n\n

The baseline is not the same for all entities covered by the act, and it is settled by the criteria for qualifying an entity<\/a>.<\/p>\n\n<\/div>\n\n\n\n

Type of entity<\/th>What the risk-management measures are measured against<\/th><\/tr><\/thead>
An essential or important entity to which Article 8(1) applies<\/td>The catalogue in Article 8(1), including the technical and organisational measures listed in point 2(a)\u2013(n)<\/td><\/tr>
An important entity that is a public entity, and the universities indicated in Article 8(3) in respect of their public tasks<\/td>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<\/td><\/tr>
Digital entities listed in Article 8b(1), including providers of cloud services, data centres and managed services<\/td>Additionally the measures in Commission Implementing Regulation (EU) 2024\/2690, which applies directly<\/td><\/tr>
Electricity sub-sector entities identified as having a high or critical impact<\/td>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 \u2014 the network code on cybersecurity aspects of cross-border electricity flows \u2014 apply in addition<\/td><\/tr>
The banking sector and financial market infrastructure<\/td>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\u20138f<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

If the result does not open by settling which of these arrangements applies to the organisation, the pages that follow describe somebody else\u2019s obligations.<\/p>\n\n\n\n

What was in scope and what fell outside it<\/h3>\n\n\n\n

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. It should state 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 \u2014 an analysis covering \u201cthe group\u201d leaves the individual entities without a result of their own.<\/p>\n\n\n\n

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\u2019s or the auditor\u2019s first question.<\/p>\n\n\n\n

How a single gap is described<\/h3>\n\n\n\n

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. That basis covers 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.<\/p>\n\n\n\n

The second layer is the one most often missing. The sentence \u201cthe incident reporting procedure is incomplete\u201d, 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.<\/p>\n\n\n\n

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 \u201cIT\u201d in an organisation where the business lines decide priorities will not be closed, because its owner has no mandate to change the process.<\/p>\n\n\n\n

Where the order of actions comes from<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

Deadlines enter in two ways. Existing entities implement the obligations under Chapter 3 of the act by April 3, 2027, and the first audit of an essential entity falls due by April 3, 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 October 3, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

What the organisation will use to show a gap is closed<\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

What a gap analysis is not<\/h3>\n\n\n\n

Three distinctions save the most misunderstandings.<\/p>\n\n\n\n

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\u201313 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.<\/p>\n\n\n\n

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 \u2014 it does not create it.<\/p>\n\n\n\n

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 October 31, 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 \u2014 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.<\/p>\n\n\n\n

\n

Acceptance checklist for a gap analysis<\/h2>\n\n\n\n

To check before accepting the document and before the budget conversation.<\/p>\n\n\n\n