What GDPR asks of healthcare providers and health tech in practice
A clinic or health tech company usually meets GDPR when a customer, a hospital contract or a supervisory authority asks for proof. The first point to understand is that GDPR requires no audit, attestation or certificate. Health data is a special category under Article 9, so processing it is prohibited unless an Article 9(2) exception applies, and the work is showing a supervisory authority that processing is lawful, access is controlled and breaches are handled properly. Cost and timeline depend on the systems in scope, where they are hosted, which processors touch the data and which national rules apply, because Member States may add conditions for health data under Article 9(4). Ask any consultant to price the work against a written list of systems, hosting locations and processors rather than against a general headcount.
Each cost component has a clear owner. The organization, as controller, owns its compliance decisions, lawful basis, records and staff training. An implementation partner can prepare systems and evidence, such as role-based access to patient records, multi-factor authentication for remote access, logging and tested restore procedures. Only an independent auditor or certification body issues any report or certificate, and Article 42 certification, where it is available, is voluntary and does not transfer responsibility away from the controller. Ask each supplier which items are one-time setup, such as configuration and documentation, and which recur, such as log review, access recertification and annual testing. Confirm with the vendor and your national supervisory authority which add-on rules apply to your data before fixing scope.
Start with the access model, because it is where regulators have found the most direct failures. Under Article 9(3), health data may be processed for care only by or under the responsibility of a professional bound by secrecy, and the EDPB small business guide's example of patient files open by default only to treating doctors shows the same principle of data protection by default. Check whether remote and external access to patient records goes through a VPN with multi-factor authentication, and whether access rights follow the actual care-team need to know. In a 2026 CNIL decision, a EUR 500,000 fine against Hôpital Privé de la Loire cited external access without a VPN or multi-factor authentication and access control that ignored care-team need to know. The same decision also faulted the failure to inform 202,246 people designated as trusted third parties whose data were stolen, so your breach communication plan must cover every affected group, not only patients.
Which healthcare roles carry which GDPR duties
A solo physician or small practice that decides how patient records are kept is usually the controller for those records. The role matters because the controller owns the lawful basis, the security measures and the duty to answer patient rights requests, even when a software vendor hosts the system. Processing health data is a special category under Article 9(1), so the Article 9(2)(h) care exception applies only when the data is handled by or under the responsibility of a professional bound by professional secrecy, as Article 9(3) requires. Whether a DPIA or DPO is required depends on whether the processing is large-scale and whether it forms a core activity. A small practice that treats a limited number of patients may fall below that threshold, but the record-keeping exemption in Article 30(5) is still lost, because processing special category data takes an organization out of that exemption regardless of headcount.
- Controller role: the practice decides purposes and means for its patient files, even when a cloud vendor stores them.
- Article 9(2)(h) care exception: access to health data should be limited to professionals bound by secrecy, supported by written access rules.
- DPIA trigger: large-scale processing of special category data requires a DPIA under Article 35(3)(b), so confirm whether your patient volume and record sharing count as large scale.
- DPO trigger: a DPO is required under Article 37(1)(c) where large-scale processing of special categories is a core activity, which is common for a practice whose main business is patient care.
- Record of processing: because the Article 30(5) exemption does not apply, keep a written record of processing activities.
Confirm with your national supervisory authority and professional body how your country adds conditions for health data under Article 9(4).
A hospital or clinic group usually acts as controller for patient data across its sites, and it may act as joint controller with affiliated entities that share a patient record system. Scale and integration are the main differences from a single practice. Large-scale processing of health data across many departments, staff and systems is the typical case that triggers a DPIA under Article 35(3)(b), and the health and social care activity at the core of the organization usually meets the core-activity test in Article 37(1)(c), so a DPO is normally required. The enforcement record shows why access design matters: the CNIL fined Hôpital Privé de la Loire EUR 500,000 (decision of 3 September 2026) under Articles 32 and 34, citing external access to its patient record system without VPN or multi-factor authentication and access control that ignored the care team's need to know.
- Joint controllers: where affiliated entities share one patient record system, define responsibilities in a written arrangement that identifies who answers patient requests.
- DPIA trigger: multi-site, multi-department processing of health data is typically large scale under Article 35(3)(b).
- DPO trigger: health care is the core activity, so a DPO is normally required under Article 37(1)(c), and the DPO should have resources and independence.
- Access by need to know: role-based access tied to care teams, with remote access controlled by VPN and multi-factor authentication.
- Record exemption: the Article 30(5) exemption is unavailable, so the group must maintain its records of processing.
Check whether each entity in the group is a separate controller and whether your national rules add conditions under Article 9(4).
A health tech vendor that hosts or operates software for clinics and hospitals is usually a processor under Article 28, acting on the customer's instructions. The vendor still carries direct duties. Article 32 security obligations apply to processors as well as controllers, and the processor must notify the controller of a personal data breach without undue delay. A DPIA is typically the customer's responsibility, but the vendor must supply information the customer needs for it. Whether the vendor must appoint a DPO depends on its own processing: a vendor that processes health data for many customers on a large scale, as a core activity, may meet the Article 37(1)(c) test in its own right. The Article 30(5) exemption is lost for the same reason as for controllers, because the vendor processes special category data for its customers.
- Processor role: the vendor processes patient data on documented customer instructions, with a contract covering those instructions and sub-processors.
- Security of processing: Article 32 applies to the vendor directly, including access control, encryption and logging for support access.
- Breach notice: the vendor must inform each customer controller of a breach so the controller can meet its own notification duties.
- DPO check: a vendor should assess whether its own large-scale health data processing makes a DPO mandatory under Article 37(1)(c).
- Records: the Article 30(5) exemption does not apply, so keep records of the processing carried out on behalf of customers.
Confirm with each customer which party determines purposes, because a vendor that uses patient data for its own product improvement may become a controller for that use.
Why access by default decides most patient record findings
Access by default is where data protection by default meets the daily workings of a clinic. The EDPB's small business guide uses a medical practice example in which patient files are accessible by default only to the treating doctors. The point is not the wording of a policy but the starting state of the system: anyone outside the treating team should need a deliberate step to see a file. Illustratively, a clinic whose record system opens every patient file to all staff accounts, billing contractors and visiting specialists has the reverse default. The reader's first task is to compare each role in the record system with the care team it actually serves, and to check whether the defaults in the record system and any remote access tool match that picture.
In September 2026 the French CNIL fined Hôpital Privé de la Loire EUR 500,000 under Articles 32 and 34 (decision of 3 September 2026). According to the regulator's findings, external access to the patient record system lacked a VPN and multi-factor authentication, and the access control ignored the care team's need to know. This is a regulator's finding about one controller's facts, not a rule that every provider must use a particular VPN or authentication method. Article 32 asks for measures appropriate to the risk, and the decision shows how a supervisory authority reads a gap between open remote access and clinical need. The EDPB's news item on the decision is the natural next read for the full context.
Two checks follow from this. First, list every path that reaches the record system from outside the clinic, including vendor support sessions, and confirm that each path requires strong authentication and is limited to named roles. Second, test whether a user outside a care team can open a file without a documented reason, and whether such access is logged and reviewed. The same decision also faulted the hospital for not informing directly the people whose data were stolen, so weak access controls carry notification duties as well as security duties. Confirm with your national supervisory authority and any national conditions for health data under Article 9(4) before setting the final rules.
What a healthcare organization must have in place before an assessment
A supervisory authority reviewing health data usually starts with the same questions: who can see which records, how remote access is controlled, whether access is logged, and whether the organization can act on a breach quickly. The cards below cover the controls and documents that answer those questions, with the evidence an assessor or customer auditor will ask to see.
Role-based access tied to care teams
Access to patient records should follow the care team's need to know, not the job title of the whole department. Under Article 9(3), only professionals bound by secrecy may process health data for care, so the access model must separate treating clinicians from administrative and support staff. Check this by sampling user accounts against current rota or care-team assignments and by testing whether a user outside the team can open a file. Assessors will ask for the role matrix, the approval trail for access grants, and the results of recent access reviews.
Remote access through controlled channels
The CNIL's EUR 500,000 fine against Hôpital Privé de la Loire cited external access to a patient record system that lacked VPN and multi-factor authentication. Every route into the record system from outside the network should pass through a managed gateway that enforces multi-factor authentication, and vendor or support accounts should be included. Check this by attempting a login from an unmanaged device and confirming it is refused. Assessors will ask for the remote access architecture, MFA enforcement settings, and the list of third-party accounts with their approval records.
Logging of record access
Article 32 expects the controller to be able to show who accessed what and when, and logs are how that is shown. Logs should record each read, change and export of a patient record, with user identity, timestamp and the record concerned, and they should be stored where administrators cannot alter them. Check this by picking a patient file and confirming that every access in the past period is attributable to a named user. Assessors will ask for log retention settings, samples of access logs for specific records, and the procedure for reviewing unusual access, such as staff opening records of colleagues.
Tested breach notification path
A breach notification plan works only if the people named in it can act within the time limits. Article 33 requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours, and Article 34 requires direct communication to affected individuals when the risk is high. The Hôpital Privé de la Loire case included a failure to inform 202,246 people who had been designated as trusted third parties, whose data were also stolen. Check this by running a tabletop exercise that includes contact lists for individuals, not only the regulator. Assessors will ask for the tested plan, the exercise record, and the template notices.
A DPIA on file
Large-scale processing of special categories requires a data protection impact assessment under Article 35(3)(b), and most hospital and health platform processing will meet that threshold. The DPIA should describe the processing, the necessity and proportionality of each data flow, the risks to patients, and the measures that reduce them, including the access and logging controls above. Check this by confirming the DPIA covers current systems, not the original deployment, and that it is reviewed when systems change. Assessors will ask for the signed DPIA, its review dates, and evidence that the listed measures are actually in place.
A documented DPO decision
Article 37(1)(c) requires a data protection officer where the core activity involves large-scale processing of special category data, so a provider whose core business is patient care usually needs one. A smaller practice or health tech vendor should record its reasoning either way, including why its processing is not a core activity or not large scale. Check this by reviewing the written decision and confirming the named officer has resources, independence and no conflicting role. Assessors will ask for the designation letter or the written justification, the officer's contact details published to the supervisory authority, and the reporting line to senior management.
How a breach affecting third parties changes notification work
The sequence turns a detected incident into a documented decision, a supervisory authority notice within 72 hours where required, and direct communication to everyone whose data was taken, including people the organization never treated as patients.
Detect and log the incident with its scope
The security or operations team records the suspected incident in the breach register as soon as it is detected, with the time of discovery, the systems involved and the first view of what data may be affected. Name one incident owner and the data protection contact so the clock and the decisions have a clear owner. The step is done when the register entry exists and the owner has acknowledged it in writing. Keep the entry open, because the facts will change as the investigation proceeds.
Map the data and every person it touches
Identify which patient, staff and third-party records were accessed or taken, and trace each data set to the people it describes. Include people who are not patients, such as relatives, guarantors or persons designated as trusted contacts, because their personal data may sit in the same records. The output is a data inventory tied to categories of individuals, with a note on whether any Article 9 health data is involved. Confirm the list with the system owners before it is used for notices.
Confirm third-party roles and obtain their facts
Where a processor, hosting provider, remote support firm or other third party operated the affected system, establish in writing what it knows and when it told you. Processors must notify the controller without undue delay, so the record should show the date of that notice. Ask each third party to supply the systems, logs and counts it holds, and confirm which entity is the controller for each data set. The step closes with a signed-off fact sheet that the controller has checked.
Record the risk decision and the 72-hour clock
Assess whether the breach is likely to result in a risk to the rights and freedoms of individuals, and record the reasoning, the time of awareness and any reasons for delay. Where a notice to the supervisory authority is required, it is due within 72 hours of awareness under Article 33, so the decision must be made and dated inside that window. The output is a signed decision record that states yes or no to notification and why. A decision not to notify still needs to be documented.
Build the complete list of affected individuals
Before notices are sent, reconcile the data inventory with the extraction logs and the third-party counts to produce one list of every affected individual, grouped by category and by how each person can be contacted. Do not limit the list to people the organization has a direct patient relationship with. The check is that the total in the list matches the counts from the investigation and that the gaps are recorded as open items. Where the full list is not yet known, the record should say so and set a plan to complete it.
Send the supervisory authority notice in phases
Submit the notice to the competent supervisory authority with the information Article 33 asks for, including the nature of the breach, the categories and approximate numbers of people and records affected, likely consequences and measures taken. Where all details are not yet available, provide them in phases and record the later updates against the original notice. Keep a copy of what was sent, when, and to which authority, as part of the breach documentation.
Communicate directly with each affected person
Where the breach is likely to result in a high risk to individuals, Article 34 requires communication to them without undue delay, in clear language that describes the consequences and the steps they can take. Send notices directly to every person on the reconciled list, using the channels the list records. The Hôpital Privé de la Loire case shows the gap this step closes: 202,246 people designated as trusted third parties, whose data was also stolen, received no direct information, and the CNIL cited that as a separate failure under Article 34. The step closes when delivery records exist for every name on the list.
Document the breach and close the register entry
Update the breach register with the full chain of decisions, notices, dates, the list of affected individuals and the corrective measures, then link the evidence files. Review the entry with the data protection officer or the responsible person and record lessons that change the inventory, contracts or access controls. The entry closes only when the notices, delivery records and corrective actions are all filed. Keep this record available for supervisory authority requests.
Who is paid for what in GDPR health data work
This table shows who is paid for each part of GDPR health data work, whether the cost is one-time or recurring, and what changes the price. Use it to decide which roles to buy in and what to ask for in each quote, since no external certificate is required and the controller stays responsible for compliance.
| Role | Who is paid and for what | One-time or recurring | What drives the cost |
|---|---|---|---|
| Supervisory authority or external auditor | Nobody is paid for a GDPR certificate, because none is required. An independent assessor is paid only if the organization chooses an Article 42 certification or a voluntary review. | Optional, and usually one-time per review cycle | Scope of processing, number of systems, whether certification is pursued, and the assessor's accreditation. Ask whether the scope covers remote access and logging. |
| Data protection officer (internal or outsourced) | Internal staff are paid through salary. An outsourced DPO is paid a service fee for the minimum tasks in Article 39, plus any advisory time on incidents. | Recurring, for the life of the processing | Mandatory when core activities involve large-scale health data (Article 37(1)(c)). Volume of patient records, number of sites, and incident load. Ask what tasks and response times the fee covers. |
| DPIA author | Internal privacy or security staff, or an external consultant, is paid to describe processing, assess risk and record mitigations. | One-time per processing activity, then recurring reviews when processing changes | Number of health data flows, new clinical or telehealth systems, and whether high residual risk triggers prior consultation. Ask for the deliverables and the review trigger list. |
| Implementation partner for access control and logging | A systems integrator or platform partner is paid to configure role-based access, multi-factor authentication, VPN or zero-trust remote access, and audit logs in the client's own environment. | Mostly one-time build, then recurring support and upgrades | Number of applications, identity systems in use, external access paths, and log retention needs. Ask for a fixed scope, named deliverables and a written test plan. |
| Legal counsel for national add-ons | Lawyers in each Member State are paid to review national conditions for health, genetic and biometric data under Article 9(4), and professional secrecy rules. | Recurring when national rules change, otherwise one-time review | Number of countries where patients or staff are located, and the number of processing purposes. Ask which national conditions the advice covers and how updates are handled. |
| Internal staff time | Clinicians, IT administrators and managers are paid through existing payroll for training, access reviews, and incident drills. | Recurring, usually as periodic reviews and training cycles | Headcount with patient record access, frequency of access reviews, and staff turnover. Ask the implementation partner to size the training and handover work in the quote. |
| Trusted third parties and processors | Vendors that host or support health systems are paid under processor contracts, and they may add their own sub-processor and remote support costs. | Recurring subscription or support fee | Remote support from outside the EEA, sub-processor chains, and contract terms for audit rights. Ask for the processor agreement and remote access model before signing. |
Who owns controls, who prepares evidence, and who issues findings
The controller is the organization that decides why and how patient data is processed, and it carries the legal duties under the GDPR. No vendor, consultant or auditor can take those duties over. For a hospital, clinic or health tech company, the controller's management must decide the lawful basis and Article 9 condition for each processing activity, approve risk decisions, sign off DPIAs, and answer to regulators when something goes wrong.
- Legal and privacy decisions: choosing the Article 9(2) condition, setting retention and access rules, and deciding whether a breach must be notified.
- Role of the DPO: where a data protection officer is required, the DPO advises and monitors but the controller remains accountable.
- Clinical and operational owners: defining which care teams need which records, which is the basis for access by default.
- Contracts: signing processor agreements and approving sub-processors, including any remote support provider.
- Ownership of evidence: keeping the record of processing, DPIAs and policies current.
Check that each control in your register has a named internal owner who can explain it to a regulator without relying on a vendor.
An implementation partner such as DeployOpen works inside the controller's or processor's infrastructure to configure, harden and document the systems that process health data. The partner prepares technical controls and evidence under a written scope. It does not decide the legal basis, sign the DPIA on the controller's behalf, or certify compliance.
- Access control build-out: role-based access aligned to care-team need, multi-factor authentication and gated remote access.
- Logging and monitoring: configuring audit trails that show who opened which patient record and when.
- Backup, restore and encryption: setting up and testing recovery and encryption for patient data at rest and in transit.
- Documentation: producing configuration baselines, architecture diagrams and test results that feed the DPIA and the Article 32 evidence file.
- Testing: security testing of the patient-facing and remote access paths before go-live.
Ask any partner to state in writing which items it delivers and which remain with your internal owners.
Supervisory authorities such as national data protection authorities investigate complaints and breaches and can impose fines under Article 83. The GDPR requires no audit, attestation or certificate, so no assessor is needed to be lawful. Where an organization wants independent assurance, only an independent auditor or an accredited certification body can issue a report or certificate. GDPR certification under Article 42 is voluntary, is issued for at most three years, and does not reduce the controller's or processor's responsibility for compliance.
- Regulator role: investigations, orders and fines, which are the outcome that health data cases most often reach.
- Independent assessment: an external reviewer can test your controls and report, but the report is the assessor's, not the vendor's.
- Article 42 certification: voluntary, time-limited and issued only by accredited bodies or authorities.
- Typical outsourcing: external privacy audits and gap assessments are often bought from specialist firms, while the findings still belong to the auditor.
- Responsibility stays put: a certificate never shifts liability away from the controller.
Before buying an audit or certification, confirm with the body that it is accredited for the scope you need.
Questions healthcare buyers ask before outside help
Is a data protection officer mandatory for a small medical practice?
It depends on whether the practice's core activity is large-scale processing of special category data, and that is the test to confirm first. Article 37(1)(c) requires a DPO where core activities consist of large-scale processing of special categories such as health data. A single practice treating patients is not automatically large-scale, but a multi-site group, a telehealth service or a health app processing records for many patients may be. Practices below that threshold are not exempt from GDPR duties. Processing health data also removes the Article 30(5) record-keeping exemption for organizations with fewer than 250 employees, so a written record of processing is expected regardless. Ask the outside party to document the DPO threshold analysis in writing, and check your national supervisory authority's guidance for how it reads 'large-scale' in practice.
Does an electronic health record system always need a DPIA?
Large-scale processing of special category data requires a data protection impact assessment under Article 35(3)(b), and an electronic health record system almost always involves that kind of processing. Most EHR deployments therefore need a DPIA before go-live, covering the processing purposes, necessity, risks to patients and the measures that reduce them. The assessment should include access design, remote access, logging, backup and sub-processors. If residual risk stays high after mitigation, Article 36 requires prior consultation with the supervisory authority. Confirm with your national authority whether it publishes a mandatory DPIA list that adds requirements for health settings.
What drives the cost of GDPR compliance for a healthcare organization?
The main cost drivers are the number of systems holding health data, how many sites and staff roles access them, how many processors and sub-processors are involved, and how much documentation already exists. Costs fall into one-time work such as the DPIA, record of processing, access model redesign and remote access hardening, and recurring work such as DPO time, access reviews, log review and training. Outside help is usually paid for a fixed scope covering systems, deliverables and timelines, agreed in writing before work starts. No fee figure is given here because none was supplied. Ask any provider for a quote that lists each system in scope, each deliverable, who performs each task, and which items are one-time versus recurring.
How do national health data rules change the work?
Article 9(4) allows Member States to keep or introduce further conditions and limitations for genetic, biometric and health data, so the same system can need different rules in different countries. Those national conditions can affect where data may be stored, who may access it, how long records must be kept, and what consent or secrecy rules apply. In practice, map every country where patients are treated or data is processed, then check each national health data law and supervisory authority guidance before finalizing the access model and retention design. Confirm these rules with local counsel, since this page does not set out national requirements.
Is a health tech vendor a processor or a controller?
A health tech vendor is usually a processor when it handles patient data on behalf of a provider that decides why and how the data is used, but the role depends on the actual facts of each service. Under GDPR, processors act on documented instructions and must sign a contract covering the controller's terms, sub-processors and security. If the vendor uses patient data for its own purposes, such as product analytics or model training, it may be a controller for that processing. Check the contract, the data flows and any sub-processor chain before deciding. Ask the vendor to show which processing it does for itself and which it does for you.
How long does GDPR preparation take and what does the work need from us?
Preparation time depends on system count, existing documentation, access model complexity and how many decisions need management sign-off, so no duration is given here. The organization must provide system owners, a named internal contact, access to current configurations, access lists by role, existing policies, contracts with processors, and decisions on retention and access. Expect the work to depend on your internal reviewers as much as on the outside team. Agree on milestones, deliverables and a sign-off process in the written scope before work starts, and ask the provider which tasks remain your responsibility after handover.
Can an outside partner certify that we are GDPR compliant?
No. GDPR requires no audit, attestation or certificate, and an implementation partner does not issue reports or certificates. Certification under Article 42 is voluntary, issued by accredited certification bodies or supervisory authorities for at most three years, and it does not reduce your responsibility for compliance. The organization owns its controls. A partner can prepare systems, controls and evidence, such as access configuration, logs, DPIA drafts and records of processing, so that your DPO and any external reviewer can assess them. Confirm the scope of any outside review in writing before you start.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so health data stays where your controls apply. We prepare the systems, access controls and evidence that support your GDPR position, while your organization owns its controls and decisions and an independent assessor or the supervisory authority reviews them.
How we scope
- Each engagement starts with a written scope covering the systems that hold or reach patient data.
- We map which care teams need access to which records, so access rules reflect actual clinical need.
- Scope also records remote access paths, including external support and third-party connections, before any build work starts.
How we build
- We configure remote access through VPN and multi-factor authentication, with no direct external path into patient record systems.
- Role-based access is set so treating staff see their own care team's records by default, with logging of every access.
- Hardening, encryption and backup and restore are built to the risk assessment agreed for your environment.
How we hand over
- You receive configuration records, access matrices, logging setup and test results mapped to the agreed scope.
- Documentation covers the controls you own, so your DPO and security team can review and maintain them.
- Breach response runbooks, including the steps to identify and inform affected individuals, are handed over for your own review and approval.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Security testing of applications, APIs and infrastructure can be scheduled to check remote access and access control changes.
- Before any assessment, confirm with your auditor or supervisory authority which evidence they expect, since DeployOpen does not issue reports or certificates.
