Blog

NIS2 Article 21.2 e:

Security in procurement and development: build the lock before you move in.

I often think of it like this: you wouldn't move into a new house hoping someone will come and fit the lock later. You make sure the door can be locked before you bring in the sofa. Yet, we often do the exact opposite with digital systems. We buy, develop or order a service, then try to 'add security' after everything is already running.

This is why NIS2 Article 21.2 e is one of the most important points in the entire regulation. It requires security throughout the entire lifecycle: at procurement, development and maintenance, including vulnerability management and coordinated vulnerability disclosure (European Union, 2022).

Robert Willborg

Co-founder and Chief Security Officer at OneMore Secure.

First: what point e actually says

It's easy to assume 21.2 e only concerns procurement. It doesn't. Point e covers security in acquisition, development and maintenance of network and information systems. This includes vulnerability management and reporting. In other words: how you build, buy and manage technology in a way that ensures trustworthiness over time (European Union, 2022).

Application in Sweden: from theory to supervision

In Sweden, the Cybersecurity Act (2025:1506) and Cybersecurity Ordinance (2025:1507) came into force on 15 January 2026. This means NIS2 is no longer just an 'EU idea' but a practical set of requirements that must be demonstrated in work, decisions and evidence (Swedish Parliament, 2025a; Swedish Parliament, 2025b; Government, 2026).

The most common pitfall: Excel, standard forms and one-off checks

I still encounter procurements where security is handled through long questionnaires emailed back and forth. The questions are often generic, not linked to the actual delivery, and answers are rarely checked after signing. It's like asking a builder if they 'usually' fit locks, then never checking if the door actually locks.

NIS2 points in a different direction. Security should be part of the lifecycle, not a one-off event. This means requirements must be measurable and followed up throughout the contract period. Otherwise, you get a reassuring piece of paper but a reality that isn't secure.

What vulnerability management means without becoming 'security theatre'

A vulnerability is simply a weak spot that can be exploited. Vulnerability management means identifying, prioritising and fixing them before they cause incidents. It sounds technical, but at its core it's governance: who owns the decision, how quickly do we act, and how do we verify it was done.

For some types of actors, the EU has also specified technical and methodological requirements through an implementing regulation. This emphasises that vulnerability management and secure lifecycle routines must be systematic, traceable and up to date (European Commission, 2024).

The uncomfortable truth: your supplier is part of your attack surface

When you buy systems or services, you don't just buy functionality. You also buy a future update chain, support chain, component list and culture. If the supplier has poor vulnerability routines or is reluctant to answer questions, that's a red flag. Not because they are 'bad', but because they become part of your exposure.

This is closely linked to Article 21.2 d on the supply chain, but 21.2 e goes deeper: it concerns how securely what you buy and build is designed and maintained over time (European Union, 2022).

Three realistic and lawful suggestions

I want to keep this as a blog post, not a manual. But I dare to suggest three actions that usually make a difference, and align fully with 21.2 e without inventing new requirements.

· Require evidence, not promises.

· Set vulnerability SLAs by risk.

· Practice updating as a routine.

Requiring evidence means asking for concrete artefacts: what the process looks like, what is measured, and what the latest period shows. Vulnerability SLAs means linking time requirements to criticality, so not everything is 'as soon as possible'. Practicing updating as a routine means patching and changes are done in a controlled way, with rollback and clear communication. That's how you build a lock that actually locks.

Final word

Article 21.2 e is a wake-up call for anyone who wants to treat security as an afterthought. It says: embed security where it matters most, when you select, build and manage the system. Then risk management is not a brake. It becomes a way to avoid panic, reduce costs over time and increase trust when someone asks: 'can we rely on this?'. A lock that works every day isn't glamorous. It's freedom.