Finland’s Cybersecurity Act, which transposes the EU’s NIS2 Directive into Finnish law, brought specific, concrete obligations to thousands of organizations that had no corresponding requirements before. This article is for the technical and executive leaders in those organizations. It cuts through the regulatory language and explains what NIS2 actually requires from your cloud architecture, in terms you can act on today.
What changed and who is now covered
The EU’s Network and Information Security Directive (NIS2) replaced its predecessor, NIS1, in October 2024, expanding both the scope of who is covered and the depth of what is required. Finland implemented the directive through the Cybersecurity Act (Act 124/2025), with obligations entering into force in April 2025.
The scope expansion is significant. Under NIS1, roughly 1,100 organizations in Finland fell under the directive’s requirements. Under NIS2, that number has grown to approximately 5,500 (Secomea, 2025). The expansion covers new sectors: healthcare, energy, water supply, manufacturing, transport, financial services, digital infrastructure, and public administration. If your organization operates in any of these sectors and meets the relevant size thresholds, you are almost certainly covered.
NIS2 divides covered organizations into two tiers. Essential entities face the most demanding requirements and the highest potential penalties: fines of up to 10 million euros or 2 percent of global annual revenue, whichever is higher. Important entities face lighter supervisory requirements but still carry real compliance obligations. The classification depends on your sector, your size, and how critical your services are considered to be. In Finland, supervision is handled by sector-specific authorities: Traficom for digital infrastructure and telecommunications, Valvira for healthcare, the Finnish Energy Authority for energy, and others.
The key point for CTOs: NIS2 is not a legal problem your legal team can handle alone. Compliance is largely a technical challenge. The controls required live in your cloud architecture, your monitoring stack, your access management, your vendor contracts, and your incident response processes.
What NIS2 requires from your cloud, specifically
The directive operates on four core pillars. Each has direct implications for how cloud environments must be designed and operated.
Risk management means documented decisions, not just working controls
Article 21 of NIS2 requires covered entities to implement technical, operational, and organizational measures proportionate to the risks they face. In cloud terms, this means risk assessments must be documented and reviewed regularly. Security policies must exist for information systems and must reflect actual architectural decisions. If your cloud environment was designed on sound engineering principles but nobody wrote down why specific controls were chosen, you have a gap. NIS2 requires you to be able to show your work, not just show the result.
Corporate accountability is direct and personal
Under NIS2, senior management is personally accountable for cybersecurity compliance. Board members and executives can face consequences for failures that result from the organization not implementing adequate controls. This changes the dynamic between engineering teams and leadership. Security posture is no longer something that lives entirely in the hands of technical staff. Executives must approve cybersecurity strategies, receive appropriate training, and understand what they are signing off on. In practical terms, your cloud security posture needs to be explainable to a board member, not just to another engineer.
Incident reporting is a technical infrastructure requirement
NIS2 mandates a 24-hour early warning when a significant incident is detected, followed by an initial assessment report within 72 hours. This sounds manageable until you have a real incident and realize your monitoring stack was not designed with regulatory reporting timelines in mind. The 24-hour window starts when you become aware of a significant incident. That means your detection capability is part of your compliance posture. Organizations that rely on manual monitoring, ad hoc alerting, or slow escalation chains will struggle to meet this requirement when it matters most. The incident reporting pipeline, including SIEM integration, escalation paths, and reporting contacts for Traficom, must be built and tested before an incident happens, not during one.
Business continuity means tested recovery, not documented hope
NIS2 requires plans for business continuity and crisis management. In cloud environments, continuity planning must go beyond writing documents. Recovery time objectives must be defined and tested. Backup and recovery processes must actually run in practice. Incident response playbooks must be practiced under realistic conditions. Many organizations have some version of these plans on paper but have not run tabletop exercises or real recovery tests in years. NIS2 does not ask whether you have a plan. It asks whether your plan works.
The four areas most organizations underestimate
In readiness work across cloud environments, four gaps appear consistently. They tend to be underestimated not because they are obscure, but because they sit at the edges of traditional security thinking.
Supply chain accountability
NIS2 requires organizations to evaluate the cybersecurity posture of their suppliers and to embed cybersecurity obligations into vendor contracts. This applies directly to cloud providers, managed service partners, and any third party with access to your systems. It also applies to the software supply chain: the dependencies you run on your cloud. Many organizations have well-configured cloud environments but have not revisited their vendor contracts or supplier assessments since NIS2 came into force. The responsibility does not stop at your own perimeter. If your cloud managed service provider is breached and that breach reaches your data, your compliance posture is implicated.
MFA as the floor, not the ceiling
Multi-factor authentication is a minimum requirement under NIS2. The question is not whether MFA is enabled somewhere in your environment. The question is whether every access path is covered, including service accounts, administrative interfaces, legacy systems, and API access. In cloud environments, MFA gaps often appear not in the main user authentication layer, where it is usually configured, but in the integration layers, the deployment pipelines, and the operational access paths that were set up before MFA was standard practice. A survey of your actual access paths, not just your policy documents, is the right starting point.
Encryption as architecture, not policy
NIS2 assumes data encryption at rest and in transit. In complex cloud environments, coverage is often uneven. Primary databases and storage buckets tend to be encrypted. Logging pipelines, inter-service communication, backup targets, and data flowing between cloud services are more often patchy. The issue is usually not that encryption is missing by choice. It is that coverage was applied service by service as systems were built, without an overarching architecture principle. A full encryption inventory across your cloud estate is a practical first step.
Documentation that serves two audiences
The shift in corporate accountability means the documentation your cloud engineers maintain must now serve non-technical executives as well as technical peers. Security policies, risk assessments, and architecture decisions must be written clearly enough for a board member to read and understand what they are approving. If your documentation is written exclusively for engineers, that is a practical compliance gap, because the people now accountable for it cannot evaluate it.
How to assess your current position
The most common mistake organizations make with NIS2 is treating it as a legal exercise rather than a technical one. The legal team can tell you whether you are in scope. What comes next is a genuine assessment of your cloud security posture against the requirements that matter.
That assessment should cover your access control architecture and MFA coverage, your encryption posture across all data stores and in-transit paths, your monitoring and incident detection capability, your incident reporting process and its readiness for a real 24-hour window, your vendor contracts and supplier security assessments, your business continuity and recovery processes, and your documentation and governance trail.
At Cloud2, our Cloud Review is designed for exactly this. We map your cloud environment against the security requirements that matter under NIS2, identify where you are compliant, where you are not, and which gaps carry the most risk. The output is not a list of theoretical vulnerabilities. It is a clear picture of your actual posture and a concrete plan for closing the gaps that matter most.
NIS2 compliance is achievable. Most organizations are closer than they think on some requirements and further than they think on others. The first step is knowing which is which.
