NIS2 and Poland's cybersecurity act: what to do with all that documentation, and how it ties into GDPR

The amendment to Poland's National Cybersecurity System Act (ustawa o KSC), which implements the NIS2 directive into Polish law, came into force on 3 April 2026. Since then one of two things usually happens inside companies: silence, or panic and the question "so now we have to write a second set of policies?".

The answer is: no, not a second set. If you have GDPR in place, you already have a substantial part of what KSC requires - just written from a different angle. This article explains, in plain terms, what you need on paper, by when, and exactly where GDPR and KSC overlap.

Start with the calendar - it decides the order of the work

The deadlines run from the day the act came into force (gov.pl):

• 3 April 2026 - the amendment came into force.
• 3 October 2026 - deadline for self-assessment and entry in the register of key and important entities (via the S46 system). This is the nearest date and the one most often missed.
• 3 April 2027 - deadline for implementing the information security management system (ISMS) - that is, all the documentation and procedures.
• 3 April 2028 - deadline for the first security audit. Then at least once every three years.

So: first establish whether you are a key or important entity at all, and register. You have a year longer for the documentation. Doing it the other way round - writing policies first, checking whether you had to second - is the most expensive mistake available.

What the documentation actually has to cover

No legal jargon - here is what the ISMS has to include:

1. Risk analysis - which threats apply to your systems and services, how likely, how damaging, and what you do about them.
2. Inventory - what systems, data, hardware and suppliers you have. You cannot protect what is not on a list.
3. Security policies - access, passwords, updates, backups, remote work.
4. Incident handling and reporting procedure - with hard clocks (more on those in a moment).
5. Business continuity and backups - what you do when a system goes down, and how fast you come back.
6. Supply-chain security - requirements for IT suppliers, and the clauses in their contracts.
7. Training - for staff and for management (KSC explicitly requires this).
8. Audit - planned, recurring, with a report.

On top of that comes hard personal liability of the entity's manager - a fine of up to 300% of their monthly salary in private entities. Fines for the entities themselves reach EUR 10 million or 2% of turnover (key entities) and EUR 7 million or 1.4% of turnover (important entities). That is not a number you simply book as a cost.

And here is where GDPR comes in - you have already done most of this work

If you have GDPR implemented, you are not starting from a blank page. Look at the overlap:

The difference is in the perspective, not in the documents. GDPR asks: "is personal data safe, are people's rights protected?" KSC asks: "will your service keep running when someone attacks you?" The same server, the same backup, the same procedure - simply judged from a different angle.

That is why you do the risk analysis once, but look at it with two sets of eyes: what threatens personal data (GDPR) and what threatens service continuity (KSC). One document, two columns of conclusions.

The key practical point: one event, two separate notifications

This is where companies most often trip. A leak of client data is simultaneously:

• a personal data breach → notify the Polish DPA (PUODO) within 72 hours (Art. 33 GDPR) and, where the risk is high, notify the affected individuals,
• a serious incident → notify the relevant CSIRT: an early warning within 24 hours, the proper report within 72 hours, and a final report within one month.

Two different authorities, two different clocks, and the shortest of them is 24 hours. In practice this means one thing: your incident procedure must carry both paths in a single document, with a clear "who calls, who writes, who decides". The person who spots a break-in at 2 a.m. will not be cross-referencing two separate binders.

The most common mistake: two parallel worlds of documentation

We see it regularly: a company has one security policy "from GDPR" and a second one "from KSC". Two asset registers. Two incident procedures. Two training plans.

Nobody keeps that setup alive for more than a year. The documents drift apart, and during an inspection it turns out a system exists in one register and no longer in the other. There is only one healthy approach: a single security management system in which GDPR and KSC are two sets of requirements, not two filing cabinets.

What to do - six steps, in order

1. Check whether you are a key or important entity. Sector, size, type of services. That is an hour's decision, not a quarter's project.
2. Register by 3 October 2026. Failing to enter the register is a stand-alone basis for a fine - regardless of how well protected you actually are.
3. Pull out your GDPR documentation and treat it as the starting point. The processing record, DPIAs, the breach procedure, data processing agreements - these are foundations, not waste paper.
4. Do one risk analysis with two perspectives - personal data and service continuity.
5. Merge the incident procedure - one internal report, two external paths (CSIRT 24 h / 72 h, PUODO 72 h).
6. Add what GDPR does not cover: business continuity, requirements for IT suppliers, management training, and an audit plan for 3 April 2028.

You have until 3 April 2027 for the ISMS. You have until 3 October 2026 for the register entry - and that is the clock ticking right now.

Not sure where to start - or whether any of this applies to you? Kiran Sp. z o.o. has been doing GDPR rollouts since 2018: legal and IT audits, documentation and ongoing monitoring. That same documentation is today the foundation of KSC compliance. Get in touch - we'll start by establishing whether you are a key or important entity, and what follows from that. Our article GDPR audit step by step is a useful companion piece.