NIS2 and your development project – what you need to know

For organizations covered by NIS2, cybersecurity is no longer just a good idea – it’s the law, and the responsibility extends all the way into the supply chain. That changes how a development project has to be set up. Security can no longer be something the vendor “handles anyway” – it becomes a requirement you’re responsible for setting and following up on. This guide translates the directive into what it practically means when you commission and build a digital service.

Which sectors and sizes are covered

The first thing to find out is whether you’re covered at all, since NIS2 doesn’t apply to everyone. The directive targets organizations whose function matters to society, and splits them into two groups with somewhat different oversight.

The designated sectors include energy, transport, banking, healthcare, drinking water and wastewater, digital infrastructure, public administration, postal services, waste, and food, among others. Compared to the old NIS directive, the list is considerably broader, and many organizations that were previously outside are now covered. Size acts as a rough threshold: as a rule of thumb, medium and larger organizations are covered, while the very smallest are often exempt. Exactly where the thresholds sit is set by the Swedish legislation implementing the directive, so an organization near the line should check its own situation rather than guess. The basic question is simple to ask: are we in a designated sector, and are we big enough? If the answer is yes on both, the requirements apply.

Supply-chain responsibility when choosing a vendor

What makes NIS2 especially relevant to a development project is supply-chain responsibility. The core of it is that you can’t outsource security to someone else and wash your hands of it. If you hire an agency to build your system, that agency becomes part of your chain, and their security shortcomings can become your problem, both in practice and under oversight.

In practice, that means security has to be a criterion when you choose a vendor, not an afterthought. In a technical evaluation, you should look at how the vendor actually works with security: how they protect code and data, how they handle vulnerabilities and incidents, and how they in turn place requirements on their own subcontractors. That should then be reflected in the contract, with clear commitments on security work, incident handling, and the right to follow up. A vendor that can’t describe its own security work is a risk regardless of NIS2 – but under the directive, that risk also becomes your compliance issue.

Incident-reporting time limits and what the system must handle

One of the most concrete new elements in NIS2 is the requirement for fast incident reporting. Serious incidents must be reported to the relevant authority within tight windows – an early warning shortly after the incident is detected, followed by a more detailed report afterward. The exact timings follow from national law, but the direction is clear: it has to happen fast.

For a development project, the key insight is that you can’t report what you don’t detect. A system lacking proper logging and monitoring makes it impossible to know an incident has occurred, let alone timestamp it and report it on time. That’s why certain capabilities become directly tied to compliance:

Most of this already characterizes a well-built system anyway. NIS2 makes the difference of moving it from desirable to mandatory – and it should be in the requirements from the start, since it’s hard and expensive to build in after the fact.

A concrete scenario

An organization in one of the designated sectors was about to procure a new system and determined it was covered by NIS2. Instead of treating security as a technical detail to sort out at the end, they built it into the requirements and into the vendor evaluation right from the start.

In choosing a vendor, their security work was genuinely weighed in: how they handled vulnerabilities, how they’d build logging and monitoring, and how they placed requirements down their own chain. The system was built with incident detection and traceability from the ground up, and the contract regulated reporting responsibility and follow-up. When a minor security event later occurred, it could be detected, timestamped, and reported within the window – something that would have been impossible if security had only been considered after launch.

Weave the requirements in from the start

NIS2 turns cybersecurity into a matter for the entire supply chain and for management, not just the IT department. For a development project, the message is concrete: find out whether you’re covered, weigh in security when choosing a vendor, write it into the contract, and build systems that can detect and report incidents on time. Done from the start, it’s manageable; done too late, it becomes an expensive scramble under pressure.

At Weapp we build with security and traceability as a starting point and are glad to help buyers translate requirements like NIS2 into concrete specifications, as part of our services. Wondering what the directive means for your next project? Get in touch so we can talk through how the requirements are best weighed in already at vendor selection.