NIS2 and the Polish KSC Act: key deadlines, obligations and a checklist

What NIS2 and the amended KSC Act are

NIS2 is EU Directive 2022/2555 on measures for a high common level of cybersecurity across the Union. Poland transposed it by amending the National Cybersecurity System Act (ustawa o krajowym systemie cyberbezpieczeństwa) on 23 January 2026. The amendment was published in the Journal of Laws on 2 March 2026 (item 252) and came into force on 3 April 2026. Government guidance often calls the new regime KSC 2.0.

The biggest change is scope. The old Act covered mainly operators of essential services designated by decision. The new one covers essential and important entities in more than a dozen sectors: energy, transport and healthcare, water supply, waste management and manufacturing, ICT services and public entities. Each organisation checks for itself whether it is covered, a process called self-identification.

Both groups have the same substantive obligations. The difference lies in supervision: essential entities face broader supervision and mandatory audits, while important entities are inspected mainly when there are signs of non-compliance. Responsibility for cybersecurity sits with management and cannot be handed to the IT department or an outside provider. Tasks can be delegated, accountability cannot.

Deadlines: what has passed and what is next

Deadlines run from the date the Act came into force or from the day an organisation started to meet the criteria. For organisations that already met them on 3 April 2026, the calendar looks like this:

Organisations that meet the criteria later get the same periods counted from that day: 6 months to register, 12 to implement, 24 for the first audit.

There are also ongoing duties: changes to register data must be reported within 14 days, and the head of the entity must complete cybersecurity training once every calendar year.

Who the Act applies to

Self-identification has two main steps. First, check whether the organisation operates in a sector or subsector listed in Annex 1 or Annex 2 to the Act. The PKD activity code is a hint, but what counts is what the organisation actually does. Then determine its size using the EU SME definition:

• medium-sized enterprise: fewer than 250 employees and turnover up to EUR 50 million or a balance sheet total up to EUR 43 million,
• essential entity: as a rule, a sector from Annex 1 and larger than a medium-sized enterprise,
• important entity: a sector from Annex 1 or 2, at least medium-sized, and not an essential entity.

Partner and linked enterprises count towards size, so a company in a group may be “larger” than its own figures suggest. Some organisations are covered regardless of size, for example DNS service providers, qualified trust service providers, critical entities and some public entities.

Public bodies

The Act has a separate sector called “public entities”, present in both annexes. Not every public body is a public entity within the meaning of the Act, so this has to be checked for each organisation. Public entities do not apply for registration: the minister for digital affairs or the competent authority enters them in the register ex officio, based on public records, and then asks them to complete their data. In local government it is worth reviewing not only the municipal office but also subordinate units and municipal companies, which may be covered on other grounds, for example as drinking water suppliers.

Companies outside the Act

The Act also covers supply chain security. Essential and important entities must assess and monitor the risks posed by their ICT product and service suppliers. In practice this means questionnaires, contract clauses and supplier audits, so a small IT company or software house will feel the Act through its clients even if it is not covered itself.

Key obligations

The core of the Act is Article 8: essential and important entities implement an information security management system based on systematic risk assessment. In practice the ISMS covers:

• risk and asset management: you know what systems and data you have, what threatens them and how you reduce the risk,
• policies and responsibilities: a security policy, defined roles and staff permissions,
• business continuity: backups, disaster recovery plans and crisis management,
• technical measures: access control, multi-factor authentication (MFA), cryptography and encryption, patch management, system integrity and protection, physical security,
• security in acquiring and developing systems, including testing,
• the supply chain: risk assessment and monitoring of ICT suppliers, including high-risk suppliers,
• training and cyber hygiene for staff, and mandatory annual training for the head of the entity (Article 8e).

Beyond the ISMS, the Act requires incident handling and reporting, at least two designated cybersecurity contact persons as a rule (Article 9), and documentation of security activities (Article 10). Essential entities must also carry out a security audit at least every 3 years (Article 15) and send a copy of the report to the competent cybersecurity authority.

Supervisors will check whether the rules work in practice, not just whether documents exist. A password policy that nobody enforces, or a backup that nobody has ever restored, will not be enough.

Incident reporting: 24 hours, 72 hours, one month

Significant incidents are reported through System S46. Reports currently go to the relevant national CSIRT (CSIRT NASK, CSIRT GOV or CSIRT MON) and will eventually go to sectoral CSIRTs. Reporting has three stages:

1. Early warning, within 24 hours of detection: who is reporting, when the incident occurred and was detected, whether it may have been caused by unlawful action and whether it may affect other EU countries. You can ask for technical support at this stage.
2. Incident notification, within 72 hours of detection: impact on services, causes and course of events, expected consequences, actions taken and an update to the early warning.
3. Final report, within one month of detection: a detailed description of the incident and damage, its source or probable cause, mitigation measures applied and planned, and any cross-border effects.

If personal data is involved, GDPR applies separately: a personal data breach must be reported to the Polish data protection authority (UODO) within 72 hours of becoming aware of it.

Twenty-four hours is not long, especially when an incident starts on a Friday evening. The procedure has to be ready in advance: who decides whether an incident is significant, who decides to report it, who has access to S46 and how to reach these people out of hours. It is worth rehearsing it in a tabletop exercise before you need it for real.

Penalties and personal liability of the head of the entity

Source: NASK guide “Od wymagań do działania” (September 2026), Articles 73 and 73a of the Act.

Fines under the new provisions can first be imposed two years after the Act came into force, that is from 3 April 2028. The exception is particularly serious breaches that pose a serious threat to security, life or health, or a risk of serious damage or disruption to services: in those cases the fine can reach PLN 100 million.

Fines are not the only tool. Authorities can order deficiencies to be remedied, audit recommendations to be implemented, affected parties to be informed, or appoint a monitoring officer. For essential entities that are not public entities, a temporary ban on holding management positions is also possible.

The transition period for fines does not mean you can wait until 2028. The implementation deadline is 3 April 2027, and any incident that happens before then still has to be handled and reported.

Checklist for the coming months

This list does not replace a gap analysis, but it gives a quick picture of where an organisation stands. Every item you cannot tick with a clear conscience is a task for your plan.

Formalities

• Self-identification is documented: sector, size, status (essential, important or not covered) and the reasoning.
• The organisation is in the KSC register and its data is up to date. Public entities have completed their data after being asked.
• At least two cybersecurity contact persons are designated and have access to System S46.
• The head of the entity has completed this year's cybersecurity training and it is documented.

Organisation and documents

• There is a current inventory of systems, services and data with named owners.
• There is a risk assessment and a risk treatment plan with deadlines and owners.
• The security policy and procedures are approved by management and known to staff.
• There is a business continuity plan and a plan for restoring key systems after a failure or attack.

Technology

• Remote access, email and administrator accounts are protected with multi-factor authentication (MFA).
• Backups run automatically, at least one copy is isolated (offline or immutable), and restores are tested regularly.
• System and software updates follow an agreed schedule. No servers run without vendor support.
• The network is divided into zones and traffic between them is controlled by a firewall.
• Logs from firewalls, servers and Active Directory are collected in one place and someone actually reviews them.

People and suppliers

• Staff receive cyber hygiene training, and new starters get it during onboarding.
• There is a list of ICT suppliers with a risk rating, and contracts include security requirements and an obligation to report incidents.

Incidents

• There is an incident procedure with criteria for a “significant incident” and the 24 h, 72 h and one-month deadlines.
• It is clear who decides to report and how to reach them out of hours. The procedure has been rehearsed.

Where to start when time is short

There are only a few months left until 3 April 2027. In this situation the most effective order is to remove the biggest risks first and build the documentation in parallel:

1. Gap analysis. Compare the current state with the Act, the Polish KRI regulation and ISO/IEC 27001. The result is a prioritised list of gaps. This usually takes 3 to 6 weeks.
2. Quick technical wins. MFA, an isolated backup with a tested restore, patching, disabling unused accounts and services. These cut the risk of an attack before the first policy is written.
3. Incident procedure and contact persons. Little work, but without them you cannot meet the reporting deadlines.
4. Risk assessment and ISMS documents. Security policy, procedures, business continuity plan. Base them on what already works rather than on generic templates from the internet.
5. Training and suppliers. Train management and staff, review contracts with ICT suppliers.
6. Monitoring. Collect logs and respond to alerts, in-house or through an external SOC.

If the organisation has passed a KRI audit or runs an ISO/IEC 27001 management system, part of the work is already done. What remains is whatever the Act requires beyond those standards, such as reporting through S46 and supplier assessment.

Frequently asked questions

Sources

• Act of 23 January 2026 amending the National Cybersecurity System Act, Journal of Laws 2026, item 252 (ISAP, in Polish)
• NASK, “Od wymagań do działania. Praktyczny przewodnik po nowelizacji”, September 2026 (PDF, in Polish)
• Ministry of Digital Affairs: self-registration in the register of essential and important entities (in Polish)
• KSC register (wykaz-ksc.gov.pl)
• Directive (EU) 2022/2555 (NIS2) (EUR-Lex)

This article is for information only and is not legal advice. The law is stated as at 6 November 2026. Confirm your organisation's status with a lawyer or the Ministry of Digital Affairs.