Poland’s KSC Act Is Now in Force: Why NIS2 Compliance Starts with Infrastructure Automation

Poland’s implementation of the EU’s NIS2 Directive marks a decisive shift in how organisations think about cybersecurity, resilience, and operational risk. With amendments to the Act on the National Cybersecurity System (KSC Act) entering into force on 3 April 2026, enforcement expectations are now real, national, and significantly stricter than many organisations anticipated – including obligations for security controls, incident response, and supply‑chain governance. 

For IT and security leaders, this is not just another compliance exercise. Poland’s KSC Act pulls infrastructure operations, automation, and tooling decisions directly into scope. How systems are configured, how drift is handled, and how changes are governed now require repeatable evidence and demonstrated control. 

From 400 Organisations to 42,000 — Overnight 

Under the previous KSC framework, roughly 400 organisations were regulated. The amended Act expands that scope dramatically — bringing an estimated 42,000 organisations into scope across 18 sectors, including energy, transport, banking, healthcare, digital infrastructure, manufacturing, and public administration. 

In several areas, Poland has deliberately gone further than NIS2 itself. The energy sector, for example, now explicitly includes coal mining and fuel production, categories not clearly elevated in the directive. 

If your organisation previously assumed it was out of scope, that assumption is now risky. 

What are the KSC Act deadlines? 

The KSC Act does not require everything at once, but the timeline is tighter than it appears: 

• 3 October 2026: Essential and important entities must register in the national register. Failing to register does not remove obligations, it adds an additional violation. 
• 3 April 2027: Full implementation required, including an operating ISMS, incident response procedures, risk management controls, and supply chain security policies aligned with NIS2. 
• 3 April 2028: Mandatory cybersecurity audits begin for essential entities, and financial penalties activate in earnest. 

For organisations that have not yet assessed scope, tooling, or operational readiness, October 2026 is closer than it looks. 

What Penalties in the KSC Act Go Beyond NIS2? 

NIS2 sets a maximum penalty of €10 million or 2 percent of global annual turnover for essential entities. Poland has chosen to raise the stakes. 

Under the KSC Act, regulators can impose fines of up to PLN 100 million (approximately €24 million), with additional daily penalties of up to PLN 100,000 for ongoing non‑compliance. 

More significantly, the Act introduces personal liability for board members in cases of gross negligence. This shifts cybersecurity investment discussions from a technical debate to a board‑level risk conversation, where infrastructure reality, not policy intent, will be scrutinised. 

Poland’s Biggest Departure: the High‑Risk Vendor Framework 

The most operationally disruptive element of Poland’s KSC Act is also the least understood: the High‑Risk Vendor (HRV) framework. 

Unlike most NIS2 implementations, which emphasise supply chain risk assessments and contractual controls, Poland enables regulators to formally designate specific ICT vendors as high risk. Once designated, regulated organisations must remove and replace those vendors’ products and services within a defined timeframe and at their own cost. 

This mechanism applies across all sectors, not just telecommunications. Any vendor with meaningful links to non‑EU, non‑NATO states becomes a potential HRV candidate. 

For infrastructure leaders, this changes the equation. Vendor provenance, accountability, and long‑term viability are now compliance considerations, not future procurement discussions. 

Why Infrastructure Automation is Now a Compliance Issue 

Many organisations evolved their automation stacks organically: scripts, community tools, and manual processes that broadly work. Under the KSC Act, that approach carries measurable risk. 

Auditors and regulators will look for evidence that: 

• Security policies are enforced consistently, not selectively. 
• Changes are traceable. Who changed what, when, and why. 
• Configuration drift is detected and corrected continuously. 
• Tooling is supported, maintained, and backed by clear vendor accountability. 

The KSC Act raises the bar from best‑effort security to provable security. If you cannot demonstrate control in practice, written policies offer little protection. 

The HRV framework adds further pressure. Tools with opaque supply chains or unclear ownership now expose organisations to forced, time‑pressured replacement. 

Why Unmanaged and Unsupported Tooling Is Hard to Defend 

Open source tools remain valuable, but NIS2, and particularly Poland’s implementation, changes the risk calculation. 

Infrastructure leaders are now being asked harder questions: 

• Accountability and remediation: When a critical vulnerability is disclosed, who is accountable, and how quickly can it be patched in a way that is documented and auditor‑defensible? 
• Evidence and auditability: Can you produce compliance evidence on demand—without manually reconstructing logs, reports, or change histories? 
• Visibility and inventory: Do you have a complete, current inventory of all systems in scope, including the present configuration state of each? 
• Drift and change control: How do you detect configuration drift, how quickly is it corrected, and can you show who made the last change and when? 

Community maintained tools without guaranteed remediation timelines or formal accountability are increasingly difficult to justify under Poland’s regulatory expectations. 

How Does Puppet Directly Support KSC Act Obligations? 

Puppet was built for environments where consistency, governance, and auditability matter. 

• Continuous Enforcement: Puppet checks system configuration every 30 minutes and automatically remediates drift, ensuring declared policies remain enforced without relying on manual intervention. 
• Audit‑Ready Evidence: Every change, correction, and enforcement action is logged, creating a continuously updated compliance record that stands up to regulatory and audit scrutiny. 
• Vendor‑backed security: Puppet provides hardened, signed builds with SLA‑backed CVE remediation, meeting the KSC Act’s requirements for secure, well‑maintained systems. 
• Edge and network coverage: Puppet Edge extends the same policy‑driven control model to firewalls, switches, and edge infrastructure that cannot host an agent, closing visibility gaps that auditors increasingly target. 

For organisations navigating Poland’s HRV framework, Puppet’s transparent provenance, EU‑aligned operations, and commercial support model provide a defensible alternative to unmanaged or high‑risk tooling. 

Why Acting Now Matters 

Organisations that act now retain control. They can assess scope, modernise automation, and build defensible compliance records methodically. 

Those that wait until the April 2027 implementation deadline - or worse, the April 2028 audit cycle - will be forced to make tooling and architecture decisions under regulatory pressure, with fewer options and higher risk. 

October 2026 is the first real test of readiness. The gap between now and then is shorter than it appears. 

NIS2 is ultimately about resilience. Reviewing infrastructure automation today is one of the most effective steps Polish organisations can take to ensure they are ready for what comes next. 

Explore Puppet Enterprise Get a Demo