Poland Software Supply Chain and AI Security Rules: A 90-Day Plan

If your organisation builds, buys or runs software in Poland, the rule that now matters most is the amended Act on the National Cybersecurity System (ustawa o krajowym systemie cyberbezpieczeństwa, the KSC Act). The amending act of 23 January 2026 transposes NIS2, was published in the Journal of Laws on 2 March 2026 and has been in force since 3 April 2026. Entities in scope had until 3 October 2026 to apply for entry on the national register, and must meet the Chapter 3 security duties by 3 April 2027. Banks and other financial entities answer to DORA, supervised by the Polish Financial Supervision Authority (KNF). Poland's own AI systems act came into force on 11 August 2026, and the EU Cyber Resilience Act reporting duties have applied since 11 September 2026.

The practical answer is the same for all of them: know what is in your software, know who supplied it, decide quickly when a component turns out to be vulnerable, and keep a record your management body has seen and signed.

This guide is for the CISO, AppSec, engineering, GRC, vendor risk and the data protection officer in Polish organisations, and for foreign software makers selling to them. The first two thirds work with any tools. Safeguard enters at "How Safeguard does this".

This is not legal or regulatory advice. Where the post describes a rule, it describes the primary text as published on 26 October 2026. Your supervisor, auditor and counsel decide how it applies to you.

Key takeaways

• The NIS2 transposition is in force. The Act of 23 January 2026 amending the KSC Act (Journal of Laws 2026, item 252) has applied since 3 April 2026.
• The registration window has closed. Entities already in scope applied between 7 May and 3 October 2026; later entrants apply within six months.
• 3 April 2027 is the next big date for the Chapter 3 security duties. Key entities complete their first audit by 3 April 2028.
• Incident clocks are 24 hours, 72 hours and one month, to the competent sector CSIRT.
• Supply chain is written into the law. Article 8 covers secure acquisition and development, ICT supply chain security, regular updates and prompt action on vulnerabilities. Article 67b lets the Minister name a high-risk vendor, with a phase-out of up to seven years.
• Management carries the duty, with annual training and personal fines of up to 300% of remuneration.
• Financial entities follow DORA. The KSC Act names the KNF as the DORA competent authority and, with listed exceptions, defers to DORA for banking and market infrastructure entities.
• Poland has a national AI law. The Act of 3 July 2026 names the Commission for the Development and Security of Artificial Intelligence as the AI Act supervisor.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA and deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, license compliance, the Compliance and GRC suite with framework pages for the Poland KSC Act, NIS2, DORA and the EU CRA, TPRM SBOM requests and monitoring, CSAF and VEX upload, Trust Center, attestation and signing, Package Firewall, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, autonomous remediation (ships switched off), the CLI and local runner, Zero AI mode, bring your own model, and private VPC, on-prem and air-gapped deployment.

Who this applies to in Poland

Poland's 2018 system was built around operators of essential services. The 2026 amendment replaces that model with the NIS2 categories, widens the sectors and makes each entity identify itself.

Key and important entities. Medium and large organisations in the sectors listed in Annexes 1 and 2 of the amended Act fall in scope: energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public entities, space, postal and courier services, waste, chemicals, food, manufacturing, digital providers and research. Some smaller organisations are in scope by type, such as DNS providers, TLD registries and trust service providers. Under Article 7c each entity applies for entry on the register itself; operators of essential services on the old register were moved across by the Minister.

Public entities. Many public bodies are key or important entities. A public entity that is an important entity follows the information security management standard in Annex 4 of the Act instead of the full Article 8 list, and the Minister can designate a state legal person as a key entity by decision (Article 7m).

Regulated finance. Banks, payment institutions, investment firms, insurers and the other financial entities covered by DORA, Regulation (EU) 2022/2554, are supervised by the KNF (Komisja Nadzoru Finansowego). The KSC Act itself names the KNF as the competent authority within the meaning of DORA.

Software, hardware and cloud suppliers. The Act reaches suppliers three ways: through their customers' supply chain duties (contracts, questionnaires, audits); directly, for managed service, managed security, cloud, data centre and other digital providers, which apply Commission Implementing Regulation (EU) 2024/2690 under Article 8b; and through the high-risk vendor procedure in Article 67b, which can reach any supplier of hardware or software (dostawca sprzętu lub oprogramowania).

Manufacturers selling products with digital elements. Anyone placing such products on the EU market, wherever they are based, falls under the Cyber Resilience Act, Regulation (EU) 2024/2847.

Providers and deployers of AI systems. The EU AI Act, Regulation (EU) 2024/1689, applies across the EU. Poland's Act of 3 July 2026 on artificial intelligence systems sets up the national supervisor and procedures.

Anyone processing personal data. The GDPR applies, enforced in Poland by the President of the Personal Data Protection Office (UODO).

The rules, regulator by regulator

The amended KSC Act: Poland's NIS2 law

Status today. The Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts was published in the Journal of Laws (Dziennik Ustaw) 2026, item 252, on 2 March 2026. Under its Article 49 it entered into force one month later, and the Sejm's ELI legal acts service records it as in force from 3 April 2026. (The ISAP database page would not load for us; this status comes from the ELI record and the published text.)

Who supervises. The Minister of Digital Affairs keeps the register of key and important entities. Sector authorities for cybersecurity (organy właściwe do spraw cyberbezpieczeństwa) supervise their sectors, inspect and can order audits. The national CSIRTs are CSIRT NASK (operated by NASK, whose team is CERT Polska), CSIRT GOV and CSIRT MON, and sector CSIRTs receive incident reports.

What it requires. The core duties for software teams sit in a handful of articles:

• Article 7c, registration. Apply within six months of meeting the criteria, update within 14 days of any change, with a statement by the head of the entity made under criminal liability.
• Article 8, the information security management system. Systematic risk assessment and proportionate measures. Article 8(1)(2) lists, among others, security in acquiring, developing, maintaining and operating the system, including testing (point b); security and continuity of the ICT supply chain, taking account of the relationship with each direct supplier of hardware or software (point e); continuous monitoring (point g); and asset management (point m). Article 8(1)(3) requires collecting threat and vulnerability information. Article 8(1)(5) requires regular software updates per the producer's recommendations, with an analysis of their effect and criticality (point b), protection against unauthorised modification (point c) and prompt action on vulnerabilities (point d).
• Article 8(2), suppliers. Weigh each supplier's vulnerabilities, the quality of its ICT products and processes, EU coordinated risk assessments under Article 22 of NIS2 and any Article 67b outcome.
• Article 8b, digital providers. Cloud, data centre, managed service, managed security and other listed digital providers apply Implementing Regulation 2024/2690.
• Articles 8c to 8f, management. The head of the entity (kierownik podmiotu) is responsible even when tasks are delegated; on a board with no named person, every member is. The head decides on the security system, plans the budget and trains once every calendar year. Staff doing Article 8 or Article 11 tasks first provide a criminal record certificate.
• Article 11, incidents. Early warning of a serious incident to the competent sector CSIRT no later than 24 hours from detection (point 4); notification within 72 hours (point 4a); interim reports on request (point 4b); final report within one month of the notification (point 4c). Trust service providers report within 24 hours.
• Article 15, audit. Key entities audit at their own cost at least once every three years, by an auditor who did not do their Article 8 to 13 work in the prior year.
• Article 16, new entrants. Chapter 3 duties within 12 months of meeting the criteria; first audit for key entities within 24 months.

Deadlines that remain. For entities in scope on 3 April 2026, transitional Article 33 sets Chapter 3 duties by 3 April 2027 and the first key entity audit by 3 April 2028. Former operators of essential services had until 3 October 2026 to start reporting under the new Articles 11 to 12b. The Minister's communication of 8 April 2026 (Official Journal of the Minister of Digital Affairs, item 7) set the 7 May to 3 October 2026 registration window. If you were in scope and missed it, talk to counsel now.

Penalties. Up to EUR 10 million or 2% of revenue, whichever is higher, for key entities, and up to EUR 7 million or 1.4% of revenue for important entities. Under Article 73a the head of the entity can be fined personally up to 300% of remuneration (100% in public entities).

The high-risk vendor procedure (Articles 67b to 67c)

The Minister of Digital Affairs, to protect state security or public order, can start proceedings to recognise a supplier of hardware or software as a high-risk vendor. The procedure covers suppliers used by key and important entities (except in the electronic communications subsector), electronic communications undertakings with annual telecoms revenue above PLN 10 million, and financial entities other than those under the DORA simplified framework in Article 16 of DORA. An opinion team advises, the decision is immediately enforceable and is published in Monitor Polski.

Once a decision is issued, the entities concerned may not put into use the ICT products, services and processes it covers, and must withdraw them within seven years of publication. Telecoms operators withdraw products in the critical functions listed in Annex 3 within four years. Until withdrawal, repair, modernisation, part replacement and updates are allowed where needed for continuity.

For a software team, the consequence is simple: know which products, services and dependencies come from which supplier, before a decision lands.

DORA and the KNF

DORA has applied to EU financial entities since 17 January 2025, and it is directly applicable in Poland. The amended KSC Act names the KNF as the competent authority under DORA. Article 8i of the KSC Act then switches off the Act's own rules on security management systems and serious incident reporting for key and important entities in banking and financial market infrastructure, keeping a listed set of provisions (including registration, Article 8(1)(1) risk assessment, cyber hygiene in Article 8(1)(2)(j), information sharing, and the high-risk vendor provisions). The management duties in Articles 8c to 8f apply to them correspondingly. CSIRT NASK and CSIRT GOV keep tasks for major ICT-related incidents in the sector.

For a Polish bank's software teams, DORA's own articles carry the weight: ICT risk management (Articles 5 to 16), major ICT-related incident reporting to the KNF (Articles 17 to 23), resilience testing (Articles 24 to 27) and ICT third-party risk, including the register of information and contract terms (Articles 28 to 30).

CERT Polska and coordinated vulnerability disclosure

CERT Polska is the team inside NASK that operates CSIRT NASK. Under the amended Article 26a, CSIRT NASK is Poland's coordinator for coordinated vulnerability disclosure, so it is the national contact when a researcher reports a flaw in your product or you find one in someone else's. CERT Polska's incident reports and advisories are not binding law, but supervisors will expect you to act on those that touch your estate.

The National Cybersecurity Certification System Act

Poland's Act of 25 June 2025 on the national cybersecurity certification system (Journal of Laws 2025, item 1017) has been in force since 28 August 2025. It sets up the national framework for certifying ICT products, services and processes and connects it to the EU Cybersecurity Act, Regulation (EU) 2019/881. It does not make certification mandatory for software in general; it matters when a buyer, a tender or a future EU scheme asks for a certificate.

The EU Cyber Resilience Act

The CRA entered into force on 10 December 2024. Manufacturers must report actively exploited vulnerabilities and severe incidents through the ENISA single reporting platform from 11 September 2026, and the main obligations, including the Annex I essential requirements and the SBOM duty, apply from 11 December 2027. Annex I Part II asks manufacturers to identify and document components, including by drawing up a software bill of materials, and to address and remediate vulnerabilities without delay. The CRA applies in Poland as in every member state.

The EU AI Act and Poland's AI systems act

The European Commission's AI Act page says the Act became applicable on 2 August 2026, with exceptions: prohibitions and AI literacy from 2 February 2025, general-purpose AI obligations from 2 August 2025, and, following the political agreement on the "AI Omnibus", high-risk rules for Annex III use cases from 2 December 2027 and for Annex I products from 2 August 2028. Poland's Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026, item 1003) was published on 27 July 2026 and, per the Sejm's ELI record, entered into force on 11 August 2026. Its Article 127 delays several parts, including Articles 8 to 18 and Chapters 3 to 5, 8 and 9, until three months after publication. Article 5 makes the Commission for the Development and Security of Artificial Intelligence (Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji) the market surveillance authority for AI systems under Article 70(1) of the AI Act and the single point of contact under Article 70(2). The Sejm appointed the Commission's chair by resolution of 18 September 2026, with Senate consent on 24 September 2026.

UODO and the GDPR

The President of UODO enforces the GDPR in Poland. Article 33 GDPR requires a controller to notify a personal data breach within 72 hours of becoming aware of it, and Article 32 requires security appropriate to the risk. A serious incident under the KSC Act that also touches personal data starts both clocks, to different recipients.

What the rules ask of software and open source

Across the regimes, the asks are the same six things. The table maps each to what a supervisor, sector authority or auditor is likely to ask to see. It is drawn from the primary texts above; it does not reproduce any official checklist.

The amended KSC Act does not use the word SBOM. It asks for asset management, supply chain security and vulnerability handling, and an SBOM is the most direct way to show all three for software. The CRA does name it.

Real public incidents in or affecting Poland

We keep this section to official reporting, and to one case.

The energy sector attacks of 29 December 2025. On 30 January 2026 CERT Polska published an incident report on a coordinated, destructive cyberattack carried out on 29 December 2025 against more than 30 wind and photovoltaic farms, a large combined heat and power plant and a manufacturing company. CERT Polska reports that IT systems and industrial devices were damaged and that communication between the renewable farms and the distribution system operator was disrupted, while electricity production and heat supply continued. We cover the report in a separate post, Poland energy sector wiper attacks, December 2025, so we do not repeat its technical detail here. The point for this guide is narrower: energy is an Annex 1 sector, and organisations like these are the ones the amended Act now calls key or important entities, with 24 hour reporting clocks and named management responsibility.

CERT Polska's annual report for 2025, published on 8 April 2026, is the wider reference for incident trends in Poland. Read its statistics section yourself before quoting figures from it.

The personas who own the problem

CISO

The CISO owns the Article 8 security management system and the incident procedure. The trigger is 3 April 2027. Before then the CISO needs to show the board a risk assessment, measures mapped to Article 8(1)(2), a tested 24 hour early warning path and a training record for the head of the entity. A bad week is a serious incident in March 2027 with no tested reporting path.

Head of AppSec or product security

This person owns regular updates and prompt action on vulnerabilities under Article 8(1)(5), and the CRA's vulnerability handling duties for manufacturers. They need a readable triage rule, a component inventory per product and a way to record "not affected". Their trigger is the next advisory on a widely used library.

VP or Director of Engineering

Engineering owns the pipeline and wants one process that satisfies the KSC Act, DORA for financial customers and the CRA, not three, with gates that do not stop every release on day one.

GRC and compliance lead

The GRC lead owns registration under Article 7c, Article 8 evidence, the Article 15 audit and the KSC to DORA mapping for financial groups. Their trigger is an inspection or the audit plan. They need evidence by article, with dates.

Procurement and vendor risk owner

Article 8(2) asks the entity to weigh each supplier's vulnerabilities and product quality, and Article 67b means any supplier could be named high-risk. The vendor risk owner needs a register linking each supplier to what it supplies and where it runs, plus supplier SBOMs on a schedule. Their trigger is a renewal or a decision in Monitor Polski.

Data protection officer

The DPO (inspektor ochrony danych) owns the GDPR clock and transfer analysis, including where any security tool processes data.

The head of the entity

The kierownik podmiotu is personally responsible and can be fined. The board needs a short, dated record: decisions, budget, training and open items.

Foreign software makers selling into Poland

Your customer's Article 8(1)(2)(e) and 8(2) duties become your questionnaire; Article 8b may apply to you directly as a managed or cloud provider; and the CRA applies to products with digital elements. Expect requests for SBOMs, vulnerability policies and incident contacts.

A practical 30/60/90-day plan

This plan works with any tooling and is built backwards from 3 April 2027.

Days 1 to 30: confirm scope, register and inventory

1. Confirm your category against the Annexes (key, important or neither) and record the reasoning.
2. Confirm registration. If you were in scope on 3 April 2026 and not entered automatically, check your application was filed by 3 October 2026. If not, involve counsel this week.
3. Name the head of the entity and delegates, and book the annual Article 8e training.
4. Run the Article 8f criminal record checks for everyone doing Article 8 or Article 11 tasks.
5. Build the system inventory: every information system behind your service, with its software and owners.
6. Generate SBOMs in SPDX or CycloneDX for the software you build, starting with the regulated service.
7. Start the supplier register: what each supplier provides, where it runs, and the renewal date.

Days 31 to 60: vulnerability handling, incidents and suppliers

1. Write the triage rule: known exploitation, exploit probability, reachability and exposure, with timelines.
2. Add an update impact record, because Article 8(1)(5)(b) asks you to weigh the effect and criticality of updates.
3. Rehearse the 24 hour early warning with a tabletop. Time how long it takes to say which products contain the affected component.
4. Map the parallel clocks: KSC Article 11, DORA Article 19, GDPR Article 33 and CRA Article 14. Write down who reports to whom, by when.
5. Send supplier evidence requests (template below) to critical suppliers.
6. Test high-risk vendor readiness: if a supplier were named under Article 67b tomorrow, could you list every affected product?

Days 61 to 90: gates, evidence and the board pack

1. Add release gates: warn first, then block on the clearest rules once the backlog is under control.
2. Record exceptions with a justification, an approver and an expiry date.
3. Keep build provenance and hashes for deployed software, for Article 8(1)(5)(c).
4. Inventory AI systems: models, agents and AI services, their purpose and data.
5. Assemble the evidence pack, one folder per Article 8 point.
6. Take it to the board, minute the decision and plan the first Article 15 audit.

Template: supplier software evidence request

Use this text, adapted to your contract:

As a key (or important) entity under the Polish Act on the National Cybersecurity System, we must manage the security of our ICT supply chain under Article 8(1)(2)(e) and 8(2). Please provide, for each product or service you supply to us: a software bill of materials in SPDX or CycloneDX format for the current release; your vulnerability handling and disclosure policy; your target timelines for fixing critical and high vulnerabilities; a 24 hour security contact; and notice of any change in your own critical suppliers. Please update the SBOM with each release.

Decision table: one vulnerability, which clock?

Illustrative scenario: a Friday advisory

Illustrative scenario, with invented round numbers. On a Friday an advisory lands for a widely used open source library. A Polish important entity runs 40 applications. Without an inventory, Monday comes and nobody can say whether the payment portal is affected. With SBOMs per application and supplier SBOMs on file, the team lists 6 affected applications within an hour, sees that 2 call the vulnerable function, patches those first and records "not affected" for the rest.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh as of 26 October 2026. Every capability named is GA. Commands are shown as the docs show them; we did not run them. Safeguard helps a team produce and keep the evidence these regimes ask for.

Step 1: Build the inventory with SBOM generation (GA)

1. Connect the repositories and registries for the software you build. Safeguard generates SBOMs (GA) in SPDX and CycloneDX and runs software composition analysis with deep transitive dependency scanning (GA).
2. Where you cannot or will not connect a repository, the Safeguard CLI and local runner (GA) scan on your own machine. The CLI docs show:

# Sign in (OAuth device-code flow)
safeguard login

# Scan a local directory
safeguard scan --dir .

# Scan an SBOM you already have (SPDX or CycloneDX)
safeguard scan --sbom sbom.json

3. Check SBOMs you receive or produce before you rely on them:

safeguard validate sbom.json --strict -o report.json

Step 2: Map scans to the Polish and EU framework pages (GA)

The Compliance and GRC suite (GA) includes framework pages that matter here. Each is on in a workspace unless you switch it off under Compliance › Manage.

• Poland KSC Act: each scan of a product checks six requirements against what the scan found, including the SBOM. They cover systematic risk assessment and proportionate measures (tied to Article 8), integrity protection, security documentation (tied to Article 10), incident handling (tied to Article 11) and vulnerability information. The page also lists catalogue controls and a KSC incident response and reporting procedure template. Two cautions: the identifiers on that page are Safeguard's own labels, not the Act's numbering, and the page describes the Act in its earlier "operators of essential services" terms. Map its checks to the amended articles yourself.
• EU NIS2 Directive, covering supply chain measures and vulnerability management; EU DORA for KNF-supervised entities; and the EU Cyber Resilience Act for manufacturers.

You evidence non-scan controls with automated tests, uploaded evidence, policies or an attestation.

Step 3: Prioritise with vulnerability management and reachability analysis (GA)

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis (GA) ranks them by whether the vulnerable code path is actually called. That is the days 31 to 60 triage rule, applied on every scan.

Step 4: Record "not affected" decisions with CSAF and VEX upload (GA)

CSAF and VEX upload (GA) keeps supplier advisories and your own exploitability statements next to the findings they explain.

Step 5: Enforce rules with policies and gates (GA)

1. Go to Settings › Policies and create a policy.
2. Set each policy's action. The docs define three: Block (the gate fails), Warn (the gate passes with a warning) and Notify (the gate passes and a notification is sent).
3. Approvals run through exceptions: a developer requests an exception with a justification, approvers decide, and the history is kept. That is the exception record from days 61 to 90.
4. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate GATE_NAME

The docs say this fails the CI job when the gate fails.

5. License compliance (GA) runs in the same pipeline.
6. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a build.

Step 6: Request and monitor supplier evidence with TPRM (GA)

1. In TPRM (Third-Party Risk Manager), request an SBOM from a supplier using a request template with a format and a deadline, or send a bulk request to several suppliers at once. Custom templates can carry the evidence request text above.
2. TPRM monitoring watches supplier SBOMs for new risk, with alert types the docs name, including a CVE added to CISA KEV and SBOM expiry.

Step 7: Fix what you own with autonomous remediation (GA, ships off)

For repositories you connect, autonomous remediation opens tested, policy gated fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.

Step 8: Integrity, provenance and sharing (GA)

1. Attestation and signing (GA) records build provenance with in-toto and SLSA provenance, and SCAL and LCAL scores, for software you build. That supports the protection against unauthorised modification in Article 8(1)(5)(c).
2. Trust Center (GA) publishes your posture and documents, such as SBOMs and VEX, to customers. Publishing is an explicit action.

Step 9: Inventory and govern AI (GA)

1. AI-BOM discovery (GA) inventories AI assets, the starting point for AI Act classification.
2. AI Gateway (GA) evaluates the prompts, responses and tool calls you route through it against guardrails for prompt injection, jailbreak and PII egress, and records guardrail events you can review.
3. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) records which agent holds what access, at what level.

Step 10: Choose a deployment that matches your residency rules (GA)

Safeguard's SaaS runs in US, EU and Gov regions; there is no Poland-specific region. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. Where data must stay under your control, the GA options are private VPC or dedicated tenancy; full on-prem; fully air-gapped, with the AI models running inside your environment and signed offline snapshot delivery; the local runner, where the CLI scans on your machine and sends only encrypted results, so source code never leaves your environment; and Zero AI mode, with no language model in the loop, or bring your own approved model. Safeguard states that customer code, SBOMs and telemetry are not used to train shared models. Its posture wording is limited to SOC 2 Type II audit in progress and designed for FedRAMP High.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It is not a supervisor, auditor or CSIRT. It does not register you, file Article 11 reports, report to the KNF or notify UODO, and it does not perform your Article 15 audit. It can supply evidence to your auditor.
• It holds no Polish certification. Safeguard is not certified under Poland's national cybersecurity certification system and is not on any government framework or list. It helps you produce the evidence the rules ask for.
• It does not host in Poland. SaaS regions are US, EU and Gov. If you need control over where data sits, use private VPC, on-prem, air-gapped deployment, the local runner or Zero AI mode. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU.
• It does not decide high-risk vendor questions. Article 67b decisions are the Minister's. Safeguard helps you see which products and services a decision would touch.
• It does not classify your AI systems. AI-BOM discovery gives you the inventory; whether a system is high-risk under the AI Act is a legal judgment for you and counsel.
• It does not fix software you do not build. When the vulnerable code sits in a vendor appliance, a hosted service or a closed-source product, the fix has to come from that vendor.

Common mistakes

• Assuming the old operator list still defines scope. The amendment moved to self-identification. Many organisations that were never operators of essential services are now key or important entities.
• Treating the registration deadline as the finish line. 3 October 2026 was the registration window. The security duties are due by 3 April 2027, and the first audit for key entities by 3 April 2028.
• Leaving the board out. Article 8c makes the head of the entity responsible, with personal fines under Article 73a. A plan without minuted board approval and a training record is incomplete.
• Forgetting the criminal record check. Article 8f applies before staff start Article 8 or Article 11 tasks, including contractors doing that work.
• Running separate inventories for the KSC Act, the CRA and DORA.
• Ignoring the high-risk vendor procedure until a decision lands. By then you have to find every affected product under time pressure.
• Blocking everything on day one. Start gates on warnings, clear the backlog, then move the clearest rules to blocking.

FAQ

Has Poland transposed NIS2?

Yes. The Act of 23 January 2026 amending the Act on the National Cybersecurity System was published as Journal of Laws 2026, item 252, on 2 March 2026 and entered into force on 3 April 2026.

What is the deadline for NIS2 compliance in Poland?

Entities in scope on 3 April 2026 must meet the Chapter 3 duties, including the Article 8 security management system and the incident rules, within 12 months, by 3 April 2027. Key entities must complete their first security audit by 3 April 2028.

What are the incident reporting deadlines under the KSC Act?

An early warning to the competent sector CSIRT within 24 hours of detecting a serious incident, the incident notification within 72 hours, and a final report within one month of the notification. Trust service providers report within 24 hours.

Who supervises cybersecurity in Poland?

The Minister of Digital Affairs keeps the register; sector authorities supervise their sectors; CSIRT NASK (CERT Polska), CSIRT GOV and CSIRT MON are the national CSIRTs; sector CSIRTs receive incident reports.

Does the KSC Act apply to Polish banks?

Partly. Article 8i defers to DORA for their security management and incident reporting, but keeps registration, management duties and the high-risk vendor rules, among others. The KNF is the DORA competent authority.

What is a high-risk vendor in Poland?

A supplier of hardware or software that the Minister of Digital Affairs recognises as such by decision under Article 67b. Entities concerned must stop deploying the covered products and withdraw them within seven years, or four years for telecoms critical functions.

What are the fines under the amended KSC Act?

Up to EUR 10 million or 2% of revenue for key entities, and up to EUR 7 million or 1.4% for important entities. The head of the entity can be fined up to 300% of remuneration.

Who supervises the AI Act in Poland?

The Commission for the Development and Security of Artificial Intelligence, under the Act of 3 July 2026 on artificial intelligence systems, which entered into force on 11 August 2026.

Does the KSC Act require an SBOM?

It does not use the word. It requires asset management, supply chain security and vulnerability handling, and an SBOM is the most direct evidence for all three. The CRA does require one for products with digital elements.

Every Polish duty in this guide comes back to one moment: a component turns out to be vulnerable, and you need to know where it runs and how fast you can fix it. The block below describes the three ways Safeguard closes that gap for the open source you build and ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner. You set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a Polish team whose source code must stay on its own systems, this is the flow that produces SBOMs and findings without handing over the repository.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow is how a team acts promptly on a vulnerability under Article 8(1)(5)(d) while keeping a human in charge.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. GRC and security teams can then ask questions of their SBOM and findings data from an assistant they already use, with access limited to the tools they approved.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Sejm ELI record: Act of 23 January 2026 amending the KSC Act, Journal of Laws 2026, item 252
• Journal of Laws 2026, item 252, published text (PDF)
• Sejm ELI record: consolidated text of the KSC Act, Journal of Laws 2026, item 20
• Minister of Digital Affairs: communication of 8 April 2026 on the registration schedule (PDF)
• Ministry of Digital Affairs
• Sejm ELI record: Act of 25 June 2025 on the national cybersecurity certification system
• Sejm ELI record: Act of 3 July 2026 on artificial intelligence systems, Journal of Laws 2026, item 1003
• Act of 3 July 2026 on artificial intelligence systems, published text (PDF)
• KNF: the DORA Regulation
• CERT Polska
• CERT Polska: energy sector incident report, 30 January 2026
• CERT Polska: annual report 2025, 8 April 2026
• UODO (Personal Data Protection Office)
• European Commission: Cyber Resilience Act
• European Commission: AI Act regulatory framework
• Safeguard docs: Poland KSC Act
• Safeguard docs: EU NIS2 Directive
• Safeguard docs: EU DORA
• Safeguard docs: EU Cyber Resilience Act
• Safeguard docs: CLI usage
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Package Firewall
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: AI Gateway
• Safeguard docs: Attestation and Signing
• Safeguard docs: Trust Center setup
• Safeguard docs: Air-Gapped Deployment

Related reading: Poland energy sector wiper attacks, December 2025.

Try it yourself: download Safeguard or read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.