Finland software supply chain and AI security rules: a 90-day plan

If you build, buy or run software in Finland, the Cybersecurity Act (kyberturvallisuuslaki, 124/2025) has applied since 8 April 2025, its risk management model was due by 8 July 2025, and every significant incident needs an early warning to your sector supervisor within 24 hours. Public bodies carry the same duties through a new chapter 4a of the Act on Information Management in Public Administration (906/2019). On top of that sit DORA for financial firms supervised by the Financial Supervisory Authority (FIN-FSA), the Act on the Supervision of Certain Artificial Intelligence Systems (1377/2025) in force since 1 January 2026, GDPR enforcement by the Data Protection Ombudsman, and the EU Cyber Resilience Act for anyone who makes products with digital elements.

This guide takes each regime from its primary source, names the supervisor, lists what it asks of software and open source, and ends with a 30/60/90-day plan that works with any tooling. It is a practical reading of public texts, not legal advice.

Key takeaways

• Finland's NIS2 law is in force. The Cybersecurity Act (124/2025) applies from 8 April 2025, with registration due by 8 May 2025 and a risk management model by 8 July 2025. Section 9 includes supply chain security and secure acquisition, development and maintenance.
• Reporting clocks are 24 hours, 72 hours and one month from detecting a significant incident (sections 11 to 13).
• Supervision is split by sector under section 26, with Traficom's National Cyber Security Centre Finland (NCSC-FI) as single point of contact and CSIRT.
• Penalties reach EUR 10 million or 2 percent of worldwide turnover for essential entities (section 38).
• Public bodies are covered through chapter 4a of the Information Management Act, with no transition period.
• Finance runs on DORA, supervised by FIN-FSA since 17 January 2025.
• AI supervision is decentralised. Under 1377/2025, Traficom coordinates and supervises the transparency duties in force since 2 August 2026.
• Makers face the CRA clock now: reporting since 11 September 2026, full obligations from 11 December 2027.
• Safeguard capabilities in this guide are all generally available (GA): SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV context, reachability analysis, policies and gates, the Compliance and GRC suite, TPRM, CSAF and VEX upload, license compliance, autonomous remediation (ships switched off), Package Firewall, AI-BOM discovery, AI Gateway, MCP Guardrail, agent identity, Trust Center, the local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

Who this applies to in Finland

Finland's rules reach five broad groups, and many organisations sit in more than one.

Essential and important entities under the Cybersecurity Act. Section 3 of the Act brings in medium and large organisations in the sectors listed in its Annexes I and II, which follow the NIS2 Directive, from energy, transport, health, water and digital infrastructure to managed service providers, manufacturing and research. Some, such as DNS service providers, top-level domain registries and qualified trust service providers, are in scope regardless of size. Entities designated as critical under Finland's critical infrastructure resilience law also fall under the Act.

Public administration. Public administration entities in scope carry the NIS2 duties through chapter 4a of the Act on Information Management in Public Administration (laki julkisen hallinnon tiedonhallinnasta, 906/2019, usually called tiedonhallintalaki). Traficom supervises public administration for cybersecurity.

Financial entities. Banks, insurers, investment firms, payment and e-money institutions, fund managers and the other entity types listed in DORA Article 2 follow DORA, supervised in Finland by FIN-FSA (Finanssivalvonta).

Suppliers to all of the above. Section 9 makes supply chain security mandatory for every in-scope entity, so vendors, SaaS providers and integrators selling to them will be asked for evidence even when not in scope themselves.

Makers and AI providers. Finnish software and device makers are manufacturers under the Cyber Resilience Act, and AI providers and deployers fall under the AI Act and 1377/2025.

The rules, regulator by regulator

Every status below was checked on 25 October 2026 against Finlex, Traficom, FIN-FSA or the European Commission. EU article references that we could not load from EUR-Lex are noted at the end.

The Cybersecurity Act (kyberturvallisuuslaki, 124/2025): Finland's NIS2 law

Traficom's announcement says Parliament passed the Act to implement the NIS2 Directive and that the obligations entered into force on 8 April 2025. Finlex shows the consolidated text with later amendments in 2025 and 2026, including changes to the list of supervisors that take effect on 1 January 2027.

The Act has 47 sections in six chapters: scope and definitions, risk management and incident reporting (sections 7 to 18), the CSIRT and coordinated vulnerability disclosure (sections 19 to 25), supervision (sections 26 to 34), penalty payments (sections 35 to 40) and other provisions. Section 4 leaves out activity carried out solely for national defence, national security, public order or law enforcement.

The risk management model (section 8). Every entity must keep an up-to-date risk management model that identifies risks to its networks, information systems and their physical environment using an all-hazards approach, and that sets objectives, procedures, responsibilities and the measures from section 9.

The minimum measures (section 9). The model and its controls must take into account and keep up to date at least a list of areas set out in section 9(2). Among them:

• policies for cybersecurity risk management and assessment of how well the controls work;
• security policies for networks and information systems;
• security in acquiring, developing and maintaining networks and information systems, including procedures for handling and disclosing vulnerabilities;
• the overall quality and resilience of products and services from direct suppliers in the supply chain, the controls built into them, and those suppliers' cybersecurity practices;
• asset management and identification of functions important to security;
• personnel security and cybersecurity training;
• access control and authentication;
• policies on cryptography and, where needed, secure electronic communications;
• backups, recovery planning, crisis management and other business continuity, with secured emergency communications where needed;
• basic security practices for operations, telecommunications, hardware and software security and data security;
• physical and environmental security and securing essential resources.

The measures must be proportionate to the entity's size, exposure and risks. Section 9 also lets each supervisor issue technical regulations for its sector, and the Act requires entities to follow the Commission's implementing acts under NIS2 Article 21(5). For digital infrastructure and digital service providers, that is Implementing Regulation (EU) 2024/2690, which Traficom points to directly.

Management responsibility (section 10). The Act defines management as the board, supervisory board and managing director, and anyone in a comparable position who actually runs the organisation.

Incident reporting (sections 11 to 14). A significant incident is one that has caused or can cause a serious disruption to services or substantial financial loss to the entity, or that has affected or can affect other people by causing considerable material or non-material damage. The clocks:

Reports go to the entity's own sector supervisor, which passes them to the CSIRT. Traficom's guidance gives an online NIS2 incident notification form. Under section 17, if the incident involves a personal data breach that must be notified under GDPR Article 33, the supervisor informs the Data Protection Ombudsman; that does not replace the controller's own Article 33 notification.

Penalties (sections 35 to 38). Administrative penalty payments are imposed by a sanctions board on the supervisor's proposal. The maximum is EUR 10,000,000 or 2 percent of the previous financial year's worldwide turnover for an essential entity, and EUR 7,000,000 or 1.4 percent for an important entity, whichever is higher.

Registration (section 41). Entities had to register with each relevant supervisor within one month, which Traficom put at 8 May 2025.

Who supervises: Traficom, the NCSC-FI and the sector authorities

Section 26 divides supervision by sector. Traficom supervises the sectors in Annex I points 1 to 7 and Annex II points 1 to 5 of the Finnish Act; its news release says that includes postal and courier services, space, public administration, managed service providers, managed security service providers, research and the manufacture of vehicles and other transport equipment, on top of the transport and communications sectors it already supervised under the old NIS rules. The other supervisors named in section 26 include the Energy Authority (Energiavirasto), the Finnish Safety and Chemicals Agency (Turvallisuus- ja kemikaalivirasto, Tukes), the Permit and Supervision Agency (Lupa- ja valvontavirasto), the regional Elinvoimakeskus, the Food Authority (Ruokavirasto) and the Finnish Medicines Agency (Fimea). An amendment that takes effect on 1 January 2027 adds the Radiation and Nuclear Safety Authority (Säteilyturvakeskus, STUK) for holders of a nuclear facility operating licence.

The NCSC-FI (Kyberturvallisuuskeskus) at Traficom is the single point of contact under NIS2 Article 8(3) and hosts the CSIRT. Traficom stresses that the CSIRT does not supervise anyone and that voluntarily disclosed information cannot be used against the notifier without consent. Mandatory reports go to your supervisor; the CSIRT gives technical help.

The Information Management Act (906/2019): public administration

Traficom's announcement is explicit that, for public administration, the NIS2 requirements are laid down in the Act on Information Management in Public Administration, amended by Act 125/2025. The new chapter 4a, "Cybersecurity obligations and supervision of compliance", runs from section 18a (classification of entities and notification of activity) through section 18b (duty to manage cybersecurity risks and the risk management model), section 18c (risk management measures), section 18d (duty to report significant incidents), section 18e (receiving incident reports), section 18f (voluntary reporting) and section 18g (informing others of significant cyber threats and incidents). Traficom notes that public administration entities did not get a transition period: the risk management obligation applied from 8 April 2025.

Chapter 4 of the same Act already required authorities to secure data and information systems (section 13), manage access rights (section 16), collect log data (section 17) and, in state administration, security classify documents (section 18). Suppliers see these as contract requirements.

DORA and FIN-FSA (banks, insurers, payment firms, investment firms)

DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 and is directly applicable in Finland. FIN-FSA supervises Finnish financial entities. Its reporting release 11/2025 set out the first collection of the register of information on ICT third-party arrangements: a reference date of 31 March 2025, submission through FIN-FSA's reporting service using the Suomi.fi mandate specifier "DORA", and a deadline of 26 May 2025. Check FIN-FSA's reporting releases for the current cycle's dates.

From our reading of the regulation (EUR-Lex did not load for us on 25 October 2026), the DORA articles that touch software and open source most directly are Article 8 (identification of ICT assets and their dependencies), Article 9 (protection and prevention, including patch management), Article 19 (major ICT-related incident reporting), Article 28 (ICT third-party risk and the register of information) and Article 30 (key contractual provisions). Under NIS2's rule on sector-specific acts, DORA's ICT risk management and incident reporting duties apply to the financial entities it covers in place of the general NIS2 duties, and the supervisors listed in section 26 of the Cybersecurity Act do not include FIN-FSA.

The Data Protection Ombudsman and the GDPR

The Data Protection Ombudsman (tietosuojavaltuutettu) supervises the GDPR and the Data Protection Act (1050/2018). For software teams, the articles that bite are Article 25 (data protection by design), Article 28 (processors), Article 32 (security of processing) and Article 33 (breach notification within 72 hours where feasible). The Cybersecurity Act links the two regimes: section 17 has the supervisor notify the Ombudsman when a significant incident involves a notifiable personal data breach, and section 33 deals with notifying the Ombudsman in supervision cases.

The EU Cyber Resilience Act for Finnish makers

The European Commission's CRA page confirms that the regulation entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026 and that the main obligations apply from 11 December 2027. From our reading of Regulation (EU) 2024/2847 (EUR-Lex did not load for us), Article 14 requires a manufacturer to notify an actively exploited vulnerability with an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a corrective measure being available, and to report severe incidents on a 24 hour, 72 hour and one month pattern, through ENISA's single reporting platform to the CSIRT designated as coordinator. Annex I Part II sets the vulnerability handling requirements that apply from December 2027, including drawing up a software bill of materials covering at least the top-level dependencies. Section 22 of the Cybersecurity Act already gives Traficom's CSIRT its coordinated vulnerability disclosure role in Finland.

The EU AI Act and Finland's supervision law (1377/2025)

The Commission's AI Act page sets the current timeline after the AI Omnibus, which entered into force on 27 July 2026. Prohibitions and AI literacy have applied since 2 February 2025, general purpose AI model obligations since 2 August 2025, and most of the Act since 2 August 2026. High-risk rules for Annex III use cases (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and justice) apply from 2 December 2027, and for AI embedded in Annex I products from 2 August 2028.

Finland's Act on the Supervision of Certain Artificial Intelligence Systems (laki eräiden tekoälyjärjestelmien valvonnasta, 1377/2025) entered into force on 1 January 2026. It spreads supervision across existing authorities. Traficom is the single point of contact under AI Act Article 70(2) and supervises the Article 50 transparency obligations. The Data Protection Ombudsman covers several Annex III areas. FIN-FSA covers high-risk AI used by the financial entities it supervises, and sector authorities such as the Energy Authority, Tukes and Fimea cover AI safety components in their fields. A sanctions board connected to Traficom imposes administrative fines.

Traficom's guidance says providers must tell people when they are talking to an AI system and make generated content detectable, and deployers must disclose deep fakes. Systems placed on the market before 2 August 2026 have until 2 December 2026 for machine-readable marking.

What the rules ask of software and open source

The Finnish rules rarely say "SBOM", but section 9's asset management, maintenance, vulnerability handling and supplier duties cannot be shown for software without one. The CRA makes it explicit for makers from December 2027.

Each requirement maps to the evidence a supervisor, auditor or customer usually asks for.

A few practical points sit behind that table.

Supplier evidence is now normal. Because section 9 covers direct suppliers' products and practices, expect SBOM delivery, vulnerability notification windows and audit rights in contracts.

Disclosure needs a contact. Coordinated vulnerability disclosure under section 22 and the CRA both assume researchers can reach you. A published security contact and a working intake process are the minimum.

Residency is a design choice, not a slogan. The useful question is where source code, SBOMs and findings are processed, and who can reach them.

Real public incidents in or affecting Finland

These are drawn from official releases. We report only what the sources state.

City of Helsinki Education Division data breach (April 2024). The City of Helsinki became aware of a breach on 30 April 2024 and issued a notice on 2 May 2024. In its 13 May 2024 update, the city said the attacker reached the Education Division network through a vulnerability in a remote access server, that a hotfix patch had been available but had not been installed, and that its "security update and device maintenance controls and procedures have been insufficient". The attacker obtained the usernames and email addresses of all city staff, the personal identity codes and addresses of students, guardians and Education Division staff, and content from network drives holding tens of millions of files, some containing sensitive personal data. The city notified the Data Protection Ombudsman, the police and the NCSC-FI. On 13 March 2025 the city reported that the National Bureau of Investigation had opened a preliminary investigation into whether a data protection offence had occurred. A Government-appointed safety investigation led by the Safety Investigation Authority (Otkes) delivered its report on 17 June 2025 with four recommendations, covering communication guidance, the coordination, supervision and guidance of information management, and better detection and correction of security weaknesses in public administration.

The city's own lesson concerns patch and maintenance controls on internet-facing systems, the same ground section 9 covers.

Tietoevry ransomware attack (January 2024). Tietoevry, an IT services group headquartered in Espoo, said a ransomware attack hit part of one of its data centres in Sweden on the night of 19 to 20 January 2024. It said a new recovery platform was built within 24 hours, more than 90 percent of servers were restored from backups within four days, and nearly all customer services were fully restored by mid-March. It shows how an incident at one service provider becomes a supply chain incident for every customer in that data centre.

The personas who own the problem

The CISO. Owns the risk management model and the incident clock. Needs an approved model, a rule for "significant", and a 24 hour answer on which services and versions are affected. Trigger: an incident, a supervisor's information request under section 28, or a security audit ordered under section 30.

The head of AppSec or product security. Owns section 9's development and vulnerability handling duties and, for makers, CRA Article 14. Needs a complete component inventory, fast exploitability triage and fixes that beat disclosure deadlines. Trigger: an actively exploited vulnerability in a dependency, a customer's SBOM request, or CRA reporting since 11 September 2026.

The VP or director of engineering. Owns delivery. Needs one process that meets NIS2, DORA and CRA demands without parallel workflows. Trigger: a large customer's security schedule.

The GRC or compliance lead. Owns evidence. Needs each section mapped to a control, owner and record. Trigger: registration, the annual review of the model, a FIN-FSA register submission, or an audit.

Procurement and vendor risk. Owns supplier security under section 9 and DORA Article 28. Needs a critical supplier list and a standard evidence request. Trigger: contract renewal, a DORA register submission or a supplier's incident.

The Data Protection Officer. Owns GDPR Article 32 and 33. Needs to know within hours whether a security incident is also a personal data breach and which systems process personal data. Trigger: any significant incident.

The public sector information management lead. Owns chapters 4 and 4a of the Information Management Act. Needs log data, access control, maintenance records and supplier evidence for every system. Trigger: Traficom supervision, a procurement, or an incident like Helsinki's.

A practical 30/60/90-day plan

This plan works with any tooling. It assumes you are in scope of the Cybersecurity Act or the Information Management Act, or you sell to someone who is, and that some of the earlier deadlines have already passed.

Days 1 to 30: scope, inventory and ownership

1. Confirm your status. Check whether you are essential or important under section 3, which supervisor applies under section 26, whether you registered, and whether DORA, the CRA or the AI Act also apply.
2. Re-read your risk management model against section 9. List every section 9 area and note, for each, the control, the owner and the evidence. Gaps in supply chain and in development and maintenance are the usual ones.
3. Build the software inventory. For each in-house application and each critical third-party product, record the components and versions. Generate SBOMs in SPDX or CycloneDX for what you build.
4. Map internet-facing systems. VPN gateways and remote access servers first, with patch status and owner for each.
5. Write the incident clock down. A one-page runbook: what counts as significant under section 11, who decides, who files the early warning and through which channel, and how the DPO is involved.

Checklist for day 30:

Days 31 to 60: vulnerability handling and suppliers

1. Set triage rules. Rank vulnerabilities by severity, known exploitation (for example CISA's KEV catalogue), exploit prediction scores and reachability. Write fix windows down and measure them.
2. Gate releases. Add a check in CI that stops releases with known exploited or critical vulnerabilities, with a documented exception path that records who approved what and until when.
3. Publish a disclosure contact. A security contact on your site and in product documentation, routed to a team that answers.
4. Classify suppliers. Mark critical ICT suppliers and request a questionnaire, an SBOM, vulnerability notification terms and an incident contact from each.
5. Prepare DORA artefacts if you are a financial entity. Reconcile the register of information with your actual contracts and check that Article 30 clauses are present.
6. Practise a 24 hour answer. Pick a recent widely reported vulnerability and time how long it takes to say which products and versions are affected.

Days 61 to 90: evidence, AI controls and residency

1. Assemble evidence by section. For each section 9 area, collect the record that proves it: policy, scan output, ticket, approval. Store it where the GRC lead can produce it on request.
2. Brief management. Section 10 makes management responsible: present the model, gaps and residual risks, and minute the decision.
3. Inventory AI. List AI systems you provide or deploy, models and agents in use, and where model traffic goes. Classify each against the AI Act (prohibited, high-risk from December 2027, transparency duties now) and note the Finnish supervisor.
4. Implement transparency notices. Chatbots and generative features need the Article 50 notices and marks now; machine-readable marking for systems already on the market by 2 December 2026.
5. Decide residency. For each system that handles classified or sensitive data, decide where code, SBOMs and findings may be processed, and record the reason.
6. Plan for the CRA. If you make products, set up the 24 hour reporting path for actively exploited vulnerabilities now and plan SBOM and support-period documentation for December 2027.

How Safeguard does this

Everything in the plan above works without Safeguard. This section shows how the same steps run in Safeguard, using only what Safeguard's documentation and offering describe. Every capability named here is generally available (GA).

1. Turn on the Finnish and EU framework pages. In the Compliance and GRC suite (GA), the Finland Data Protection Act (1050/2018) framework is off until you switch it on under Compliance › Manage, while NIS2 is on unless you switch it off. The Finland page lists six scan requirements tied to GDPR Articles 5(1)(f), 24, 28, 30, 32 and 33 as given effect by the Data Protection Act, and the NIS2 page lists scan requirements tied to Article 21(2)(a), (d) and (e), Article 23 and coordinated disclosure, plus catalogue controls you evidence with tests, uploads, policies or attestations. There is no separate page for the Cybersecurity Act, so map section 9 to the NIS2 page yourself.
2. Generate SBOMs on every scan. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) builds the full component inventory. Each scan checks the framework requirements against what it found: on the Finland page that includes integrity hashes on deployed components, an inventory of the systems through which personal data flows, identifiable suppliers for third-party components and components identifiable fast enough for a 72 hour breach notice.
3. Scan without sending source code. For teams that will not grant repository access, including public bodies with classified systems, the local runner (GA) is part of the Safeguard CLI. As the docs show, you install it with the one-line installer, run safeguard, type /login, and the machine starts polling for work. It runs each scan locally and uploads only the SBOM and findings, never the source code. All traffic is outbound HTTPS that the runner opens; nothing connects to it. For headless use the docs show:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop

4. Prioritise what is exploited and reachable. Vulnerability management (GA) matches components against advisories and adds EPSS and CISA KEV context. Reachability analysis (GA) ranks the vulnerable code paths your application actually calls, which is how a small team meets a 24 hour clock without drowning in findings.
5. Gate releases and record exceptions. Policies and gates (GA) are set under Settings › Policies with a visual builder or YAML, with conditions such as severity, CVSS, EPSS, license, component age and maintenance status. Each policy's action is Block, Warn or Notify. When a legitimate exception is needed, a developer requests one with a business justification and an expiry date, approvers decide, and the audit trail is recorded. In CI, with policy outcomes on, the docs show a job failing when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

6. Stop bad packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that can block malicious, typosquatted and dependency-confusion packages before they reach a developer machine or a build. It supports the "acquisition" half of section 9's acquisition, development and maintenance area.
7. Collect evidence from suppliers. TPRM (GA) keeps the vendor directory. Its SBOM requests let you send single or bulk requests from a template that sets SPDX or CycloneDX format and a deadline, track status from Sent to Validated, send automatic reminders before and after the deadline, and validate each submission for format and completeness before it is scanned. That is the evidence trail behind a section 9 supplier control or a DORA register entry.
8. State what is and is not affected. CSAF and VEX upload (GA) lets you hold and share exploitability statements, which helps when a customer, the NCSC-FI or a supervisor asks whether a published vulnerability affects your product.
9. Keep licenses in check. License compliance (GA) applies SPDX license policy and attribution across the inventory, which matters for CRA technical documentation and customer contracts.
10. Fix, with a human in charge. Autonomous remediation (GA) can open 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.
11. Inventory and govern AI. AI-BOM discovery (GA) inventories AI assets. AI Gateway (GA) puts a guardrail proxy in front of model traffic for prompt injection, jailbreak and PII egress. MCP Guardrail (GA) generates guardrail proxy URLs for MCP servers, and agent identity (GA) tracks which agent holds what access, at what level. These support the AI inventory step in days 61 to 90; the transparency notices themselves stay your job.
12. Share posture with buyers. Trust Center (GA) publishes posture and documents such as SBOMs and VEX to customers, and helps answer security questionnaires from Finnish public sector and financial buyers.
13. Choose where it runs. Safeguard's SaaS is multi-region across US, EU and Gov regions; no Finland-specific region is offered. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. For residency and classified-system questions, the GA options are private VPC or dedicated tenancy, full on-prem, and fully air-gapped with the AI models running inside your environment and signed offline snapshot delivery. Zero AI mode (GA) runs the whole platform deterministically with no LLM in the loop, and bring your own model (GA) is available for teams with an approved model list. Safeguard states that customer code, SBOMs and telemetry are not used to train shared models.

Safeguard's posture wording is limited to what its Trust Center says: SOC 2 Type II compliant, and designed for FedRAMP High. Safeguard does not claim any Finnish or EU certification or approval.

What Safeguard does not do

• It does not make you compliant. Safeguard helps you produce and keep the evidence the Finnish and EU rules ask for. Whether you are essential or important, whether an incident is significant and whether a supplier is acceptable stay your decisions and your supervisors'.
• It does not report to Traficom, your sector supervisor, FIN-FSA or the Data Protection Ombudsman for you. It helps you answer "which products and versions are affected" quickly. Filing the early warning, the DORA incident report or the GDPR notification is your team's job, in the channel each authority sets.
• It does not provide a Cybersecurity Act framework page. Its docs list the EU NIS2 framework and the Finland Data Protection Act. Mapping section 9 of the Finnish Act, or chapter 4a of the Information Management Act, to those controls is work your GRC lead does.
• It does not classify documents or decide hosting. Security classification under the Information Management Act and the decisions that follow are yours. On-prem, air-gapped and local runner options can keep processing inside an environment you control; they do not replace that assessment.
• It does not patch vendor appliances or hosted services. When the vulnerable code sits in a remote access server, VPN gateway or SaaS product you buy rather than build, the fix comes from that vendor. Safeguard helps you track the request and the evidence.
• It does not replace your incident response. Containment, forensics, police reports and communication with affected people remain your processes.

Common mistakes

• Treating registration as compliance. Registering by 8 May 2025 was step one. Supervisors ask for the risk management model and its evidence.
• Writing a model that never mentions software. Section 9 names acquisition, development, maintenance, vulnerability handling and suppliers. A model with only network and physical controls will not survive a security audit under section 30.
• Ignoring internet-facing maintenance. The Helsinki breach started at a remote access server with an available patch that had not been installed. Patch status of edge systems belongs in your weekly review.
• Counting the 72 hours from the wrong moment. The Finnish Act counts 24 and 72 hours from detection of a significant incident. Write down when detection happened.
• Leaving AI out of the inventory. Transparency duties have applied since 2 August 2026 and Traficom supervises them. If you do not know where your chatbots and generative features are, you cannot label them.

FAQ

Is NIS2 in force in Finland?

Yes. The Cybersecurity Act (kyberturvallisuuslaki, 124/2025) entered into force on 8 April 2025. Public administration carries the same duties through chapter 4a of the Information Management Act (906/2019), amended by Act 125/2025.

Who supervises cybersecurity under NIS2 in Finland?

Sector authorities named in section 26 of the Cybersecurity Act, led by Traficom, with the Energy Authority, Tukes, Fimea, the Food Authority and others; STUK joins on 1 January 2027. The NCSC-FI at Traficom is the single point of contact and CSIRT.

How fast must a Finnish entity report a significant incident?

An early warning within 24 hours of detection, an incident notification within 72 hours of detection (24 hours for affected trust service providers), and a final report within one month of the notification, under sections 11 to 13. Reports go to your sector supervisor.

What fines apply under the Finnish Cybersecurity Act?

Up to EUR 10 million or 2 percent of worldwide annual turnover for essential entities and up to EUR 7 million or 1.4 percent for important entities, whichever is higher, imposed by a sanctions board on the supervisor's proposal.

Does the Cybersecurity Act require an SBOM?

Not by name. It requires asset management, security in acquisition, development and maintenance, vulnerability handling and supply chain security under section 9, and an SBOM is the most direct evidence for those in software. The EU CRA requires an SBOM for products with digital elements from 11 December 2027.

Does DORA apply to Finnish banks and insurers?

Yes, since 17 January 2025. FIN-FSA supervises it and collected the first register of information on ICT third-party arrangements with a 26 May 2025 deadline through its reporting service.

Who supervises the AI Act in Finland?

Supervision is spread across authorities under the Act on the Supervision of Certain Artificial Intelligence Systems (1377/2025), in force since 1 January 2026. Traficom is the single point of contact and supervises the transparency duties; the Data Protection Ombudsman, FIN-FSA and sector authorities cover specific high-risk uses.

When do Finnish manufacturers have to report under the EU CRA?

Since 11 September 2026, for actively exploited vulnerabilities and severe incidents, through ENISA's single reporting platform. The full product requirements apply from 11 December 2027.

Can a Finnish public body keep source code inside its own network while scanning?

Yes, with tooling that processes code locally. Safeguard's local runner scans on your machine and uploads only the SBOM and findings.

The Finnish rules come down to knowing what is in your software, fixing what matters on a clock, and proving it with records. The block below covers how to close the remediation gap itself, including when upstream has not shipped a fix yet.

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, Griffin, Safeguard's security model, opens 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 is a real 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 the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan. The same flow is how a Finnish product team closes a vulnerability it may have to report under the CRA, with a human approving each change.

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

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. This is the option for public bodies with classified systems and banks that will not let source code leave their network.

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 chooses which tools Claude can use. For teams preparing AI inventories and agent access controls under the AI Act, it shows what scoped agent access looks like in practice.

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

Quick check

Sources

• Finlex: Cybersecurity Act (kyberturvallisuuslaki, 124/2025), consolidated (Finnish)
• Traficom: Cybersecurity Act passed by Parliament, NIS 2 obligations enter into force 8 April 2025
• Finlex: Act on Information Management in Public Administration (906/2019), consolidated (Finnish)
• Finlex: Act on the Supervision of Certain Artificial Intelligence Systems (1377/2025) (Finnish)
• Traficom: More transparency now required when AI is used
• FIN-FSA: Reporting release 11/2025 on the DORA register of information
• European Commission: Cyber Resilience Act
• European Commission: AI Act regulatory framework and timeline
• City of Helsinki: Education Division target of data breach
• City of Helsinki: Investigation into Education Division data breach proceeds (13 May 2024)
• City of Helsinki: National Bureau of Investigation launches preliminary investigation
• City of Helsinki: Otkes investigation report completed (Finnish)
• Tietoevry: clarification of the sequence of events in the ransomware attack (Swedish)
• Safeguard docs: Finland Data Protection Act (1050/2018) framework
• Safeguard docs: EU NIS2 framework
• Safeguard docs: Local Runner
• Safeguard docs: Policies and Gates
• Safeguard docs: TPRM SBOM Requests

The DORA, CRA Article 14 and Annex I, and GDPR article references are from our reading of the regulations; EUR-Lex did not load for us on 25 October 2026, so check the Official Journal text before relying on an article number.

Related reading: NIS2 supply chain evidence for EU operators, SBOM requirements for financial services under DORA, and EU Cyber Resilience Act SBOM obligations.

To try the flows above, download Safeguard and read the Safeguard documentation.

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