A new cybersecurity law. Industrial automation under scrutiny. Accountability now rests with the board

From April 2026, responsibility for the security of control systems – in ports, shipyards, terminals and at offshore wind farms – no longer stops at the IT department. Poland's overhaul of its National Cybersecurity System Act (KSC), transposing the EU's NIS2 Directive, shifts both the obligations and the penalties onto company boards. For a maritime sector built on sprawling operational technology (OT), it is a strategic shift – all the more so because, at the turn of 2025 and 2026, Poland suffered a documented, destructive attack on its energy infrastructure.

security business work at mare law and taxes equipment and technology news

09 june 2026   |   21:35   |   Source: Gazeta Morska   |   Prepared by: Kamil Kusier   |   Print

fot. materiały prasowe

The new regime is already in force

On 3 April 2026, the amended National Cybersecurity System Act entered into force, transposing the NIS2 Directive into Polish law. It replaced the previous model of "operators of essential services" and "digital service providers" with two new categories: essential entities and important entities. Membership is determined by sector and size criteria – and the catalogue of covered industries includes energy, transport (maritime and ports among them), water supply and wastewater, healthcare, digital infrastructure and selected types of industrial production.

Crucially, the law introduces a duty of self-identification: it is not a regulator but the organisation itself that must assess whether it falls under the rules, and in which category. Self-registration in the KSC register, maintained in the S46 system, opened on 7 May 2026, with the filing deadline set for 3 October 2026. Missing it means failing a statutory obligation – with the risk of sanctions and loss of eligibility for public contracts.

The calendar does not end there. Entities that already meet the criteria on the day the law took effect have until 3 April 2027 to implement an information security management system and fully connect to S46, while new essential entities must complete their first mandatory audit by 3 April 2028.

Poland is not an isolated case. Every EU member state is transposing NIS2, so operators across the bloc face equivalent obligations – Poland simply happens to be among the jurisdictions with a hard, dated regime already running.

The end of "that's IT's problem"

The deepest change is not the list of obligations but who answers for them. The law moves responsibility off the shoulders of administrators and automation engineers and onto management bodies. It is the board that approves risk-management measures, oversees their implementation and may bear personal consequences for breaches – including a statutory obligation to train senior management.

Weight is added by financial sanctions that rank among the strictest in the EU. For essential entities, the administrative penalty reaches EUR 10 million or 2 percent of annual turnover; for important entities, EUR 7 million or 1.4 percent. The transition period should not be mistaken for a period of inactivity: the implementation clocks are already running.

Incident reporting within 24 hours

The new regime imposes a rigorous reporting framework. An early warning must be sent within 24 hours, a full incident notification within 72 hours, and a final report broadly within a month. Reports go to the relevant CSIRT team (NASK, GOV or MON) through the S46 system.

In practice this creates a new information dynamic. Under time pressure, word of a PLC failure or suspicious traffic on a SCADA network may reach the state CSIRT before a full report reaches the board. Without effective internal escalation procedures, management exposes itself to a chronic risk of being blindsided – a situation in which the supervisory body is already running a case while the board is only just learning of the incident.

The threat is not hypothetical

That this is no regulatory drill was shown at the close of 2025. On 29 December 2025, a coordinated, destructive cyberattack struck Poland's energy sector. According to the CERT Polska report published on 30 January 2026, the targets included at least 30 wind and photovoltaic farms, a large combined heat and power plant supplying heat to nearly half a million customers, and a manufacturing company.

The attack was purely destructive – not financially motivated. The attackers gained access through vulnerable, internet-facing edge devices (including VPN concentrators without multi-factor authentication), exploited default accounts and passwords in automation devices, and then deployed wiper malware that destroyed data and disrupted industrial equipment. Classic OT components were hit: RTU controllers, local HMI panels and protection relays. CERT Polska noted that the infrastructure and tradecraft overlapped with clusters (Static Tundra / Berserk Bear, Dragonfly, Ghost Blizzard) associated with Russian state-linked actors.

The case crossed Poland's borders. On 10–11 February 2026, the US agency CISA issued an alert to critical-infrastructure operators intended – in its own words – to "amplify" the CERT Polska report and draw attention to threats to OT/ICS environments, in particular the risk posed by insecure edge devices. The Polish incident thereby became a warning to infrastructure operators in allied states.

The maritime sector is in scope

For the maritime industry the relevance is direct: shipping and ports form one of the densest OT ecosystems there is. Port terminals run cranes, terminal operating systems and cargo-handling automation; shipyards and industrial plants depend on control networks; and the growing Baltic offshore wind sector is precisely this class of infrastructure – substations, telecontrol, remote monitoring – the very kind that came under fire in December 2025. That attack hit onshore installations, but the risk vectors (edge devices, missing MFA, default passwords, weak IT/OT segmentation) are identical in a maritime setting.

Where service delivery depends on OT/ICS, both risk assessment and audit should extend to those environments. In practice, IT/OT network segmentation is one of the baseline measures arising from that assessment – alongside an information security management system and incident-response procedures.

The weakest link: the skills gap

The single largest risk factor in many organisations remains the divide between IT and automation expertise. An IT specialist rarely knows industrial protocols (Modbus, DNP3, Profinet); an automation engineer rarely thinks in terms of threat models. Conventional IT training does not close that gap – what is needed are programmes dedicated to the OT environment, bridging the realities of automation with the requirements of NIS2, the IEC 62443 standard and the KSC amendment.

A market response: ASE Security Academy and Enterosoft

Meeting the new requirements is the Security Academy (Akademia Bezpieczeństwa) of the ASE Technology Group, together with Enterosoft. They offer a proprietary, hands-on training programme dedicated to OT/IT environments – aimed simultaneously at the automation engineers and administrators who work day to day with SCADA, PLC and DCS systems and industrial networks. The programme connects the world of automation with the requirements of NIS2, the IEC 62443 standard and the KSC amendment. Beyond training, the Academy delivers OT security audits and implementations – from network segmentation to full incident-management systems compliant with the CSIRT/S46 regime. It is the kind of support that lets an organisation move from a reactive, post-incident posture to one of documented compliance and genuine resilience.

• Online training series "Cyberbezpieczeństwo OT w praktyce" (OT Cybersecurity in Practice): click here.
• Registration: szkolenia@ase.com.pl.
• Contact: Grzegorz Kulczykowski, tel. +48 601 480 291.

Buy us a coffee, and we’ll invest in great maritime journalism! Support Gazeta Morska and help us sail forward – click here!

cyberbezpieczeństwo OT NIS2 Enterosoft nowelizacja ustawy KSC bezpieczeństwo SCADA

comments

---

enter content

COMMENT

nick

Add the first comment