What does NEN 7510 require on technical vulnerability management?

Since the 2024 revision, NEN 7510 follows the structure and numbering of ISO 27001:2022. Control 8.8, "management of technical vulnerabilities", requires a healthcare organisation to obtain information about technical vulnerabilities in its systems in a timely manner, assess its exposure to them, and take appropriate measures. The standard prescribes no product or frequency, but does require the process to run and to be demonstrable.

Is NEN 7510 mandatory for healthcare providers?

For healthcare providers that process personal health data, NEN 7510 is in practice the standard by which they organise information security; the GDPR requires appropriate technical and organisational measures, and NEN 7510 is the Dutch elaboration of that for healthcare. Certification is not legally mandatory for every healthcare provider, but is often required contractually or by supply-chain partners.

What is the difference between NEN 7510 and ISO 27001 on this point?

On technical vulnerability management they are close: at the 2024 revision NEN 7510 adopted the structure and numbering of ISO 27001:2022, including control 8.8. NEN 7510 adds the healthcare-specific context: protecting personal health data and the continuity of care processes weigh heavily in the risk assessment.

How do I demonstrate technical vulnerability management at a NEN 7510 audit?

With evidence that the process runs: a current overview of your external attack surface, dated measurements showing which vulnerabilities were found and prioritised, remediation with an owner and a deadline, and a re-measurement proving the gap is closed. An auditor tests the cycle, not a single scan report. Dated, traceable measurements weigh more heavily than a policy document.

Back to knowledge base

Technical vulnerability management under NEN 7510: what control 8.8 asks of healthcare organisations

Published on August 18, 2026

An auditor testing your healthcare organisation against NEN 7510 asks, under control 8.8, how you manage technical vulnerabilities. That requirement is not new: under ISO 27002:2013 and NEN 7510:2017 the same subject was control 12.6.1. What changed in 2024 is its place and number. At the revision, NEN 7510 adopted the structure and numbering of ISO 27001:2022, and management of technical vulnerabilities received the number 8.8. For healthcare providers it is therefore a numbered, testable control with a fixed place in the framework. This page describes what 8.8 asks in a healthcare context, where it differs from a general security standard, and how you make it demonstrable rather than merely promising it on paper.

NEN 7510 in brief, and why 2024 matters

NEN 7510 is the Dutch standard for information security in healthcare. It consists of two parts: NEN 7510-1 describes the management system (how you set up and steer information security) and NEN 7510-2 describes the controls (what you do concretely). The standard is tailored to organisations that process personal health data, from hospitals and mental-health institutions to GP out-of-hours services, healthcare software vendors and the parties that run their infrastructure.

What makes 2024 special: at the revision, NEN 7510 adopted the structure and numbering of ISO 27001:2022, with the controls from the accompanying ISO 27002:2022. That same revision grouped those controls into four themes (organisational, people, physical, technological) and introduced the numbering in which control 8.8 "management of technical vulnerabilities" falls under the technological measures. For healthcare this means: the same 8.8 that an ISO 27001 auditor tests now also sits in the assessment framework for NEN 7510, with the healthcare-specific weighting around it.

What control 8.8 requires

The core of 8.8 is threefold. An organisation must:

obtain information about technical vulnerabilities in a timely manner for the systems it uses;
assess its exposure to those vulnerabilities;
take appropriate measures to manage the associated risk.

Note what it does not say. The standard names no product, no supplier and no scan frequency. It prescribes an outcome: you know which vulnerabilities are in play, you know how serious they are in your situation, and you act on them. How you fill that in is up to you, provided you can demonstrate it. That "demonstrating" is what an audit turns on, and it is usually harder to deliver than the process itself.

Technical vulnerability management is thus the healthcare variant of a broader process. We describe the full cycle (discover, detect, prioritise, remediate, verify and repeat) apart from the sector in vulnerability management: the process, the standard and how to get it demonstrably in order. This page looks at what the healthcare context adds to it.

The first step: receiving vulnerability information in time

The first pillar of 8.8, "obtaining information about technical vulnerabilities in a timely manner", is more concrete to fill in for healthcare than for a generic organisation. Alongside the general sources (the CVE feeds, the security advisories from the NCSC and the warnings from your own software vendors), the sector has its own channel: Z-CERT, the sectoral Computer Emergency Response Team for Dutch healthcare, shares vulnerability and threat information with affiliated healthcare institutions, focused on the systems and medical devices in use in healthcare.

That "timely obtaining" is the input side of the process: it determines whether you pick up an acute vulnerability within days or only months later. An external measurement complements it with the other side, your own exposure: which of those vulnerabilities put you at risk, because the vulnerable service is reachable from the outside?

What makes healthcare different

At the level of the standard, 8.8 in healthcare equals 8.8 elsewhere. The difference is in the weighting, and in healthcare that weighting is sharp.

The data is special. Personal health data is, under the GDPR, a special category of personal data, with a stricter protection regime. A vulnerability that allows access to a patient record weighs differently in the risk assessment than the same vulnerability in a system without sensitive data. NEN 7510 asks you to take that weighting into account in the risk assessment.

Continuity is critical. Care systems that go down affect the care itself directly. That makes remediating vulnerabilities a trade-off between security and availability: a patch that touches a clinical system is not simply rolled out at once. Precisely for that reason, knowing your exposure in advance is important: you want to know which systems are both vulnerable and reachable, so that the scarce maintenance window goes to the right gap.

The supply chain is broad and mandatory to keep in view. Healthcare providers lean heavily on suppliers: EHR software, hosting parties, medical devices with network connections. A vulnerability at a supplier is a vulnerability in your care process. NEN 7510 and, for the organisations that fall under it, the Cybersecurity Act require you to include that chain in your risk picture as well.

That last point touches a second framework. Part of healthcare falls under the Cybersecurity Act, in force from 15 August 2026 without a transition period: the healthcare sector is designated in NIS2. For those organisations the statutory duty of care comes on top of the standard. The two point the same way: manage your technical vulnerabilities and demonstrate that you do.

The external attack surface: where 8.8 meets the outside world

Control 8.8 covers all technical vulnerabilities, internal and external. This page, and the service behind it, focuses on the external attack surface: everything visible from the internet. There are two reasons for that which weigh extra heavily in healthcare.

First, an attacker starts there. An attacker does not see your internal network, but does see the portal where patients log in, the mail server, the appointment system, the VPN entrance. Second, that is exactly the layer a supply-chain partner or auditor can check themselves. What is visible from the outside is testable evidence.

The findings such an external measurement produces are recognisable in healthcare: expired or weakly configured TLS certificates on a patient portal, missing SPF, DKIM or DMARC records that let mail be spoofed on behalf of the organisation, exposed management services, outdated software with known CVEs, and forgotten subdomains from a project once delivered and never cleaned up. That last category, the shadow IT that arises outside the IT department's view, is a recurring find in organisations with many departments and projects.

External measurements do not cover everything: internal, authenticated vulnerabilities (missing patches on workstations, misconfigurations behind the front door) require a different approach. Fully covering 8.8 involves both layers. But the outside is the side your supply-chain partner, your auditor and the attacker see first, and it is the side that most easily translates into evidence.

Paper versus measurement: where the audit stalls

On paper, technical vulnerability management is arranged at many healthcare organisations: there is policy, there is a responsible person, there is a line about it in the information security plan. The question a NEN 7510 auditor asks is whether you can demonstrate it. That is where the picture breaks apart.

A policy document describes that management takes place. A series of dated measurements shows what was found, how it was prioritised and that it was resolved. That is the distinction between demonstrating administratively and demonstrating technically, and an auditor testing seriously asks for the second. A scan report six months old counts at best as evidence that you once looked; 8.8 asks for a process that runs.

Concretely, an auditor weighs: do you have sight of what is on the internet from you (including the forgotten systems)? Do you measure at a fixed cadence rather than once a year? Do you prioritise on real risk (with exploit likelihood and exposure alongside the severity score) or only on the bare CVSS score? Does every finding get an owner and a deadline? And, the step most easily skipped: do you re-measure to prove the gap is really closed?

How you make it demonstrable

Demonstrability is often quicker to improve than the process itself: the process is usually already there, and what is missing is the recorded evidence. Three things make a measurement usable as audit evidence:

Datability. Every finding is tied to a moment. A series of measurements over time shows the cycle, not one snapshot.
Traceability. An auditor can check where a finding comes from and that the report has not been changed since. A signed report with a reliable timestamp delivers that; a self-exported PDF does not.
Follow-up. With the finding, it is visible what happened to it: remediated, mitigated, or deliberately and substantiated accepted with a name and date.

Whoever has those three in order turns "we do technical vulnerability management" from an assertion into a verifiable statement, and that is exactly what 8.8 asks of you at an audit.

In-house or outsource?

Healthcare organisations do not always have their own security team. The measurement and signalling part of 8.8 (discovering and detecting the external attack surface, prioritising the findings and reporting on them readably) lends itself well to outsourcing; it is repetitive, tool-intensive work. What is not transferable is the decision on what you do with a finding and the ultimate responsibility for the risk. Under the GDPR and, where applicable, the Cybersecurity Act, that responsibility lies with the organisation itself; an external service delivers the measurement and the evidence, the judgement stays with you.

From that perspective, an external, measurement-driven service fits the demonstrability requirement of 8.8. Exposentry delivers that measurement and signalling part on the basis of OpenKAT, the open-source scanning platform of Dutch government origin: continuous scans of your external attack surface, with periodic, forensically substantiated reports that you use as substantiation towards your NEN 7510 auditor, your supply-chain partners or your insurer. Start with a baseline measurement that inventories what is visible from you, and let it move into a fixed cadence. View the packages or start with a baseline measurement to see where you stand.

Written by Edward Hasekamp, founder of Exposentry and collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.