Healthcare AI compliance: NEN 7510, GDPR Article 9, and deployment
May 2, 2026
When the hospital security review hits
You are a 15-person Dutch health-tech, three months into your first hospital pilot. The product works. The clinicians like it. The deal is moving toward an annual contract. Then the hospital's security team produces the document you knew was coming: a 40-page mapping of NEN 7510 controls against your AI stack, with a request to demonstrate compliance against each one.
Most founders in this position make the same mistake. They read "NEN 7510" and decide the answer is to get NEN 7510 certified themselves. They book a six-month consulting engagement at €30,000 to €80,000 plus internal effort, and tell the hospital "we will be NEN 7510 certified by Q2." The hospital nods politely and the deal moves to the next quarter, and the next.
Healthcare AI compliance is rarely solved by buying a vendor certification. The hospital is not asking whether you are NEN 7510 certified. The hospital is asking how your AI stack maps onto their already-certified NEN 7510 environment, what their General Data Protection Regulation Article 9 legal basis covers, and where the audit boundary sits. Those are architectural questions. They have architectural answers that take weeks rather than months and are structurally cheaper than a certification path.
This post is for the founder or chief technology officer at a Dutch health-tech startup whose first hospital pilot has just hit the security review. It explains what NEN 7510 actually requires of an AI infrastructure component, what GDPR Article 9 says about patient data and AI, what the hospital is responsible for under EU AI Act Article 26, and how customer-environment deployment maps onto each one. The argument is not that NEN 7510 certification is wrong; it is that for an early-stage health-tech, certification is rarely the answer to the question the hospital is actually asking.
A definition first. NEN 7510 is the Dutch information security standard for healthcare. It is built on ISO 27001, with extensions for care processes and patient safety that are specific to Dutch healthcare practice. NEN 7512 (logging) and NEN 7513 (communication) extend it. Every Dutch hospital is required to operate under NEN 7510, and they audit annually. When a hospital procures any service that touches patient data, NEN 7510 compliance is a precondition. The processor side of that procurement runs in parallel under the EU AI Act and GDPR Article 28 framing; this post focuses on the controls and the legal basis that the hospital itself has to defend.
What GDPR Article 9 actually requires
Patient data is special category data under General Data Protection Regulation Article 9(1). Processing is prohibited unless one of the ten Article 9(2) exceptions applies. For a hospital running a clinical workflow, the relevant exception is Article 9(2)(h): processing is necessary for the purposes of preventive or occupational medicine, medical diagnosis, the provision of health or social care, or treatment, under the responsibility of a professional subject to the obligation of professional secrecy.
That legal basis sits with the hospital, not with the AI vendor. The hospital established it when they took on the patient. It covers every operational system the hospital runs against that patient's data, including any AI system that operates inside the hospital's clinical workflow under the hospital's instructions. The architectural question for an AI deployment is whether the deployment becomes a separate processing operation outside that legal basis, or whether it stays inside it.
Customer-environment deployment keeps it inside. When the AI deployment runs on infrastructure the hospital owns, under the hospital's identity provider and access controls, on patient data the hospital is already lawfully processing under Article 9(2)(h), the deployment is not a new processing operation in the legal sense. It is an extension of the hospital's existing processing under the same legal basis. A public AI API does not have that property. The moment patient data leaves the hospital's environment to be processed by a vendor, a new processing operation has happened, the legal basis has to be re-established for that operation, and Article 9 starts asking different questions about who the controller is and whether the vendor's infrastructure is in scope of the hospital's professional-secrecy obligation. Customer-environment deployment removes that question by removing the new processing operation.
The hospital's question is architectural, not certificational. Answer in the right register.
Five controls that decide the security review
Most hospital security reviews focus on a small subset of NEN 7510 controls when the vendor is an AI infrastructure component rather than a clinical workflow tool. The five controls below are the ones that decide most pilots. Cover them honestly and the rest of the questionnaire usually follows.
Control 1: Access management to patient data
What NEN 7510 expects: every access to patient data is authenticated, authorized, role-restricted, time-limited, and logged. The hospital's existing identity provider is the source of truth for who is allowed to do what.
How customer-environment deployment maps onto it: when the AI deployment lives inside the hospital's own environment, access is controlled by the hospital's existing identity provider and role-based access control. The vendor does not create separate user accounts. The vendor does not authenticate against patient data. The hospital's existing access management posture extends to the AI deployment by inheritance.
What the vendor needs to provide: documentation of how the deployment integrates with the hospital's identity provider, the role-based access control rules, and the IAM audit trail format.
Control 2: Sub-processor management under General Data Protection Regulation Article 28
What NEN 7510 expects: every sub-processor in the data path is documented, contracted, and disclosed. The hospital's data processing agreement with the vendor names every party that touches patient data.
How customer-environment deployment maps onto it: when the data path is entirely inside the hospital's environment, the sub-processor list is short. The vendor providing the AI infrastructure software is not a sub-processor under EU AI Act and GDPR Article 28 if it never accesses patient data in production.
What the vendor needs to provide: a data processing agreement that explicitly names the conditions under which they would become a processor, with read access during incident response or support sessions called out so the hospital's auditor sees the full picture.
Control 3: Audit logging and retention under NEN 7512
What NEN 7510 expects, with the NEN 7512 extension: every action against patient data is logged, the logs are tamper-evident, and the retention period meets Dutch healthcare requirements (typically 7 to 15 years depending on data type).
How customer-environment deployment maps onto it: the AI deployment writes its audit logs into the hospital's existing logging infrastructure. Retention is governed by the hospital's existing policy. The vendor does not maintain a separate vendor-side log that the hospital cannot inspect.
What the vendor needs to provide: documentation of every audit-log entry the deployment writes, mapped to the NEN 7512 schema requirements.
Control 4: Incident response
What NEN 7510 expects: documented incident response process, defined notification timelines (the hospital's controller obligation under General Data Protection Regulation Article 33 is 72 hours), and a post-incident review process.
How customer-environment deployment maps onto it: incidents in the AI deployment surface in the hospital's existing monitoring because the deployment runs in their environment. The vendor's role is technical support, not data handler. Incident-response support requires re-grant of read access for the duration of the incident, logged in the hospital's IAM audit trail, and that re-grant is the precise scenario the Article 28 sub-processor framing in Control 2 has to cover contractually.
What the vendor needs to provide: an incident-response playbook that names the access pattern during incident response, the maximum duration of vendor read access, and the hand-back procedure once the incident is resolved.
Control 5: Data residency and data minimization
What NEN 7510 expects: patient data stays in jurisdictions the hospital has approved (typically the Netherlands or the European Economic Area), and is minimized to what is operationally necessary.
How customer-environment deployment maps onto it: the data never leaves the hospital's perimeter. Residency is governed by the hospital's choice of cloud region or on-premises location. Data minimization is governed by the hospital's configuration of what flows into the AI deployment.
What the vendor needs to provide: documentation that no inference data, document text, or user identifiers ever leave the customer's perimeter, plus the network egress rules that enforce that.
The EU AI Act Article 26 deployer-obligations frame for healthcare AI
NEN 7510 is the information-security floor. The EU AI Act sits on top of it for healthcare AI specifically, and changes who is responsible for which obligations.
Most clinical-workflow AI is high-risk under the Act. Article 6(1), read with Annex I's listing of Union harmonization legislation, brings AI systems that are themselves a regulated product or a safety component of one into the high-risk category. That captures AI systems qualifying as a medical device under the Medical Device Regulation, which covers most clinical-workflow AI. The Act distinguishes the provider (the entity that places the AI system on the market) from the deployer (the entity that uses the system under its own authority). Article 26 sets out the deployer's obligations, and for a clinical AI deployment those obligations land on the hospital.
Article 26 obligates the deployer to use the AI system in accordance with the provider's instructions for use, to assign human oversight to natural persons with the necessary competence, to ensure that input data is relevant and sufficiently representative for the intended purpose, to monitor the system's operation, to keep the logs the system generates for at least six months, and to inform the workforce and any affected natural persons that they are subject to the use of a high-risk AI system. Several of those obligations duplicate or extend NEN 7510 controls. The logging obligation lines up with NEN 7512. The human-oversight obligation lines up with the hospital's clinical-governance posture. The input-data obligation lines up with the hospital's existing data-quality controls.
The architectural consequence for the AI vendor is the same as it was for NEN 7510. When the deployment runs inside the hospital's environment, the deployer (the hospital) executes Article 26 against the same controls they already audit annually for NEN 7510. The vendor's responsibility is to provide the instructions for use, to keep the system within the high-risk classification it was conformity-assessed under, and to not become a deployer themselves. A public AI API blurs that line because the vendor is operating the system on the hospital's behalf, which can drag the vendor into deployer-style obligations the vendor is not contractually positioned to carry.
The certification trap
Most early-stage Dutch health-tech startups in this position spend €30,000 to €80,000 on consulting toward their own NEN 7510 audit. That spend buys them a certification badge that looks good in marketing materials and a six-to-nine-month delay on their first hospital deal. The certification does not actually answer the hospital's procurement question. The hospital's procurement question is architectural: show us that the patient-data path stays inside our environment, under our access controls, in our audit logs, under our Article 9(2)(h) legal basis, and inside our Article 26 deployer obligations.
The right answer for an early-stage health-tech is to inherit the hospital's existing NEN 7510 certification by deploying inside their environment. The hospital's annual NEN 7510 audit covers the controls that apply to your deployment because the deployment is inside their certified perimeter. Their existing GDPR Article 9 legal basis covers the patient data because the deployment is processing under the same hospital authority. Their Article 26 deployer obligations cover the operational side because they are the deployer. Your responsibility shrinks to documenting the data path, the access pattern, and the conformity assessment of the AI system you placed on the market.
deeplit® is the customer-environment deployment infrastructure for this pattern. We deploy open-weight models inside your hospital end-customer's environment, with the access pattern documented in private AI in your customer's GCP project and the audit boundary documented in EU AI Act and GDPR Article 28. The deployment is designed to support the General Data Protection Regulation, the EU AI Act, and the architectural controls of NEN 7510 by inheritance. We are not NEN 7510 certified ourselves; we do not need to be, because we are not in the data path.
What the hospital procurement team is actually asking is whether one architectural choice can answer four regulatory frames at once. Customer-environment deployment does. The patient-data path stays inside the hospital's perimeter, NEN 7510 controls cover the deployment by inheritance, the Article 9(2)(h) legal basis covers the processing, and the Article 26 deployer obligations stay on the deployer. The certification path costs months and money and does not answer any of those four questions better than deploying inside the hospital's environment does on day one.
If your first hospital pilot has hit the security review and you have eight to twelve weeks before the deal slips, the next step is a thirty-minute deployment call. Bring the hospital's NEN 7510 control list and we will walk through it with you. Book a deployment call.
If the hospital's information security officer is the one asking, this post is written to be forwarded to them. The architectural framing is theirs to use; the inheritance argument is theirs to cite.
The hospital's question is architectural, not certificational. Answer in the right register.
A NEN 7510 certificate proves you can handle patient data. Deploying inside the hospital's environment proves you do not need to.
Frequently asked questions
Does deeplit® hold NEN 7510 certification?
No. The deployment runs inside your hospital end-customer's environment, where their existing NEN 7510 controls apply. Our role is shipping the deployment software and the operational tooling, not processing patient data in production. The certification burden stays with the hospital, where it already exists.
Can a 15-person startup get NEN 7510 certified themselves?
Yes. The Dutch consulting market for NEN 7510 implementation exists at €30,000 to €80,000 of typical investment over six to nine months. The question is whether it answers the hospital's actual procurement question, which is architectural rather than certificational. If your AI stack is structurally outside the hospital's environment (a public AI API, your-own-cloud deployment), you may need certification to compensate. If your AI stack is inside the hospital's environment, the inheritance argument is usually stronger.
Does the hospital's existing NEN 7510 certificate cover our deployment by inheritance?
When the deployment lives inside the hospital's environment under their access controls and writes to their logging infrastructure, yes, the inheritance argument applies. The hospital's annual NEN 7510 audit covers the controls that apply to the deployment. Document the inheritance argument in your data processing agreement so the hospital's compliance team has a contractual artifact to point to.
What about NEN 7512 and NEN 7513?
NEN 7512 covers logging and NEN 7513 covers communication. Both extend NEN 7510 and matter for AI deployments that touch patient data. Customer-environment deployment makes both demonstrable using the hospital's existing logging and network infrastructure. The vendor's responsibility is documenting the log schema and the network egress posture.
Does GDPR Article 9 require the AI vendor to have a separate legal basis for processing patient data?
Not when the deployment is structured so that the vendor is not processing patient data. The hospital's General Data Protection Regulation Article 9(2)(h) legal basis covers the patient data they are already lawfully processing under their professional-secrecy obligation. Customer-environment deployment keeps the AI processing inside that legal basis because the deployment is not a separate processing operation outside the hospital's authority. A hosted-API deployment forces a new processing operation to be established and a new Article 9 exception to be defended; an in-environment deployment does not.
