The NIS 2 Directive redefines the European framework for cybersecurity in essential services. Compared to the previous regulation, the changes are significant: obligations extend to more sectors, technical and organizational measures are strengthened, greater attention is given to the supply chain, and new sanctions are introduced in case of non-compliance.
In this article, we will not focus on the entire regulatory framework but on a specific aspect: the impact of NIS 2 on the software lifecycle and the responsibilities of all companies that design, develop, or provide business applications.
Why NIS 2 Also Concerns Software Development
The NIS 2 Directive does not prescribe specific technologies or security measures to integrate into application code, as this is not its role. It is a high-level regulation that defines general principles and outcome-based obligations, leaving the translation of these principles into operational practices, tools, and methodologies to implementing standards, technical frameworks, and international best practices (such as ISO, OWASP, and NIST). In other words, NIS 2 tells you what needs to be done, not how to do it.
The most explicit reference to software is in Article 21, where the legislator highlights the need to adopt appropriate measures to ensure the “security of the acquisition, development, and maintenance of network and information systems, including vulnerability management and disclosure.” The principle is broader: the entire Directive mandates that essential entities adopt appropriate and proportionate technical, operational, and organizational measures to manage risks to network and information system security. And security, inevitably, starts with software.
Before firewalls, monitoring, or even infrastructure, there is application code. Vulnerable software is the first weak link in the security chain: it can expose essential services, render perimeter controls ineffective, and compromise the overall resilience of the organization. This is why discussing NIS 2 also means discussing the Secure Software Development Lifecycle (SSDLC).
This is no trivial matter. To be considered secure in relation to relevant threats and vulnerabilities, software must be:
- Designed and developed according to security by design and by default principles;
- Continuously tested against known vulnerabilities, including those introduced by third-party or open-source components;
- Monitorable and maintainable over time, ensuring any flaws can be identified and corrected quickly.
Although NIS 2 is not a regulation aimed at developers, it indirectly requires adopting secure development best practices. Let’s look at these in more detail.
A Secure Methodology: By Design and By Default
Compliance with NIS 2 first requires a shift in perspective: in software development and management, security cannot be an afterthought, but must be integrated from the design phase. Practically, this means not only adopting modern software lifecycle management methodologies (like DevOps) but also embedding security measures (code analysis, testing, secure coding practices, etc.) into every phase of the lifecycle.
A successful model is DevSecOps, which integrates security controls directly into development and release pipelines, automating static and dynamic code analysis, dependency management, configuration control, and patch application.
Risk Analysis and Continuous Vulnerability Management
Before writing code, you must understand the context and assess the risks. A process compliant with NIS 2 starts with a preventive risk analysis for the application: potential threats, exposed surfaces, types of data processed, interactions, and dependencies on other systems, possibly third-party. This allows prioritization of interventions based on actual risk and the design of solutions that balance security, performance, and scalability.
A key element is vulnerability management: identifying and fixing known weaknesses, tracking dependencies (including via a Software Bill of Materials, SBOM), assessing updates, and monitoring security alerts concerning third-party and open-source components.
Logging, Monitoring, and Observability
NIS 2 emphasizes proactive cyber risk management. The Directive requires a systemic approach based on continuous, demonstrable risk identification, assessment, and mitigation.
Implementing monitoring systems is essential to meet this requirement; after all, you cannot manage what you do not know. Observability is particularly important for meeting NIS 2 requirements, as it allows understanding what is happening and why it is happening (e.g., a non-responsive external dependency or a bug in a specific microservice).
If software is observable by design, it becomes possible to meet the strict incident reporting timelines and, most importantly, conduct in-depth software analyses to demonstrate resilience and continuous improvement.
Updates and Lifecycle Management
Software is never finished—it must always account for new threats and vulnerabilities. Applications need continuous updates without introducing new bugs. Therefore, structured processes for patch development and deployment, safe rollbacks, release validation, and communication with end users are essential.
Supporting Companies in Developing Secure Software
One of our core competencies is software development, the foundation of any digital transformation project. At Kirey, we develop software using modern, agile methodologies focused on performance, scalability, and, of course, maximum security.
Not only to ensure regulatory compliance with directives like NIS 2, but also because security is the basis for building customer trust, protecting corporate reputation, and safeguarding critical data and processes.
Contact us to discover how we can help you develop software that is high-performing, modern, secure, and compliant with regulations.
