How to Choose GDPR-Compliant Clinic Software (2026)

How to Choose GDPR-Compliant Clinic Software (2026 Checklist)

Every clinic software vendor in the EU market claims GDPR compliance. The phrase is easy to print on a marketing page and hard to verify without deliberate evaluation. For clinic owners and practice managers responsible for patient data, "GDPR-ready" on a vendor's website is a starting point for due diligence, not the conclusion of it.

This guide provides a practical, evidence-based framework for evaluating clinic software against the requirements that matter for an EU clinical practice — from lawful basis support to subject access request handling, from access controls to incident response. It is designed to help you ask the right questions and test the right workflows before signing a contract, not after.

Why Clinic Software Is a High-Stakes GDPR Decision

Clinical practices process special-category personal data under GDPR Article 9 — health data, which carries the most stringent obligations in the regulation. The lawful basis for processing patient health data for clinical care is Article 9(2)(h), but this basis has conditions: the processing must be necessary for the provision of health care, and it must be carried out by a professional under an obligation of professional secrecy.

The software that processes this data is a data processor under GDPR Article 28. This means:

• The vendor must process data only on the clinic's documented instructions
• The vendor must implement appropriate technical and organisational measures to ensure data security
• The vendor must notify the clinic of any personal data breach without undue delay
• The vendor must delete or return all personal data at the end of the service relationship

Processor terms formalising these obligations are required by law. Any vendor that cannot provide processor terms should not be used for clinical data.

The Evaluation Framework

1. Lawful Basis and Consent Workflow Support

The software should support documenting and applying the lawful basis for each type of processing:

Clinical data: Article 9(2)(h) — health care purposes. The system should allow the clinic to document this basis in the Record of Processing Activities (ROPA). Check whether the vendor provides a pre-populated ROPA template that covers standard clinic processing activities.

Marketing communications: Article 6(1)(a) — consent. The system should allow capture of explicit, separate marketing consent, track when consent was given, record the version of the privacy notice in effect at the time, and allow consent to be withdrawn. Confirm that marketing consent cannot be bundled with clinical consent — they must be separate opt-ins.

What to test: Create a test patient. Record clinical information. Separately record marketing consent. Withdraw marketing consent. Confirm that withdrawal is recorded with a timestamp and does not affect the clinical record.

2. Role-Based Access Controls and Audit Logs

Role-based access: Not every staff member should access every patient record. A receptionist booking appointments does not need to access clinical notes. A practitioner delivering care does not need access to billing payment details beyond what is required for the appointment. The software must support granular role definitions with access controls at the data category level.

Audit log: Every access to, or modification of, a patient record should be logged with: user identity, timestamp, action performed, and (where applicable) the record accessed. The audit log is the primary evidence tool for demonstrating GDPR accountability — if a data breach occurs, the audit log is how you determine what data was accessed and by whom.

What to test: Log in as a receptionist-level user. Attempt to access a clinical note — confirm the system blocks access. Log in as a practitioner. Create a clinical note. Log in as an administrator. Pull the audit log and confirm the clinical note creation is recorded with the practitioner's identity and the timestamp.

3. Data Retention and Deletion Tools

Retention policy configuration: Clinical data retention periods vary by patient age, data category, and jurisdiction. In most EU member states, adult clinical records are retained for 8–10 years from last contact; paediatric records are retained until the patient reaches a defined age (typically 25 or 28). The software should support configurable retention periods by data category, not a single global retention setting.

Deletion and anonymisation workflow: At the end of the retention period, data must be deleted or anonymised. The software should support a workflow for identifying records that have reached their retention period, reviewing them for exceptions (ongoing treatment, legal hold), and executing deletion or anonymisation. Manual deletion at scale — going through individual records one by one — is not operationally viable for a clinic with thousands of patient records.

DSAR export (Data Subject Access Request): Under GDPR Article 15, data subjects have the right to receive a copy of all personal data held about them. The software must be able to produce a complete export of all data held for a named patient — not just appointment records, but clinical notes, billing records, consent records, communications, and any other data category. Test this export before purchase.

What to test: Create a test patient with data in multiple categories (appointment, clinical note, billing record, marketing consent). Generate the DSAR export. Confirm it is complete across all data categories. Time how long it takes — a privacy-aware system must respond within one month.

4. Data Hosting and Transfer Controls

Hosting location: Where is the data stored? For EU clinics, EU-hosted data is the least complex option — no transfer mechanisms are required. The hosting location should be confirmed in processor terms, not just claimed on the marketing website. Ask for the specific country and data centre provider.

Third-country transfers: If the software uses sub-processors (third-party services for email, analytics, support tools) that are hosted outside the EU, those transfers must be covered by an adequacy decision or Standard Contractual Clauses (SCCs). Ask the vendor for their sub-processor list and the transfer mechanism for each one.

What to request: A copy of processor terms (must specify hosting location, sub-processors, and transfer mechanisms), the sub-processor list, and any third-country transfer documentation.

5. Breach Notification and Incident Response

Vendor breach notification: Under GDPR Article 33, the clinic must notify its supervisory authority within 72 hours of becoming aware of a personal data breach. To do this, the clinic must be notified by the vendor promptly when a breach involves their data. The processor terms should specify the vendor's obligation to notify the clinic without undue delay.

What to ask: What is your process for detecting a personal data breach? How quickly would you notify us? Who is our point of contact for data security incidents? Can you share your incident response procedure?

A vendor that cannot articulate a clear incident response procedure or notification commitment represents a compliance risk — the clinic may find out about a breach through a news report rather than a formal notification, leaving insufficient time to meet the 72-hour supervisory authority notification deadline.

Vendor Validation Steps

Beyond the feature evaluation, validate the vendor's GDPR posture through four steps:

Step 1 — Request evidence, not summaries. Ask for: processor terms (not a link to a privacy policy page), the sub-processor list, any security certifications (ISO 27001, SOC 2), and the incident response procedure. A vendor that provides these without hesitation is operating at the expected standard. A vendor that sends a marketing PDF instead of a legal document is not.

Step 2 — Pilot real compliance workflows. Don't evaluate GDPR compliance from a demo — run a pilot with real compliance workflow scenarios: DSAR export, marketing consent withdrawal, role access control testing, audit log review. The difference between a system that claims GDPR compliance and one that operationally delivers it becomes visible in the pilot.

Step 3 — Review incident handling. Ask specifically: have you ever experienced a personal data breach affecting client data? If so, how was it handled? A vendor with a history of incidents is not disqualified — how they handled the incident matters more than whether one occurred. A vendor that had an incident, notified clients promptly, and has since strengthened controls is preferable to a vendor that claims no incidents but cannot articulate their detection and response process.

Step 4 — Confirm contractual data-processing terms. The processor terms must be signed before you process patient data on the vendor's platform. Confirm that processor terms can be signed (some vendors only offer it at higher tiers — this is a compliance risk if you process special-category data on a basic tier). Confirm that processor terms specifies: the subject matter, duration, nature, and purpose of processing; the type of personal data and categories of data subjects; and the obligations and rights of the controller.

Platform Comparison

GDPR criterion	Tregovia	Generic SaaS	EHR (established)
processor terms available on all plans	Yes	Often enterprise-only	Yes
Sub-processor list published	Yes	Varies	Usually
Privacy review recommended	Yes	Varies	Usually EU-optional
DSAR export workflow	Yes	Manual / API only	Yes
Granular RBAC	Yes	Limited	Yes
Audit log (all record access)	Yes	Limited	Yes
Retention policy configuration	Yes	No	Yes
Consent lifecycle management	Yes	No	Varies

Verify current GDPR features and processor terms availability at each vendor's website.

Setting Up in Tregovia

Tregovia is built for EU healthcare and service businesses:

• processor terms: Included with all plans. Specifies processing subject matter, sub-processors, and notification obligations.
• Lawful basis documentation: ROPA template provided; consent records stored with timestamp, version, and withdrawal date
• RBAC: Six role levels; configurable per staff member; access blocked at data category level
• Audit log: All record access and modifications logged; exportable for review
• DSAR export: One-click export of all data for a named patient across all data categories
• Retention configuration: Per-category retention periods; deletion workflow at end of period
• Privacy review: Confirm current privacy terms and transfer safeguards before importing regulated data.
• Breach notification: Incident notification procedure documented in processor terms; 72h commitment

Pricing: EUR 47/month flat rate — up to 2 staff, up to 100 clients (extra users EUR 10/month per 5 seats). 14-day free trial.

FAQ

Is GDPR compliance primarily a legal or technical problem?

Both, and the split matters. The legal side covers lawful basis, consent, data subject rights, and documentation — this requires policy decisions by the clinic. The technical side covers access controls, encryption, audit logging, breach detection, and retention automation — this is delivered by the software. A clinic with a perfect legal framework but software that can't produce a DSAR export, or that has no audit log, cannot operationally fulfil its GDPR obligations. Choose software that handles the technical requirements, then pair it with a policy framework appropriate for your practice.

Does hosting in the EU guarantee GDPR compliance?

No. Hosting in the EU means EU data protection law applies to the hosting environment, and no third-country transfer mechanism is required for the primary data processing. It does not guarantee that the software's operational controls (access management, retention tools, audit logging, breach detection) are adequate. Many EU-hosted tools have weak access controls or no audit logging — they are technically within the EU but operationally non-compliant. Hosting location is a necessary but not sufficient compliance condition.

Who should be involved in clinic software evaluation?

At minimum: the practice owner or manager (operational accountability), a clinical lead (understands what data is processed and why), and where available, someone with data protection knowledge (can evaluate processor terms and consent workflows). Avoid evaluating GDPR compliance through a sales demo alone — the vendor is incentivised to show you the best-case scenario. A technical pilot run by your own team, testing real workflows, is far more informative.

What is the minimum evidence a clinic should collect before signing?

A reviewed processor terms; the sub-processor list; confirmation of hosting location; a DSAR export test result; and an audit log sample. If the vendor cannot provide all five before you go live, you are taking on compliance risk that belongs to the vendor. An established, well-run vendor will provide all of these as standard.

What happens if a vendor suffers a breach and doesn't notify the clinic promptly?

The clinic may miss the 72-hour supervisory authority notification deadline — even though the breach occurred at the vendor's infrastructure. This is why processor terms must specify the vendor's notification obligation explicitly. Under GDPR Article 28(3)(f), the vendor must "assist the controller in ensuring compliance with the obligations pursuant to Article 32 to 36" — which includes breach notification. If the vendor fails to notify promptly and the clinic misses the 72-hour deadline as a result, the clinic can demonstrate that the failure was the vendor's, but this requires documented evidence (processor terms obligation, the vendor's failure to notify, the clinic's response on receiving notification). Document everything.