Skip to main content
NIS2Certify
Back to overview

NIS2 Article 21(2)(e): Secure Development and Vulnerability Handling for MSPs

By NIS2Certify
NIS2Article 21vulnerability-handlingsecure-developmentMSPpatch-management
NIS2 Article 21(2)(e): Secure Development and Vulnerability Handling for MSPs

A logging library your client never chose, never installed on purpose, and cannot name off the top of their head ships a critical CVE on a Friday afternoon. It sits three layers deep inside a monitoring agent you deployed for them eighteen months ago. The clock that matters is not the one on the vendor's advisory — it is the one an auditor will start when they ask how fast you knew, how fast you acted, and where the proof is.

That scenario is what NIS2 Article 21(2)(e) is written to prevent. It is the measure most consultants skip because it sounds like a developer problem. It is not. It is a supply chain and maintenance problem, and for MSPs it is one of the hardest measures to evidence.

Article 21(2)(e) covers everything you build, buy, and maintain

The ten risk-management measures in Article 21(2) are the backbone of NIS2 compliance. Most attention goes to the visible ones — MFA, backups, incident reporting. Measure (e) is quieter and broader: "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure."

Read it slowly. Three verbs — acquisition, development, maintenance — plus a standing obligation to handle and disclose vulnerabilities. It applies whether you write code, resell a platform, or just keep someone else's software patched. There is no carve-out for "we don't develop anything." If you maintain a client's systems, you own the maintenance half of this measure.

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

For the full map of how (e) connects to the other nine measures, see our breakdown of all ten Article 21 measures.

What "secure acquisition, development and maintenance" means in practice

Break the measure into the three things it actually asks for.

Acquisition means you choose software and suppliers with security as a selection criterion, not an afterthought. That means documented vendor evaluation: does the supplier follow secure development practices, do they publish advisories, do they commit to disclosing vulnerabilities in their product? A one-line "we use reputable vendors" does not survive an audit.

Development means that anything you build — a client portal, an automation script, a custom integration — goes through a secure lifecycle. Secure coding standards, code review, security testing before deployment, and a process for vulnerabilities found after go-live. You do not need a 40-page SDLC document. You need a repeatable process you can show.

Maintenance is where most MSPs live. It means patching, change management, and keeping an accurate inventory of what is deployed where. You cannot patch what you cannot see, and you cannot prove you patched it without records.

Do you build, or only maintain? The controls differ

The measure applies to everyone in scope, but the weight shifts depending on what you do. Use the decision logic below to work out which controls carry the most audit risk for your operation.

Does NIS2 Apply to Your Organisation?
1
Does your organisation operate in an essential or important sector (energy, transport, health, digital infrastructure, etc.)?
Yes ↓No →
2
Does your organisation have 50 or more employees, or an annual turnover exceeding €10 million?
Yes ↓No →
3
Is your organisation a critical infrastructure provider or a qualified trust service provider?
Yes ↓No →
✗
NIS2 does not directly apply to your organisation.
✓
NIS2 applies to your organisation as an Essential or Important Entity.
!
NIS2 may apply to your organisation — seek legal advice to confirm your status.
Applies
Possibly applies
Does not apply

If you only maintain third-party software, your exposure sits in inventory accuracy, patch SLAs, and change records. If you develop anything client-facing, add secure coding, code review, and pre-release testing to the list. If you resell or bundle other vendors' platforms, your acquisition controls — vendor vetting and disclosure clauses — become the thing an auditor probes first. Map your services honestly before you build the control set.

Vulnerability handling: intake, triage, and patch SLAs

Vulnerability handling is a loop, not a project. It has three moving parts.

Intake is how vulnerabilities reach you — vendor advisories, your own scanning, third-party pen tests, and a channel for outsiders to report a flaw in something you run. If there is no inbox for that last one, you are missing a control the directive names explicitly.

Triage is how you rank what arrives. Severity plus exposure plus exploitability, scored the same way every time so two engineers reach the same answer.

Remediation is the patch, tied to a service-level clock. NIS2 does not prescribe patch timeframes, so the market has settled on a de facto standard that buyers now write into contracts: critical inside 24–48 hours, high within 7 days, medium within 30 days, low within 90 — with a documented exception process for the cases where you genuinely cannot patch in time. That exception process matters as much as the SLA. An auditor is not looking for a perfect record. They are looking for a defensible one.

The catch for MSPs: you have to produce these records per client, at audit time, on request. Scanning that lives only in a dashboard is not evidence. A dated, exportable trail is.

Coordinated vulnerability disclosure and the EUVD

Handling your own vulnerabilities is half the measure. The other half is disclosure — and NIS2 built a formal channel for it.

Under Article 12, every Member State designates one CSIRT as the coordinator for a national coordinated vulnerability disclosure (CVD) programme. That CSIRT acts as a trusted intermediary between whoever reports a flaw and the vendor whose product carries it. It contacts the affected parties, supports the reporter, and negotiates disclosure timelines — including the messy cases where one vulnerability hits products across several countries at once.

Feeding all of this is the European Vulnerability Database (EUVD), maintained by ENISA, which has run a vulnerability registry as an official CVE Numbering Authority since January 2024. For an MSP, the EUVD is a second source of truth alongside vendor advisories — and knowing how to work with it is now part of the job. We cover the practical side in our EUVD guide for MSPs.

The practical takeaway: you need a published way for someone to report a vulnerability in a product or service you operate, and a decision on how you engage with the national CVD process. Both are auditable. Neither is optional if you are in scope.

When a vendor's flaw becomes your client's liability

Here is where measure (e) stops being abstract. A vulnerability in a supplier's product does not stay contained. It cascades — from the vendor, to you, to your client, to their clients — and NIS2's supply chain obligations (measure (d)) mean the liability travels with it.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

If a component you deployed carries an unpatched critical flaw and a client is breached through it, "the vendor should have told us" is not a defence. The directive expects you to have assessed that supplier, contracted for disclosure, and had a process to act on the advisory when it came. This is why acquisition and vulnerability handling are one measure and not two — the weakness enters through what you bought and is managed through what you do next. Our supply chain security breakdown walks through the contractual side.

The evidence an auditor will actually ask for

Measure (e) is judged on paper trails, not intentions. Have these ready, per client where relevant:

A software and supplier inventory that is current, not a spreadsheet from last year. Vendor evaluation records showing security was a selection criterion. A patch policy with severity-based SLAs, plus the logs proving you met them — and the exception records where you did not. Change management records tying each change to an approval. A vulnerability intake and disclosure channel that exists and is monitored. And, if you develop anything, secure SDLC notes: coding standards, review evidence, pre-release test results.

None of this is exotic. All of it is the difference between passing an audit and explaining, after an incident, why the records do not exist. Measure (f) — assessing whether your controls actually work — sits directly on top of this one; see our audit-loop guide for how the two connect.

Start with what you can see

Most MSPs already do 60% of this measure — they patch, they track changes, they pick decent vendors. The gap is almost always evidence and the disclosure channel, not the underlying work. The fastest way to find your specific gaps is to look at your maintenance and acquisition controls through the lens of Article 21(2)(e) and mark what you could hand an auditor today versus what you would have to scramble to assemble.

If you want that gap mapped for you, run a free NIS2 quick scan — it flags exactly where your secure-development and vulnerability-handling posture stands against the directive, per measure.

Measure (e) is not the flashiest part of NIS2. It is the one most likely to be thin when an auditor pulls the thread, precisely because it looks like someone else's job. For an MSP, it is yours.

    NIS2 Article 21(2)(e): Secure Development and Vulnerability Handling for MSPs — NIS2Certify