31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
NEN 7510 Penetration Testing: What Dutch Healthcare Providers and Their Suppliers Must Test, and Why the Law Says So
NEN 7510 is the Dutch information security standard for healthcare, and since 2018 it has been mandatory by decree for every care provider that processes patient data electronically. Its controls on vulnerability management and security testing are where the penetration test comes in. This guide covers the standard, the legal basis, the regulators, the related frameworks and how to scope a test that satisfies all of them.
What NEN 7510 is and who must comply
NEN 7510 is the Dutch standard for information security in healthcare, published by NEN, the Royal Netherlands Standardization Institute. The current edition is NEN 7510:2024, in two parts. NEN 7510-1 sets the requirements for an information security management system and follows the structure of ISO/IEC 27001:2022, with healthcare-specific additions. NEN 7510-2 contains the controls and implementation guidance and follows ISO/IEC 27002:2022, again extended with controls that only make sense in care: logging of access to patient records, unique identification of patients, handling of medical devices, and the duty of care that underpins all of it. Organisations certified against the 2017 edition are transitioning to the 2024 edition within the period NEN and the certification bodies have set.
Unlike ISO 27001, which is voluntary unless a customer or regulator demands it, NEN 7510 is law for Dutch healthcare. The Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg (Wabvpz) and the Besluit elektronische gegevensverwerking door zorgaanbieders, in force since 1 January 2018, require every care provider that uses an electronic exchange system or an electronic patient record to comply with NEN 7510, NEN 7512 (secure electronic communication between parties) and NEN 7513 (logging of access to patient data). That covers hospitals, mental health institutions, general practices, pharmacies, laboratories, nursing and home care organisations, independent treatment centres, and the regional and national exchange infrastructures that connect them. The Wet elektronische gegevensuitwisseling in de zorg (Wegiz), in force since 2023, builds on the same norms for mandated data exchanges.
Suppliers are pulled in by contract and by certification. Electronic patient record vendors, hosting providers, patient portal platforms, personal health environment (PGO) providers and exchange service providers are expected to hold NEN 7510 certification, and healthcare customers write that expectation into procurement. In practice the supplier's penetration test often serves several hospitals at once, in the same way a third-party memorandum does in a DigiD assessment.
The controls that call for a penetration test
NEN 7510-2 follows the ISO/IEC 27002:2022 control set. None of these controls uses the words penetration test, and all of them are practically impossible to evidence without one.
Management of technical vulnerabilities (control 8.8)
The organisation must obtain information about technical vulnerabilities in the systems it uses, evaluate its exposure and take appropriate measures. In a hospital environment this covers the electronic patient record, the portal, the integration engine, the imaging systems, the lab systems and the medical devices on the clinical network. Scanning tells you which versions are installed. A penetration test tells you which vulnerabilities are reachable and exploitable from the positions an attacker can realistically occupy: the internet, a compromised workstation, a guest network or a connected device.
Security testing in development and acceptance (control 8.29)
New and changed systems must be security-tested before acceptance. Hospitals rarely build their own record systems, but they configure, integrate and extend them constantly: new FHIR endpoints for a PGO connection, a new e-consult module, an upgraded portal. Each of those is a change that control 8.29 expects to be tested before patients use it, and a penetration test on the acceptance environment is the recognised way to do that.
Compliance with policies, rules and standards (control 5.36)
Managers must regularly review whether systems comply with the organisation's security policies and standards. Technical compliance review is the operational form of this control, and it is the one auditors cite most often when they ask for the latest penetration test report. A policy that says all externally reachable systems are hardened to the NCSC guidelines is only a policy until a test confirms it.
Healthcare-specific controls on access and logging
NEN 7510 adds requirements on access to patient data (need-to-know, role-based access, emergency access with justification) and on logging that access in accordance with NEN 7513. These controls fail silently: an authorisation flaw in a portal or an API that lets one patient read another's record is invisible in the logs until someone exploits it. Testing authorisation at the level of the individual patient record is the single most important healthcare-specific element of a NEN 7510 penetration test.
Supplier relationships (controls 5.19 to 5.22)
The standard requires security to be addressed in supplier agreements and monitored throughout the relationship. For a care provider that means asking suppliers for their penetration test reports, checking their scope against what you actually use, and testing the interfaces and configurations that are yours. For a supplier it means having a test report that is good enough to hand over.
The healthcare attack surface: what a NEN 7510 test typically scopes
A hospital or care organisation has an attack surface that few other sectors match: clinical systems that cannot go offline, devices with decade-long lifecycles, and dozens of external exchange partners.
Electronic patient record (EPD/ECD) and the systems around it
The record system itself, the integration engine that routes HL7 v2 and FHIR messages, the lab and pharmacy systems, PACS and DICOM imaging, and the reporting warehouses. Tested from an assumed-breach position on the internal network: what can a compromised workstation or contractor account reach, and does segmentation hold?
Patient portals and e-health applications
Portals where patients view results, book appointments, message clinicians and upload documents, usually behind DigiD or another identity provider. Tested for authorisation between patients, session management, file handling, business logic and the identity federation itself.
HL7 FHIR APIs and PGO connections
The FHIR endpoints that expose patient data to personal health environments under the MedMij scheme, to other providers and to apps. Tested for OAuth 2.0 and OpenID Connect implementation flaws, token scope and lifetime, resource-level authorisation, and the search and bulk operations that make FHIR convenient and dangerous.
Medical devices and the clinical network
Infusion pumps, monitors, imaging modalities and lab analysers on the clinical network, many running software that cannot be patched on a normal cycle. Tested without disrupting care: passive discovery, segmentation verification, and controlled testing of management interfaces, in line with IEC 81001-5-1 expectations for manufacturers and the MDR obligations that apply to them.
Mobile apps and remote access
Patient and clinician apps, remote access for staff working from home, VDI environments and the identity infrastructure (Active Directory, Entra ID) that ties them together. Tested along the OWASP MASVS for the apps and from the perspective of a stolen device or phished credential for remote access.
Secure e-mail and exchange services (NTA 7516, NEN 7512)
The services used to exchange health data by e-mail and with external parties, which NTA 7516 and NEN 7512 govern. Tested for configuration (SPF, DKIM, DMARC, TLS enforcement), the portal components of secure mail products, and the integrity of the exchange chain.
Where penetration testing appears across the healthcare frameworks
A Dutch care provider rarely answers to one framework. The same test, scoped with care, evidences most of them.
| Framework | Who it binds | Where the test shows up |
|---|---|---|
| NEN 7510:2024 | All Dutch care providers (by decree) and, via contract, their suppliers | Controls 8.8, 8.29 and 5.36, plus healthcare-specific access and logging controls; certification audits ask for the latest report |
| Besluit elektronische gegevensverwerking door zorgaanbieders | Care providers using electronic exchange systems or records | Makes NEN 7510, 7512 and 7513 mandatory; the IGJ supervises compliance |
| MedMij scheme | PGO providers and healthcare data service providers in the scheme | Information security requirements include demonstrable security testing of the MedMij-facing environment as part of qualification and the annual cycle |
| NTA 7516 | Providers and users of secure e-mail for health data | Technical requirements evidenced through testing of the mail and portal components during certification |
| ISO/IEC 27001:2022 | Organisations that choose to certify, often alongside NEN 7510 | Annex A controls A.8.8, A.8.29 and A.5.36 map one-to-one to the NEN 7510-2 controls |
| NIS2 / Cyberbeveiligingswet | Healthcare providers that are essential or important entities | Article 21(2)(f): policies and procedures to assess the effectiveness of cybersecurity risk-management measures |
| GDPR / AVG | Every controller and processor of health data | Article 32(1)(d): a process for regularly testing, assessing and evaluating the effectiveness of security measures |
What NEN 7510 auditors and the IGJ expect to find
Certification auditors and the Health and Youth Care Inspectorate look for the same evidence trail. Have it ready before the audit, not during it.
- A risk-based testing plan that names which systems are tested, how often and at what depth, with the electronic patient record, portals, APIs and externally reachable systems covered at least annually
- The most recent penetration test report for each of those systems, with scope, dates, named tester, methodology and findings
- Evidence that findings were triaged, assigned, remediated within the deadlines your policy sets, and retested
- Authorisation testing at patient-record level, because that is where NEN 7510's access and logging controls are most exposed
- Supplier test reports for hosted record systems and portals, with your own review of their scope against what you use
- Testing of changes before acceptance (new modules, new integrations, new FHIR endpoints), traceable in change management
- A link between test findings and your NEN 7513 logging: were the exploited actions visible in the access logs, and would they have been detected?
- For NIS2 entities: the test programme referenced in the cybersecurity risk-management framework your board has approved
Combining NEN 7510 with ISO 27001 and NIS2 in one testing programme
Most Dutch hospitals and larger care organisations hold NEN 7510 certification and increasingly ISO 27001 as well, often from the same certification body in a combined audit. Because NEN 7510-2 follows the ISO 27002:2022 control set, one penetration test programme evidences both, provided the scope statement names the systems in both management system scopes and the report cites the controls. Suppliers that serve care providers and other sectors benefit most: one annual programme, one report structure, two certificates.
NIS2 adds the board. Healthcare providers are listed in Annex I of the directive, so hospitals and other large providers are essential entities, and the Cyberbeveiligingswet, the Dutch transposition, makes the management body responsible for approving and overseeing the cybersecurity risk-management measures. Article 21(2)(f) requires policies and procedures to assess the effectiveness of those measures, and Article 21(2)(e) covers security in acquisition, development and maintenance, including vulnerability handling. A penetration test programme that is approved by the board, executed on schedule and reported upward satisfies both. The practical change is that test results now need a management summary the board can act on, not only a findings list for the IT department.
Z-CERT, the Dutch computer emergency response team for healthcare, is the sector's hub for threat intelligence and incident coordination and plays a formal role in the NIS2 structure for the sector. Their sector-specific threat picture is a useful input for scoping: the ransomware groups, initial access techniques and exposed services they report are the scenarios a realistic test should include.
How we test in healthcare
Healthcare testing has one constraint other sectors do not have: patient safety comes before test coverage. We scope with the CISO, the clinical application managers and, where devices are involved, the medical technology department. Production systems are tested within agreed windows with a named escalation contact, medical devices are tested with manufacturer guidance and never with active exploitation on a device in clinical use, and test accounts are created with synthetic patient data so no real record is touched. Where a test must run on production, for example a portal behind DigiD, the coupling is exercised against the identity provider's pre-production environment.
The report cites the NEN 7510-2 control, the ISO 27001 Annex A control and, where relevant, the MedMij or NTA 7516 requirement per finding, so your information security officer files it once and your certification auditor, your supplier manager and your board each read the section written for them. The lead tester is OSCP-certified and named, the retest is part of the engagement, and we deliver before your audit date, not after it.
Frequently asked questions
Preparing for a NEN 7510 audit or a MedMij qualification?
We scope healthcare tests with patient safety first, cite the NEN 7510-2 control per finding and deliver before your audit date. Talk to an expert.