GDPR CRM for Private Medical Practices (2026 Guide)

How to Choose a GDPR-Compliant CRM for a Private Medical Practice (2026)

GDPR compliance for a private medical practice isn't achieved by selecting a CRM that advertises "GDPR-aware" on its marketing page. It's achieved through the combination of a platform that supports the necessary technical controls and operational practices that implement those controls correctly. A platform with all the required features — consent logging, audit trails, access controls, data export — run by a practice without governance procedures is still non-compliant. A well-governed practice using a platform without the required technical controls is equally non-compliant.

This guide covers what to evaluate in a CRM for genuine GDPR compliance in a private medical practice: the legal framework, the technical requirements, the operational procedures, and the verification steps that confirm the platform actually delivers what it claims.

The Legal Framework for Medical Practice Data

Special category data

Patient clinical data in a private medical practice is special category data under GDPR Article 9 — it requires a stronger legal basis than ordinary personal data. The applicable lawful basis for a medical practice processing clinical records is typically Article 9(2)(h): "processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment, or the management of health or social care systems."

This means: clinical data can be processed without explicit consent if the processing is for the delivery of medical care. The practice does not need to ask for consent to create a clinical record for a patient.

What does require consent is marketing communications (Article 6(1)(a)) and any processing purpose that goes beyond direct care delivery — for example, sharing anonymised data for research, or sharing identifiable data with third-party companies for any commercial purpose.

Consent is not the right lawful basis for clinical records. Practices that use "patient consent" as the basis for processing clinical records create a compliance problem: if the patient withdraws consent (their right under Article 7(3)), the practice would be legally required to delete the clinical records — which conflicts with the medical record retention obligations (typically 8–10 years after the patient's last visit in most EU jurisdictions). Use Article 9(2)(h) for clinical processing, and maintain a formal record of the lawful basis for each processing activity.

Data retention

Medical records must be retained for the legally required minimum period in the relevant jurisdiction (commonly 8 years after the patient's last visit for adult records; longer for paediatric records). After the retention period, records should be deleted unless there is a specific legal basis for continued retention (ongoing litigation, regulatory investigation).

The CRM must support configurable retention policies that flag records approaching the end of their retention period and support automated or manual deletion after the retention period expires.

Technical Requirements

Role-based access control

In a private medical practice, not all staff need access to all data:

• Receptionists need: appointment scheduling, contact information, billing
• Nurses need: clinical records for the patients they're treating
• Clinicians need: all clinical records for their patients
• Billing staff need: invoices, payments, insurance records — not clinical notes
• Practice managers need: operational reports, staff access management — not necessarily individual clinical notes

The CRM must support role-based access control that restricts each staff role to the data categories they legitimately need. A receptionist should not be able to read the clinical notes for every patient in the practice. This isn't just a compliance requirement — it's a patient trust and data minimisation (Article 5(1)(c)) obligation.

Verify this in product: Create a test account with receptionist-level permissions. Confirm that clinical notes are not accessible from that account. Do the same for each other role. If the system doesn't support meaningful role-based restriction of clinical data, it is not suitable for a private medical practice.

Audit trail

Every access to a patient's clinical record should be logged: who accessed it, when, what action was taken (view, edit, export). This audit trail is the primary evidence for GDPR accountability (Article 5(2)) and is required to answer Data Subject Access Requests that include "who has accessed my records."

Verify this in product: Request a sample access log from the vendor. Does it include: user ID, timestamp, record accessed, action taken? Is it immutable (cannot be deleted or altered by any user, including administrators)? Can it be exported for an audit?

Consent management

For the processing activities that do require consent (marketing, research, non-clinical communication preferences), the CRM must support:

• Consent capture with timestamp and version of the consent text
• Consent versioning (when the consent text changes, existing consents are distinguishable from new consents under the updated text)
• Consent withdrawal recording (the date and method of withdrawal)
• Consent history per patient (a full timeline of consent grant, version, and withdrawal events)

Data subject rights workflows

Under GDPR Articles 15–22, data subjects (patients) have a suite of rights: access (Article 15), rectification (Article 16), erasure (Article 17 — subject to retention obligations), restriction of processing (Article 18), portability (Article 20), and objection (Article 21).

The CRM must support processes for:

• Data Subject Access Request (DSAR): Generating a complete export of all personal data held for a specific patient, within the 30-day response deadline
• Rectification: Allowing a patient's data to be corrected without breaking the audit trail (correction with reason logged, not silent overwrite)
• Erasure: Deleting a patient's personal data when legally permissible (after the retention period, for non-clinical data not subject to retention obligations), with a deletion confirmation record

DSAR response test: Before selecting a platform, test the DSAR workflow. Create a test patient record. Submit a DSAR for that patient. Evaluate: how long does the export take? Does it include all data categories (appointments, clinical notes, billing, consent records, communications)? Is the export in a readable format (PDF and/or CSV)? Can the export be produced in 30 days by a non-technical staff member?

Vendor Assessment

processor terms

A CRM vendor that processes patient data on behalf of a medical practice is a data processor under GDPR Article 28. The practice must have processor terms with the vendor before any patient data is processed.

The processor terms must specify: what data is processed, for what purpose, under what security measures, where the data is stored (and whether it transfers outside the EU), and how data breach notification works.

Do not use a CRM vendor that cannot provide processor terms. This is a non-negotiable compliance requirement. A vendor that says "we're GDPR-aware" without providing a formal processor terms are not in compliance.

Data residency

For EU medical practices, patient data should remain within the EU. If the CRM vendor uses hosting or infrastructure providers with servers in non-EU countries (US, UK, India), data transfer may occur — which requires adequate safeguards (Standard Contractual Clauses, adequacy decision).

Verify where the vendor stores data, not just where their main office is. A company headquartered in Dublin that stores data on servers outside the EU is a non-EU data transfer. Ask the vendor for the list of sub-processors and their data residency.

Procurement Verification Checklist

Before signing with any CRM vendor for a private medical practice:

• Formal processor terms provided and signed before data processing begins
• Data storage location confirmed as EU (preferably a high-standard EU jurisdiction)
• Sub-processor list reviewed and EU residency confirmed for all sub-processors
• Role-based access control tested with realistic role configurations
• Audit trail format reviewed — complete, timestamped, immutable
• DSAR workflow tested — full export in < 30 days, all data categories included
• Consent management features verified for marketing/research consent
• Retention policy configuration reviewed — supports jurisdiction-specific retention periods
• Security certifications reviewed (ISO 27001 or equivalent)
• Data breach notification procedure confirmed (vendor notifies practice within 72 hours per GDPR Article 33)

Setting Up in Tregovia

Tregovia's Medical Records module (EUR 15/month, for medical practices) and base plan support GDPR-aware data handling for private medical practices:

Data processing foundation:

• Confirm the current processor terms before production use
• Review hosting, sub-processor, and retention terms as part of vendor diligence
• Keep lawful-basis decisions in the clinic's own GDPR records

Access control:

• Role-based access by clinical role (receptionist, nurse, clinician, billing, manager, owner)
• Clinical and operational routes are guarded by role and module checks in the app
• Owners and admins should review staff access before importing patient data

Audit trail:

• Mutating actions publish events and audit entries across core modules
• Keep exports of critical legal decisions in the clinic's own compliance folder when required

Consent management:

• Client records include marketing consent fields
• Use Forms Intake or Contracts eSign for explicit consent workflows where required
• Keep clinical-care lawful basis separate from marketing consent

Data subject rights:

• Authenticated users and portal clients have export and deletion request flows
• Erasure processing anonymizes personal data where legally permitted while retaining records that must be kept
• Validate the workflow against your retention duties before relying on deletion automation

GDPR position: Tregovia provides technical controls that can support GDPR operations, but compliance depends on the clinic's configuration, processor terms review, lawful basis, retention policy, and staff process.

Pricing: Medical Records module EUR 15/month on top of the EUR 47/month base plan. The base plan includes up to 2 staff and up to 100 clients; extra users are EUR 10/month per 5-seat pack.

FAQ

Is EU hosting enough for GDPR compliance?

No — EU hosting is a necessary condition but not sufficient. Hosting location determines where the data sits at rest. Compliance also requires: reviewed processor terms, appropriate access controls preventing unauthorised access, complete audit trails for access accountability, data subject rights workflows that can be executed within the GDPR response deadlines, and operational governance procedures at the practice level. A practice with EU-hosted data but no reviewed processor terms, no role-based access controls, and no DSAR procedure is non-compliant regardless of where the servers are.

What is the biggest post-go-live compliance risk?

Permission drift and undocumented process changes. Permission drift occurs when user roles are modified over time — a receptionist is given temporary access to clinical records to cover an absence, and the temporary access is never revoked. Over 12 months, several staff members may have accumulated permissions that don't reflect their current role. Quarterly access reviews — reviewing every active user's permissions against their current role — are the primary control for permission drift. Undocumented process changes (a new data processing activity is introduced without updating the practice's Records of Processing Activities) create gaps between what the practice is actually doing and what it has documented for GDPR accountability. Both are addressed by named compliance ownership and a structured quarterly review cycle.

Who should own GDPR compliance in a private medical practice?

A named compliance owner — typically the practice manager or principal clinician — plus operational process owners for each processing activity. The compliance owner is responsible for: maintaining the Records of Processing Activities, ensuring vendor processor terms are in place, conducting the annual compliance review, and managing data breach incidents. Operational process owners are responsible for: following the correct procedures for their activity (e.g., the receptionist who handles DSARs must know the procedure and execute it within the 30-day deadline). Without named ownership, compliance accountability is diffused and enforcement is impossible.

What KPI should be tracked for GDPR compliance performance?

DSAR turnaround time and unresolved access exceptions. DSAR turnaround time: the time from receiving a DSAR to providing the complete response. The GDPR deadline is 30 days; the target for an organised practice is under 15 days. Consistently slow turnaround (>20 days) indicates either an inadequate export tool or an undertrained compliance process. Unresolved access exceptions: the number of open findings from the quarterly access review that haven't been resolved (revoked, justified, or escalated). These represent current non-compliance with the data minimisation principle — the longer they remain open, the greater the compliance exposure.

How should a practice respond to a GDPR data breach?

By following a pre-defined incident response procedure, not by improvising. The GDPR requires notification to the supervisory authority within 72 hours of becoming aware of the breach (Article 33), and notification to affected data subjects if the breach is likely to result in high risk to their rights (Article 34). The 72-hour clock is tight — practices without a pre-defined procedure will struggle to meet it. The procedure should define: who declares a breach, who assesses the risk (is this high-risk to data subjects?), who notifies the supervisory authority, what information must be included in the notification, and who notifies affected patients. The CRM vendor must notify the practice of any breach on the vendor's infrastructure within the same 72-hour window, per processor terms.