A mid-sized logistics company operating hubs in Warsaw and Gdańsk receives a letter from the Polish national supervisory authority. The company has 60 days to demonstrate that it has implemented a risk-management programme, incident-reporting procedures, and supply-chain security controls. The management board had assumed NIS2 did not apply to them. It did. The cost of reactive compliance – legal fees, technical audits, and emergency vendor reviews – exceeded what a structured programme would have cost by a factor of three.

The NIS2 Directive was transposed into Polish law through the Act on the National Cybersecurity System (ustawa o krajowym systemie cyberbezpieczeństwa, KSC Act), with significant amendments extending its scope to a far wider range of entities than the original 2018 framework. Companies meeting the size or sector thresholds are legally required to implement cybersecurity risk-management measures, report significant incidents within 24 hours to the national supervisory authority, and secure their supply chains. Failure to comply exposes management boards to personal liability and the entity to fines reaching EUR 10 million or 2 percent of global annual turnover.

This service page explains who is caught by the Polish NIS2 framework, what obligations apply, where companies most often fail, and how cross-border groups should coordinate their Polish compliance. It also addresses the interaction with related regimes – including GDPR Poland, DORA compliance, and the AI Act Poland – that affect the same technology and data infrastructure.

Who does the Polish NIS2 framework actually catch?

The scope question is the first and most consequential issue. Polish NIS2 rules divide regulated entities into two categories: essential entities and important entities. The distinction drives the intensity of supervision, the size of fines, and the frequency of audits. Getting the classification wrong at the outset causes every subsequent compliance decision to be calibrated incorrectly.

Essential entities operate in sectors such as energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, and public administration. Important entities cover a broader set including postal services, waste management, chemicals, food production, manufacturing of critical products, and digital providers. A company in the Mazowieckie region operating a mid-sized food processing plant – previously outside any cybersecurity regime – is now an important entity under the KSC Act amendments.

Size thresholds matter alongside sector classification. Medium enterprises (at least 50 employees or annual turnover exceeding EUR 10 million) in covered sectors are automatically pulled in. Small enterprises below those thresholds may still be caught if they are the sole provider of a service essential to a Member State, or if their disruption would have significant cross-border impact. The Office of Electronic Communications (Urząd Komunikacji Elektronicznej, UKE) and the Internal Security Agency (Agencja Bezpieczeństwa Wewnętrznego, ABW) are among the competent supervisory authorities in Poland, alongside sector-specific regulators.

Self-registration is mandatory. Entities that meet the criteria must register with the appropriate supervisory authority within three months of meeting the threshold – not when contacted by the regulator. Waiting for a letter, as the logistics company in our opening scenario discovered, is not a compliance strategy. It is a liability trigger.

  • Confirm sector classification against the KSC Act annexes
  • Apply the size thresholds: 50+ employees or EUR 10m+ turnover
  • Check sole-provider and cross-border impact criteria for small entities
  • Identify the competent supervisory authority for your sector
  • Register within the statutory three-month window

What risk-management and governance obligations apply?

Once an entity is classified, the obligations are specific and non-negotiable. The KSC Act requires management bodies – not IT departments – to approve the cybersecurity risk-management framework, oversee its implementation, and take personal responsibility for compliance. Board members who do not attend mandatory cybersecurity training (required at least once per year) face personal fines. This is where the complexity trigger bites hardest: many boards still treat cybersecurity as a technical matter delegated entirely downward.

The risk-management programme must cover at least six functional areas. These include policies on risk analysis and information system security, incident handling, business continuity and crisis management, supply-chain security, acquisition and development of network and information systems, and human resources security. Each area requires documented policies, assigned ownership, and evidence of periodic review. A policy document that has not been reviewed in 18 months will not satisfy an audit by ABW or the sector regulator.

Supply-chain security deserves particular attention. Entities must assess the cybersecurity practices of direct suppliers and service providers. For a Warsaw-based IT services company with 40 subcontractors, this means contractual clauses, periodic questionnaires, and documented risk assessments for each material vendor. We assisted a technology group in Małopolska in building a tiered vendor classification system (autumn 2025) that reduced their audit preparation time from six weeks to eight days.

Incident reporting runs on a strict timeline. A significant incident must be notified to the competent authority within 24 hours of detection (early warning), followed by a full incident notification within 72 hours, and a final report within one month. Missing the 24-hour early warning window – even by a few hours – constitutes a separate breach from the underlying incident. The Computer Security Incident Response Team (Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego, CSIRT) at national level coordinates response, but the reporting obligation runs directly to the entity's sector supervisor.

For a tailored strategy on NIS2 risk-management programme design and board-level governance, reach out to info@kordeckipartners.com.

Where do companies most often fail in practice?

Polish NIS2 compliance failures cluster around four recurring patterns. Understanding them before an audit is far cheaper than explaining them during one. The common thread is that entities treat the KSC Act as a documentation exercise rather than an operational change programme – and auditors know exactly how to test the difference.

The first failure is scope denial. Companies convince themselves they are below the threshold or outside a covered sector. The KSC Act's sector annexes are broader than most legal teams initially read them. A company providing facility management services to hospitals may be treated as part of the health sector supply chain, pulling it within scope even if its own core activity is cleaning and maintenance.

The second failure is governance theatre. A board resolution approving a cybersecurity policy – without evidence that board members understood it, attended training, or received incident reports – will not survive supervisory scrutiny. The KSC Act explicitly places accountability at management-body level. Delegating everything to a Chief Information Security Officer without board oversight is a structural deficiency, not a minor gap.

The third failure is supply-chain neglect. Entities focus on their own systems and ignore vendor risk. A significant incident caused by a third-party software provider still triggers the entity's own reporting obligations. The entity cannot deflect liability by pointing to the vendor. Contractual clauses requiring vendors to notify the entity within 12 hours of a security incident are now standard in well-drafted technology agreements – and their absence is a red flag in any NIS2 audit.

The fourth failure is GDPR-NIS2 disconnection. Many companies have mature GDPR programmes but run them in a separate silo from cybersecurity compliance. Incident response procedures, data-breach notification timelines, and risk registers overlap substantially. A breach affecting personal data triggers both a GDPR obligation to notify the Personal Data Protection Office (Urząd Ochrony Danych Osobowych, UODO) within 72 hours and a NIS2 obligation on a parallel track. Running two disconnected processes doubles effort and creates dangerous gaps – for instance, where the GDPR team notifies UODO but the NIS2 team misses the early-warning window to the sector supervisor.

How do cross-border groups coordinate Polish NIS2 compliance?

For a German investor operating a subsidiary in Poland, or a group with entities across multiple EU Member States, NIS2 compliance is not a local Polish matter that can be delegated entirely to Warsaw counsel and forgotten. The Directive creates a lead-authority mechanism for digital infrastructure and digital service providers, but for most industrial and commercial entities, supervision is national. Each subsidiary must comply with the law of the Member State where it operates – meaning a group with Polish, German, and Czech entities faces three parallel national frameworks, each with its own registration, reporting, and audit requirements.

The Polish framework has specific features that differ from implementations in other Member States. The KSC Act places explicit obligations on management bodies that go beyond what some other transpositions require. The ABW's supervisory role for essential entities in defence-adjacent sectors adds a layer that has no direct equivalent in several Western European implementations. Groups that built their NIS2 programme on a German or Dutch template and assumed Poland would be identical have consistently encountered gaps.

Cross-border incident coordination is a practical challenge. A ransomware attack affecting a group's shared IT infrastructure in multiple countries triggers simultaneous reporting obligations to each national authority on their own timelines. The group's central incident-response team must be capable of filing parallel notifications – and must have pre-agreed communication protocols with local legal counsel in each jurisdiction. We secured interim protective measures for a German investor's Polish subsidiary in Lower Silesia (spring 2026) during a multi-jurisdictional incident, coordinating simultaneous notifications to Polish and German authorities within the 24-hour window.

The interaction with DORA compliance is material for groups that include financial entities. DORA applies directly to banks, insurers, investment firms, and a range of other financial sector participants from January 2025. Where a group has both a financial subsidiary (subject to DORA) and non-financial subsidiaries (subject to NIS2 via the KSC Act), the group's shared IT and cybersecurity infrastructure must satisfy both regimes simultaneously. The Polish Financial Supervision Authority (Komisja Nadzoru Finansowego, KNF) supervises DORA compliance for Polish financial entities, while NIS2 supervision runs through sector-specific authorities. Aligning the two programmes – risk registers, incident classification, vendor management – is essential to avoid duplicative effort and conflicting obligations.

For a tailored strategy on multi-jurisdictional NIS2 coordination and DORA alignment for Polish subsidiaries, contact info@kordeckipartners.com.

How does NIS2 interact with AI Act Poland and related technology regimes?

NIS2 does not operate in isolation. Three other regulatory frameworks affect the same technology infrastructure, and compliance programmes that ignore the overlaps will generate both gaps and redundancies. The AI Act Poland dimension is the most recent addition to this stack, but it is already reshaping how in-house legal teams must think about technology governance.

The AI Act imposes risk-classification requirements on AI systems used within the EU. High-risk AI systems – including those used in critical infrastructure management, which overlaps directly with NIS2 essential-entity sectors – require conformity assessments, technical documentation, and human oversight mechanisms. A company that is both a NIS2 essential entity and a deployer of high-risk AI systems faces obligations under both regimes for the same technology. Aligning the risk-management documentation avoids duplication and creates a stronger audit trail. For context on how technology law interacts with IP strategy, see our analysis of IP protection strategy for US tech companies in Poland.

GDPR Poland integration is the most operationally mature of the overlapping regimes. Data protection impact assessments, records of processing activities, and technical security measures required under GDPR align closely with NIS2 risk assessments and security policies. The most efficient approach is a unified risk register that satisfies both regimes, with incident response procedures that trigger the correct notification path depending on whether personal data is involved, whether the incident is significant under NIS2 criteria, or both.

Trademark and IP lawyer Warsaw considerations arise where cybersecurity incidents affect proprietary systems, trade secrets, or licensed technology. A breach exposing source code or customer data covered by confidentiality agreements creates liability chains beyond the regulatory sphere. The NIS2 incident report to the supervisory authority is not privileged – it can be requested in subsequent civil litigation. Structuring incident-response communications carefully, with legal counsel involved from the outset, is not paranoia. It is standard practice in any well-run incident-response programme.

Data transfer obligations add a further layer for groups moving personal data internationally. The legal mechanisms governing data transfers from Poland to third countries or between EU Member States affect how incident data, audit logs, and security documentation can be shared within a group. For a detailed analysis of the applicable mechanisms, see our guide on data transfer from Poland to France – legal mechanisms. Groups with family-ownership structures or holding-company arrangements should also consider how asset-protection planning intersects with cybersecurity liability exposure; our discussion of family foundation in Poland – tax advantages and setup addresses related structuring questions.

What is the enforcement picture and what fines apply?

The enforcement framework is calibrated to create genuine financial deterrence. Essential entities face fines of up to EUR 10 million or 2 percent of global annual turnover (whichever is higher). Important entities face fines of up to EUR 7 million or 1.4 percent of global annual turnover. These are not theoretical maximums – supervisory authorities have the power to impose them per violation, and failure to register, failure to implement a risk-management programme, and failure to report an incident are each separate violations.

Management board liability is personal and direct. Board members who fail to ensure the entity meets its NIS2 obligations can be fined individually – separate from any fine imposed on the entity. The KSC Act also grants supervisory authorities the power to issue binding instructions requiring specific remediation steps within defined timeframes, to conduct on-site inspections without prior notice, and to impose temporary prohibitions on individuals from holding management positions in regulated entities. A prohibition of this kind – lasting up to two years – is an irreversible consequence that no board member should dismiss as a theoretical risk.

The audit cycle for essential entities includes mandatory periodic audits every two years, conducted either by the supervisory authority directly or by accredited third-party auditors. Important entities are subject to ex-post supervision, meaning audits are triggered by incidents, complaints, or supervisory risk assessments rather than on a fixed calendar. This distinction is misleading. Important entities that experience a significant incident should expect an audit within weeks. Entities that have not completed their compliance programme before an incident occurs will face simultaneous remediation and supervisory scrutiny – a position that is both expensive and reputationally damaging.

The supervisory authorities have signalled that their initial enforcement focus will be on registration compliance and incident-reporting failures. Both are straightforward to detect: an entity either appears in the register or it does not, and incident notifications either arrive on time or they do not. Structural compliance gaps in risk-management programmes are harder to detect remotely but become visible immediately on inspection.

NIS2 compliance checklist – what to prepare

The following checklist consolidates the operational steps that entities in Poland must complete. It is designed for management teams conducting an initial self-assessment, not as a substitute for a full legal and technical review. Each item represents a discrete deliverable that supervisory authorities will expect to see during an inspection.

  • Scope determination: confirm sector classification and apply size thresholds; document the analysis and the conclusion
  • Registration: file with the competent supervisory authority within three months of meeting the threshold; retain confirmation of filing
  • Governance framework: adopt a board-level resolution approving the cybersecurity risk-management programme; ensure board training is completed and documented within the first year
  • Risk-management programme: develop and implement documented policies covering the six functional areas required by the KSC Act, with assigned ownership and a review schedule
  • Incident-response procedures: establish and test procedures that meet the 24-hour early-warning and 72-hour full-notification deadlines; integrate GDPR breach-notification procedures into the same workflow

Beyond the checklist, three business scenarios illustrate how the programme applies in practice. A manufacturing company in Silesia with 200 employees producing components for the automotive sector is an important entity; it must register, implement a risk-management programme, and conduct annual supply-chain assessments of its tier-one software vendors. An IT services company in Warsaw providing managed security services to banks is both a NIS2 important entity and likely subject to DORA obligations through its financial-sector clients' contractual requirements. A foreign investor establishing a Polish subsidiary to operate digital marketplace infrastructure is an essential entity from day one – registration and a compliant programme must be in place before the platform goes live, not after the first incident.

To receive an expert assessment of your company's NIS2 classification and compliance readiness, contact info@kordeckipartners.com.

Frequently asked questions

Q: How long does a full NIS2 compliance programme take to implement for a mid-sized Polish company?

A: For a medium enterprise with no prior cybersecurity programme, a realistic timeline is four to six months from initial scoping to a fully documented and tested framework. The critical path items are the risk-management programme documentation (six to eight weeks), vendor assessments (four to eight weeks depending on supply-chain complexity), and board training (which must be scheduled around management availability). Entities that already have a mature GDPR programme can typically reduce this to three to four months by integrating existing risk registers and incident-response procedures into the NIS2 framework rather than building parallel documents.

Q: Does NIS2 apply to Polish subsidiaries of foreign groups even if the parent has already completed NIS2 compliance in another EU Member State?

A: Yes. Each entity must comply with the national law of the Member State where it operates. A parent company's compliance with German or French NIS2 transposition does not satisfy the Polish KSC Act obligations. The Polish subsidiary must register with the appropriate Polish supervisory authority, implement a programme that meets Polish statutory requirements, and report incidents to Polish authorities on Polish timelines. Group-level programmes can provide a useful baseline, but they require Polish-specific adaptation – particularly regarding the management-body accountability provisions and the role of ABW as a supervisory authority for certain essential entities.

Q: Is it a common misconception that only large companies are affected by NIS2 in Poland?

A: It is one of the most persistent misconceptions. The KSC Act catches medium enterprises – defined as at least 50 employees or EUR 10 million in annual turnover – operating in covered sectors. A company with 55 employees providing IT services to hospitals, or operating a regional energy distribution network, is within scope regardless of how small it feels relative to national incumbents. Small enterprises below the thresholds may also be caught if they are sole providers of essential services or if their disruption would have cross-border impact. The safest approach is to conduct a formal scope analysis rather than assume exemption based on company size alone.

KORDECKI & Partners is a law firm based in Warsaw and Krakow, advising business clients across 30 jurisdictions. Our team combines expertise in Polish and international law with a practical approach to technology law, cybersecurity compliance, AI Act readiness, and DORA implementation. We work with Polish entrepreneurs, foreign investors, and in-house legal teams navigating NIS2 obligations under the KSC Act. To discuss your situation, contact info@kordeckipartners.com.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. KORDECKI & Partners assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@kordeckipartners.com.