Clinic Software Right-to-Erasure Workflow: GDPR Guide (2026)

Clinic Software Right-to-Erasure Workflow: GDPR Operations Guide (2026)

GDPR Article 17 grants data subjects the right to request erasure of their personal data — commonly known as the "right to be forgotten." For clinics, this right creates a process challenge: patient data is not simply deletable on request. Clinical records, financial records, and certain legal obligations require retention of specific data for defined periods, regardless of the patient's request.

The right-to-erasure workflow for a clinic is therefore not simply "delete the data." It is a governed process that verifies identity, checks legal retention obligations, makes a documented decision, executes the appropriate action (full deletion, partial anonymisation, or lawful retention), and creates an evidence record that demonstrates compliance regardless of the outcome.

Why Erasure Requests Fail

The most common failure modes:

Incomplete cross-system deletion. A clinic deletes the patient record in the practice management system but forgets the patient's email address in the marketing automation tool, their phone number in the SMS provider platform, and their data in the backup archive. GDPR erasure applies to all processing systems, not just the primary record.

Legal hold not checked. A clinic deletes a patient record in response to an erasure request without checking whether the record contains data required to be retained under health record legislation, tax law, or an active legal dispute. Deletion of legally required records creates a different compliance problem than a failed erasure request.

No response within the deadline. GDPR Article 17 requires a response within one calendar month of the request (extendable to three months for complex requests with notice to the requester). Clinics that don't have a defined workflow for handling erasure requests routinely miss the deadline.

Generic refusal without explanation. Denying an erasure request is sometimes appropriate (legal retention obligations), but the denial must be specific — which data is retained, under which legal basis, for how long. A generic "we cannot delete your data" response is not compliant.

The Five-Step Erasure Workflow

Step 1: Receive and verify the request

Receipt: Erasure requests can arrive by any means — email, letter, phone, portal message. All must be treated as valid requests from the moment received. Log the request immediately with: date received, channel, requester name (as given), and data subject reference if known.

Identity verification: Verify that the requester is who they say they are before acting on the request. If the request is from someone who can't be identified, verify before disclosing any information about what data is held. Verification methods:

• Email from the address registered in the patient record
• Portal login with confirmed identity
• Written request with name and date of birth matching the record
• For third-party requests (e.g., parent acting for a minor): verify the relationship

Do not request excessive documentation — GDPR does not require clinics to demand notarised identity documents. Reasonable confirmation matching a known data point is sufficient.

Response deadline clock starts: From the confirmed receipt date, the one-month response window begins. Log this in the workflow tracker.

Step 2: Identify all data in scope

The erasure request covers all personal data held across all systems:

• Practice management system: patient demographics, clinical records, appointment history
• Billing system: invoice history, payment records
• Communication platform: email history, SMS history, marketing consent records
• Marketing automation: email lists, campaign engagement data
• Backup archives: snapshot data that may persist beyond primary system deletion
• Staff notes and manual records (if any): paper files, secure messaging records

Create a data inventory per request. This is more manageable if the clinic maintains a Record of Processing Activities (ROPA) — the GDPR requirement to document where personal data is held.

Step 3: Check legal retention obligations

Before any data is deleted, every category of data in scope must be checked against applicable retention obligations:

Data Category	Typical Retention Obligation	Basis
Clinical records	7–10 years after last contact (varies by member state and specialty)	Health records legislation
Financial records (invoices, payments)	5–7 years (varies by member state)	Tax and accounting law
Consent records	Duration of consent + applicable limitation period	GDPR compliance evidence
Active litigation records	Duration of legal proceedings + limitation period	Legal proceedings
Vaccination records	Varies by vaccination type and jurisdiction	EU and national veterinary/medical regulation

Decision matrix:

Scenario	Action
Data has no retention obligation	Delete
Data has retention obligation that has expired	Delete
Data has active retention obligation	Retain; document the obligation and expected retention end date
Data is subject to active legal hold	Retain; document the hold
Partial retention (some elements can be deleted, some retained)	Anonymise retained elements where possible; delete the rest

Step 4: Execute the decision

Full deletion: All data in scope can be deleted. Execute deletion across all systems identified in Step 2. Delete from:

• Primary system records
• Backup systems (note: immediate deletion from backups may not be technically feasible — record the date when backups containing the data will naturally expire, and treat this as the effective deletion date)
• Third-party processors (email marketing tool, SMS provider) — issue deletion request to each processor within the controller-processor relationship

Partial anonymisation: Some data must be retained (e.g., financial records) but can be anonymised — name and contact details removed, replaced with a pseudonymous reference. The retained financial record shows a payment was received but does not identify who made it.

Lawful retention: All or some data must be retained under applicable law. Inform the requester of what is retained, under which legal basis, and for how long.

Step 5: Document and respond

Create an immutable record of the erasure request and the decision:

• Requester details and identity verification method
• Date received and response deadline
• Data inventory (what was found and where)
• Decision for each data category (deleted / anonymised / retained with basis)
• Deletion confirmation (which systems, when)
• Response sent to requester: date, channel, content

Response to requester:

• If erased: "We have deleted your personal data as requested. [Summary of what was deleted.] [Note if any data was retained and why.]"
• If partially retained: "We have deleted [X] and retained [Y] under [legal basis] until [date]."
• If fully retained: "We are unable to erase [data category] at this time because [specific legal obligation]. We will erase it on [date when retention obligation expires]."

All responses within one calendar month of the confirmed request.

Setting Up in Tregovia

Tregovia supports GDPR erasure workflows through several coordinated features:

• Patient record management: Soft-delete (anonymise) patient records with audit trail; hard-delete where legally permissible
• Data export: Generate a complete data subject export before deletion — creates the evidence record of what was held
• Role-based access: Erasure actions require owner or admin role — not performable by reception or clinical staff
• Audit log: All deletion and anonymisation actions logged with user, timestamp, and record reference — immutable
• Privacy terms: confirm controller/processor responsibilities and deletion request handling before importing regulated client data

Privacy workflow: Tregovia includes export and erasure request flows, plus background erasure processing where legally permitted. Confirm processor terms, hosting, retention, and sub-processor terms before relying on the workflow for clinical data.

FAQ

Are all patient data elements deletable immediately upon request?

No. Clinical records, financial records, and other regulated data categories carry retention obligations that override the individual's erasure right under GDPR Article 17(3). The erasure right applies where the data is no longer necessary for the purpose it was collected, or where the processing was based on consent that has been withdrawn — but not where a statutory retention obligation requires the data to be kept. Always check retention obligations before acting on an erasure request.

How should clinics handle erasure requests for data held in backup systems?

Immediate deletion from backup archives may not be technically feasible in all backup systems. GDPR acknowledges this — the supervisory authority guidance in most EU member states permits a reasonable timeline for backup deletion (e.g., until the backup naturally expires in the backup cycle) provided the data is not actively accessed and the deletion timeline is documented. Record the backup expiry date as the effective deletion date in the request record.

Who should be authorised to approve erasure decisions?

A designated privacy or compliance owner — typically the practice owner or a named data protection officer if the clinic has one. Erasure decisions involve legal judgments about retention obligations and should not be delegated to reception or clinical staff. For small clinics, the owner or practice manager is the appropriate decision-maker.

What is the key audit artefact if a supervisory authority investigates?

The timestamped decision trail: the date the request was received, the identity verification performed, the data inventory, the retention check with the legal basis for each category, the deletion confirmations, and the response sent to the requester. This document demonstrates that the clinic followed a structured, privacy-aware process — regardless of whether the outcome was deletion or retention.

Should clinics proactively delete data for patients who haven't been seen for years?

Yes — proactive data minimisation is a GDPR principle (Article 5(1)(e)). Once the applicable retention period for a patient's data has expired and there is no active relationship or legal obligation, the data should be deleted or anonymised without waiting for an erasure request. Most clinics run a quarterly or annual data retention review that identifies records past their retention date and schedules them for deletion. This demonstrates proactive compliance and reduces the volume of data held unnecessarily.