Taking the NIS2 Directive into account in software development

The NIS2 Directive is a regulation of the European Union that entered into force on 17 October 2024. Its purpose is to strengthen cybersecurity in critical infrastructure and other essential services across the EU. As a result, software development teams are also required to comply with new statutory requirements.

The Directive applies to large and medium-sized enterprises in various sectors that are considered critical or otherwise important. For organizations operating in Finland, additional national guidance is available from the Finnish Cyber Security Centre’s website (PDF, only in Finnish). In particular, internal software development teams within these organizations must ensure that they implement in practice the risk management measures required by the Directive. Compliance with the Directive and the ability to demonstrate it are also important for software development companies that build software for organizations subject to NIS2 requirements, as the Directive requires supply chain security.

In Finland, the NIS2 Directive is being complemented by national legislation, the Cybersecurity Act (KyberTL). While KyberTL largely aligns with NIS2, it contains some national differences (though not in areas relevant to this blog). KyberTL applies only to private-sector and non‑public operators in Finland. NIS2 requirements for public administration in Finland have been implemented separately in Chapter 4 a of the Finnish Act on Information Management (TiHL).

The NIS2 Directive applies across all sectors it covers. It requires organizations to implement the following risk management measures:

• risk analyses and policies related to the security of information systems;

• incident handling;

• business continuity management, such as backup and recovery planning, and crisis management;

• supply chain security, including security aspects of the relationships between each entity and its direct suppliers or service providers;

• security of the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure;

• policies and procedures for assessing the effectiveness of cybersecurity risk management measures;

• basic cyber hygiene practices and cybersecurity training;

• policies and procedures related to the use of cryptography and, where appropriate, encryption;

• personnel security, access control policies, and asset management;

• where appropriate, the use of multi-factor authentication or continuous authentication solutions, secure voice, video, and text communications, and secure emergency communication systems in the entity’s operations.

In addition, the Directive also requires (as part of incident handling) the reporting of significant security incidents within the following timeframes:

• Early warning to the competent authority within 24 hours.

• Incident notification within 72 hours, including an initial assessment of severity.

• Interim reports at the request of the authority.

• A final or progress report within one month, containing detailed information.

In practice, this requires the following:

1. Draft a security policy that describes how your organization implements the risk management measures listed above.

2. Ensure that your employees have access to detailed instructions, so they know exactly how to comply with these risk management measures in practice.

3. Monitor that security measures are actually implemented through up-to-date monitoring and regular reviews.

4. For organizations operating in Finland, KyberTL additionally requires particularly detailed, step-by-step instructions for incident reporting.

Although the basic principles of secure software development can be generalized, each organization nevertheless has different practical ways of working. Differences may depend, for example, on the types of applications companies build, the tools they use, and the types of customers they work with.

For this reason, there is no single correct approach to security policies and their practical implementation; instead, each organization must define its own practical processes. Below are examples of what software development teams can do in practice to implement the risk management measures listed above.

Risk analysis and security policies

Conduct thorough threat modeling to identify application-specific risks and design effective countermeasures. Additionally, ensure whether the application must comply with data protection regulations and laws, such as the GDPR, to meet legal requirements.

Incident handling

Applications in use should be monitored, for example, with Microsoft Sentinel, which triggers an alert when new security incidents are detected. Based on alerts, automated or manual actions can be taken to handle security incidents. Organizations must also ensure that NIS2-mandated reporting obligations are met, following the procedures defined by the competent national authority (for example, in Finland, under KyberTL).

Business continuity management

Automating application deployments, for example with Bicep templates and DevOps release pipelines, ensures that the solution can be quickly redeployed when needed. When the application’s code and configurations are kept up to date in version control, redeployment may require only the press of a button.

Supply chain security

Use code libraries (dependencies) only from trusted parties, such as Microsoft. Be cautious when installing dependencies from publishers you are not certain about. Ideally, the organization has a process in place to validate third-party packages before they are used in applications delivered by the organization.

Security of software development and maintenance

Keep third-party code libraries, application frameworks, and Azure resources used by the application up to date. Use various automated security tools (e.g. GitHub Advanced Security) to detect vulnerabilities. Have an expert review applications for security issues. Follow secure software development practices. Development practices lead us to the next point.

Cybersecurity training

In addition to basic cybersecurity training, software developers can benefit greatly from AppSec training. People learn in different ways, so providing both self-study materials and group-based training for learning secure software development practices is recommended.

Both NIS2 (EU level) and KyberTL (Finland) require training to be provided to everyone, but also role- and unit-specific training where necessary, as well as additional separate guidelines (unit- or role-specific security guidelines).

Use of cryptography and encryption

The OWASP Top 10 document’s article on Cryptographic Failures is a good starting point for this topic. It should, however, be combined with more practical guidelines that take the technologies in use into account.

Access control principles

Follow the principle of least privilege wherever possible. This principle means that you should grant the minimum possible permissions, and only to the data and resources that are absolutely necessary for the tasks performed by the application or the user.

Use of authentication solutions

Do not use service accounts to run your code, as this typically requires disabling multi-factor authentication (MFA). NIS2 states that MFA must be used.

There are, of course, exceptions to this (e.g. Azure Logic Apps, Power Platform). In similar situations, however, it is generally recommended to prefer application identities (service principals), such as Azure managed identities.

Assessing the effectiveness of cybersecurity risk management measures

Ideally, there is automation in place that notifies you if any of the risk management measures listed above are not implemented. However, it is not possible or sensible to automate everything, so part of the assessment may require human review. Conducting regular security audits is a good idea.

As you may have already noticed when reading the list above, if you are already developing software in accordance with a Secure Software Development Lifecycle, you are likely already to meet a large portion of the NIS2 Directive’s requirements. However, ensure that you also have clear processes for incident reporting and effectiveness assessment, aligned with both EU-level NIS2 obligations and any applicable national legislation.

If you need assistance, explore our services and get in touch with us! We support organizations subject to NIS2 requirements across the EU, and provide Finland‑specific expertise where national legislation such as KyberTL applies, including SOC & CSIRT services, cybersecurity maturity assessments, SIEM implementation and development, and support for administrative cybersecurity obligations.