NIS2 in Poland: an IT checklist for the 3 October 2026 deadline
3 October 2026 is the deadline for applying for entry in the national list for entities that met the criteria on 3 April 2026. An entity that meets them later generally has six months from that point. The second important date is 3 April 2027, when the adjustment period for the statutory duties, including an information security management system, ends.
This is a checklist for an IT team that has been handed the task "sort out NIS2" and does not know where to start. A housekeeping note first: I am not a lawyer and this is not legal advice. It is a practical map of what has to happen on the IT side for the company to make the deadline. Confirm the legal interpretation for your specific situation with counsel.
Step 1: establish whether you are covered at all
The new law works on the principle of self-identification. Nobody will send you a letter informing you that you are an essential or important entity. You have to determine it yourselves, based on your sector and company size.
Things to check:
- whether you operate in one of the sectors listed in the annexes (energy, transport, health, digital infrastructure, ICT services, selected manufacturing categories, waste management and others),
- whether you meet the criteria for a medium-sized enterprise or a larger entity, taking account of staff, financial data and partner or linked enterprises,
- whether you are a supplier to an essential entity, because then requirements can reach you through the supply chain even without being formally covered.
Write the result of this analysis down. If you conclude you are not covered, a document with the reasoning still has value: it shows the decision was conscious rather than a product of ignorance.
Want a quick initial read before the full analysis? Check in three questions whether you are likely covered - it does not replace legal analysis, but it shows where to look.
Step 2: registration before 3 October
If you are covered, you register in the list of essential and important entities. The registration itself is a formality, but it requires data prepared in advance: scope of activity, contact details of responsible persons, information about the services you provide.
A practical tip: appoint your cybersecurity contact person now. The role will be needed for incident reporting anyway, and registering a random name "because someone had to be there" tends to backfire later.
Step 3: inventory, the foundation that trips up most companies
This is where the real work starts. You cannot manage the security of systems you do not know about. You need answers to:
- what servers, services and applications you run (production, test, the forgotten "temporary" machines from three years ago),
- what operating systems and versions run on them,
- which of them are critical to delivering the services covered by the law,
- who owns each system, meaning who decides about changes to it.
From experience, in companies that have never carried out a formal inventory, this step often reveals forgotten machines and services. I do not assume a percentage because the scale depends on the organisation. That is not a cause for embarrassment. It is precisely why the exercise exists.
Step 4: a vulnerability management process
The law requires vulnerability handling as a continuous process. The minimum sensible shape:
- regular, automated scanning of every inventoried system (not manual, not "once a quarter before the board meeting"),
- prioritisation of findings: what gets fixed immediately, what within an agreed deadline, what is consciously accepted,
- defined remediation deadlines (SLAs) depending on severity,
- an exception path: who may accept a risk, for how long, with what justification,
- a record of all of the above in a place from which evidence can later be generated.
The last point is the one most often skipped, and it is the one that decides the audit. A process that cannot be documented does not exist, as far as an auditor is concerned.
Step 5: incident handling
Essential and important entities report significant incidents: an early warning within 24 hours of obtaining information about an event that meets the incident criteria, a notification within 72 hours and generally a final report within one month of the notification. Some important public entities use a simplified route without the early warning and final report. Before that ever happens, you need:
- a definition of what counts as an incident in your organisation and who decides its significance,
- an incident register, including incidents that were not reportable (auditors ask about the process, not just the submissions),
- a rehearsed path: who writes the report, who approves it, where the credentials for the reporting system live.
Step 6: evidence, or how to prove all of the above
Every step above produces artefacts: the coverage analysis, registration confirmation, the asset register, scan results with history, risk acceptance decisions, the incident register. An auditor or supervisory authority will want to see them for a specific period.
You can keep them in network folders and spreadsheets. You can also use a tool that maintains scan history, deadlines, decisions and evidence export automatically. I built Secvalis for exactly that second scenario, and if you want to see what such a process looks like in practice, enter the public demo. No registration, fictional data.
Deadline summary
- by 3 October 2026: an application from entities meeting the criteria when the amendment entered into force,
- by 3 April 2027: adjustment to the duties, including an operating ISMS, vulnerability process and incident-reporting procedures.
The calendar is unforgiving in one specific way: inventory and a vulnerability process take weeks to establish in a mid-sized company, not days. The later you start, the more will be done as shortcuts, and shortcuts in documentation are what an audit exposes best.