Finland's Cybersecurity Act: where penetration testing actually helps

Finland's Cybersecurity Act (kyberturvallisuuslaki) entered into force on 8 April 2025, making Finland one of the earlier member states to transpose NIS2. Supervision is distributed across sector authorities, with Traficom's National Cyber Security Centre holding a central coordinating and CSIRT role.

The Finnish context that changes testing priorities

Two structural facts about Finnish enterprise IT matter for how you scope. Enterprise AI adoption is among the highest in the EU, well above the union average — which means a meaningful amount of business data is already flowing through language-model interfaces that were procured by teams rather than by IT. And Finnish industrial and energy sectors carry significant OT estates where the availability constraint genuinely limits what can be tested and how.

Both push against the standard annual-external-pentest template. One introduces a data-flow risk that a network test cannot see. The other makes aggressive testing inappropriate for the highest-consequence systems.

Priority one: identity and the paths into OT

Where an organisation runs both IT and OT, the finding that matters most is rarely inside the OT network. It is the path from a compromised office workstation to an engineering workstation to the control network — jump hosts with shared credentials, remote-access appliances for vendor maintenance, flat management VLANs, and domain trust that spans the boundary.

That path can be tested safely because it lives in IT. You do not need to touch a PLC to prove that reaching one is possible. Scope the test to stop at a documented boundary, and record the reached position as the finding. This gives you defensible evidence without accepting availability risk.

Priority two: the AI surface nobody scoped

In a high-AI-adoption market, the realistic question is not whether staff use language models with company data — it is which ones, holding what, under whose terms. This is squarely a NIS2 concern: it touches data handling, supply chain, and access control simultaneously, and it is usually invisible to the security function.

• Which model providers receive traffic from your networks and managed devices, and under which contracts?
• Which AI features are enabled by default in SaaS you already licence, and what data do they process?
• Which internal applications call an external model API, and what do they send in the prompt?
• Where do model-generated outputs flow back into systems that act on them without a human check?
• Is any of this logged in a way that would let you answer an incident question about it?

Answering those five questions is cheap and usually produces more risk reduction per hour than another perimeter scan. It is also the kind of finding a supervisory authority is increasingly likely to ask about.

Priority three: detection, measured rather than assumed

The pattern in that table is not incompetence. It is drift. Controls are configured correctly and then reality moves — a log source is retired, an exemption is added for a migration, a rule is muted during a noisy week and never restored. The only reliable way to find drift is to trigger the control and watch what happens.

A first-year plan for a Traficom-supervised entity

1. Confirm classification and registration with your sector supervisory authority.
2. Run an authenticated internal assessment focused on identity and, where relevant, IT-to-OT reachability with a hard boundary agreed in writing.
3. Complete an AI and third-party data-flow inventory. Revoke what has no owner.
4. Remediate on a stated window, then retest everything high or critical and keep both dated reports.
5. Run one timed incident exercise producing an awareness-to-notification record against the 24-hour early warning obligation.
6. Put the results, not the plan, in front of the management body for approval.