Informational

GDPR Clinic CRM Checklist for Private Practices

A GDPR clinic CRM checklist covering lawful basis, consent, access controls, audit logging, data subject requests, and retention for EU clinics.

By Platform EditorialPublished 10 min read
GDPR Clinic CRM Checklist for Private Practices
Summary

A GDPR clinic CRM checklist covering lawful basis, consent, access controls, audit logging, data subject requests, and retention for EU clinics. Main sections: part 1 — legal basis and consent mapping, part 2 — role-based access and data minimisation, part 3 — audit logging and retention controls, and part 4 — data subject request workflow.

GDPR Clinic CRM Checklist for Private Practices (2026 Guide)

GDPR compliance for a clinic CRM is not a configuration task completed once at implementation. It is an ongoing operational discipline: consent records expire and need renewal; access permissions need auditing as staff join and leave; data subject requests arrive and must be handled within statutory deadlines; incidents occur and must be documented.

This checklist covers the core GDPR compliance controls that should be in place for any private clinic using a CRM to manage patient or client data in the EU. Work through it systematically at implementation, then use the monthly review cadence to maintain compliance over time.

Part 1 — Legal Basis and Consent Mapping

1.1 Legal basis documented for every data processing activity

Every type of personal data processing in the CRM must have a documented legal basis under GDPR Article 6:

Processing activityLikely legal basis
Storing client contact detailsArt. 6(1)(b) — contract performance
Appointment historyArt. 6(1)(b) — contract performance
Clinical/health recordsArt. 9(2)(h) — health care purposes
Marketing emails and SMSArt. 6(1)(a) — consent (explicit opt-in required)
Staff time and attendance recordsArt. 6(1)(b) — employment contract
Analytics and reportingArt. 6(1)(f) — legitimate interests (document the balancing test)
Referral source trackingArt. 6(1)(f) — legitimate interests

Checklist item: Does your Record of Processing Activities (ROPA) document the legal basis for each activity? Is it reviewed annually or when processing changes?

1.2 Consent obtained and recorded where required

Where the legal basis is Art. 6(1)(a) (consent), the CRM must:

  • Record when consent was given, by what method, and for what specific purpose
  • Record which version of the privacy notice was in effect when consent was given
  • Provide a mechanism for clients to withdraw consent easily
  • Stop the relevant processing promptly when consent is withdrawn

Checklist item: Can you export a report from the CRM showing which clients have active marketing consent, when it was given, and via which channel?

1.3 Consent expiry and renewal

Marketing consent should be renewed at a defined interval (typically 12–24 months) or when the purpose changes materially. Stale consent from clients who haven't interacted with the clinic in years presents GDPR risk.

Checklist item: Does the CRM track consent dates and flag records where consent is approaching expiry? Is there a renewal workflow for lapsed consent?

Part 2 — Role-Based Access and Data Minimisation

2.1 Role-based access control configured

Staff should only access the data they need for their role. A receptionist needs to see appointment schedules and contact details; they do not need to see clinical notes or billing history. A billing administrator needs invoice records; they do not need clinical records.

Checklist item: Has role-based access been configured in the CRM? Are there separate role levels for reception, clinical staff, billing, and management?

2.2 Least privilege principle applied

No role should have more access than required. Review permissions quarterly: as staff roles change, their CRM permissions should be updated.

Checklist item: When a staff member changes role or leaves, is their CRM access updated within 24 hours? Is there a documented offboarding process that includes CRM access revocation?

2.3 Data minimisation in forms and records

Collect only the data necessary for the stated purpose. A new patient registration form that asks for political beliefs or unrelated personal details collects more data than required — a GDPR violation.

Checklist item: Review all intake forms, registration forms, and data entry fields in the CRM. Is every field there for a specific, documented purpose? Remove or make optional any field that doesn't have a clear processing justification.

Part 3 — Audit Logging and Retention Controls

3.1 Audit logging enabled for sensitive record access

The CRM should log who accessed which records and when, particularly for sensitive data (clinical records, financial records, special category data). Audit logs are both a security control and a GDPR accountability tool.

Checklist item: Does the CRM maintain access logs for clinical and financial records? Are logs retained for a sufficient period (typically 12 months for operational use; longer for compliance purposes)?

3.2 Retention periods defined and enforced

Every data category needs a defined retention period. After the retention period, data should be deleted or anonymised.

Data categoryTypical retention
Clinical records8–10 years from last contact (varies by jurisdiction)
Minor patientsUntil patient is 25, or 8 years from last contact (whichever is longer)
Financial records7 years (tax compliance)
Marketing consent records3 years after consent withdrawal (evidence of compliance)
Staff employment records6 years after employment ends
CCTV / location data30–90 days

Checklist item: Are retention periods defined for all data categories in the CRM? Is there a deletion or anonymisation workflow for records that reach end of retention?

3.3 processor terms in place with CRM vendor

The CRM vendor processes personal data on behalf of the clinic (as a data processor). GDPR Article 28 requires a written processor terms. Without processor terms, the clinic is non-compliant regardless of how well it manages its own processes.

Checklist item: Does your CRM vendor provide a GDPR-aware processor terms? Is it signed and filed?

Part 4 — Data Subject Request Workflow

4.1 Process defined for Subject Access Requests (SARs)

Under GDPR Article 15, data subjects can request all personal data held about them. The clinic must respond within one month (extendable to three months for complex requests with notification to the data subject).

Checklist item: Is there a defined process for receiving, logging, and responding to SARs? Does the CRM support export of all data for a specific individual?

4.2 Process defined for Right to Erasure (Article 17)

Clients can request deletion of their personal data where the legal basis for processing no longer applies. Clinics must delete data within one month, except where retention is required by law (clinical records retained for regulatory/legal purposes can be retained despite an erasure request, but the client must be informed of the basis for retention).

Checklist item: Can the CRM perform a selective erasure of marketing data while retaining clinically required records? Is there a process for responding to erasure requests within one month?

4.3 Process for rectification requests

Clients can request correction of inaccurate personal data. This is typically straightforward but must be documented.

Checklist item: Is there a defined process for updating records on client request, with the change logged?

Part 5 — Incident Response

5.1 Personal data breach notification process

Under GDPR Article 33, a personal data breach (unauthorised access, loss, or disclosure of personal data) must be reported to the relevant supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in risk to individuals.

Checklist item: Is there a documented breach response process? Does staff know what constitutes a personal data breach and who to notify internally? Is the supervisory authority contact (national data protection authority) documented?

5.2 Breach log maintained

Even breaches that don't meet the notification threshold must be documented internally under GDPR Article 33(5).

Checklist item: Is there a breach log where all incidents (notified and non-notified) are recorded with date, description, affected data, and action taken?

Monthly Review Cadence

GDPR compliance is maintained through regular review, not one-time setup:

Review itemFrequency
Access audit sample (5 records reviewed for who accessed them)Monthly
Consent expiry status (identify records approaching expiry)Monthly
Open data subject requests (confirm all responded to within deadline)Monthly
New staff access permissions (confirm appropriately scoped)On each new hire
Departed staff access revocation (confirm accounts deactivated)On each departure
Retention schedule (flag records at end of retention period)Quarterly
processor terms validity (confirm vendor processor terms are current)Annually
ROPA review (confirm all processing activities documented)Annually

Setting Up in Tregovia

Tregovia's CRM is built to support GDPR-aware EU clinic operations:

  • Consent recording: Client records include marketing consent fields, and forms can capture explicit consent responses
  • Role-based access: RECEPTIONIST → STAFF → PRACTITIONER → MANAGER → ADMIN → OWNER hierarchy; configurable per module
  • Audit logging: Mutations across core modules publish audit events with actor and entity context
  • Data retention: Tenant lifecycle and erasure jobs handle inactive tenant retention and GDPR erasure requests
  • SAR export: Authenticated user and portal-client export endpoints are available
  • Erasure workflow: Erasure requests are queued and processed with anonymization where legally permitted
  • processor terms review: Confirm the current processor terms, hosting, and sub-processor terms before production use

Pricing: EUR 47/month base plan with up to 2 staff and up to 100 clients; extra users are EUR 10/month per 5-seat pack. Some workflows require paid add-on modules.

FAQ

What is the most overlooked GDPR control in clinic CRM systems?

Practical handling of data subject requests under real operational workload. Most clinics have a privacy policy and a consent checkbox on their forms, but few have a documented, tested process for responding to a subject access request within the 30-day deadline. When the first real SAR arrives — from a disgruntled patient, from a solicitor, from a regulator — the absence of a process becomes immediately apparent. Build and test the SAR response process before you need it.

Should all clinical staff have access to all CRM records?

No. Clinical staff should have access to records for patients under their care or that are relevant to their role. A practitioner at Location A does not need access to patient records for Location B unless they have a clinical relationship. A vet technician does not need access to billing records. Role-based access scoped by clinical need, not convenience, is the correct model. Start from the principle of least privilege and add access only when there is a clear clinical or operational justification.

How do clinics prove GDPR compliance to regulators?

Through documented evidence of controls in operation: the ROPA (showing all processing activities and their legal basis), consent records (showing that marketing communications were sent to opted-in contacts), access logs (showing that sensitive records were accessed only by authorised staff), SAR response records (showing requests were handled within deadline), and the breach log (showing that incidents were identified and documented). Regulators examining a GDPR complaint will ask for this evidence; clinics that can produce it promptly are in a far stronger position than those who can't.

What should be documented for a GDPR audit?

Policies (privacy policy, data retention policy, access control policy), decisions (the legal basis chosen for each processing activity and why), logs (access logs, consent records, breach log, SAR response records), and corrective actions (what was done when an incident or gap was identified). Documentation proves that the clinic thought about GDPR and took deliberate, documented steps to comply — not that it happened to be compliant by accident.

Does the clinic need a Data Protection Officer (DPO)?

GDPR Article 37 requires a DPO when an organisation is a public authority, when it carries out large-scale systematic monitoring of individuals, or when it carries out large-scale processing of special category data. Most private clinics do not meet the "large-scale" threshold. However, clinics that process health data at scale (large multi-location chains, telehealth platforms with thousands of patients) may need to assess this. Even without a mandatory DPO, assigning a named individual as the GDPR compliance lead — responsible for the ROPA, SAR responses, and breach notification — is best practice for any clinic.

<!-- seo-audit-related-links -->

Continue Reading

Use these guides to continue the same evaluation path with adjacent workflows, migration questions, and buyer checks.

14-day free trial

GDPR-ready practice management software

Platform gives teams GDPR-aware controls for consent records, access, exports, and right-to-erasure workflows. Review your DPA and local obligations before going live.