What to sign with your data processor

Key Takeaways

• If a provider accesses or hosts patient data, you need a written data processor contract before you start using the service.
• The contract must state where the data is hosted, which sub-processors are involved and what actions the provider can carry out without asking for permission.
• Security measures are not solved with a generic sentence: request verifiable commitments and a clear channel for notifying incidents.
• Exit provisions (return, deletion and timings) are where clinics get stuck most often; have these signed and operational from day one.

Running a clinic means delegating tasks to third parties: software, cloud, accounting, maintenance or courier services. The moment a provider handles patient data, it’s no longer “just another service”: it’s a data processor and you must sign a contract.

Data processor: when it applies in a clinic

En una clínica, el “encargado del tratamiento” es el proveedor que trata datos personales por tu cuenta y siguiendo tus instrucciones. Esta figura y su contrato están regulados por el RGPD (art. 28) and must be formalised in writing.

Typical day-to-day examples

Think of real situations at the front desk and in practice management:

• Clinical record / schedule software that hosts patient records, appointments, reminders and billing: the provider is usually a data processor (and sometimes there are sub-processors).
• Cloud backup service where an export of the database is uploaded: data processor.
• Call centre that confirms appointments and sees name, phone and slots: data processor.
• IT maintenance company that connects remotely to the server or the devices where the software runs: data processor if they can see data.
• Email/SMS platform that sends reminders containing identifying data: usually a data processor (though review case by case).

By contrast, a company that sells sealed hardware (without accessing your systems) does not have to be a data processor. The practical question is: can they access personal data or do they host it? If the answer is yes, you need a contract.

Action you can take (today)

Make a quick list of providers with three columns: “Accesses”, “Hosts”, “Could access for support”. Anything that marks any box should be reviewed for a data processor contract.

What the data processor contract must include

The GDPR requires minimum content. In a clinic it’s helpful to make this concrete for operations: schedule, patient record, payments, patient communications and technical support.

1) Subject, duration and types of data processed

Don’t accept a contract that says “provision of services” and nothing more. It must state:

• What service is provided (for example, “hosting and support of the patient management system”).
• For how long (term and what happens at termination).
• What data are processed: identity data, contact, health data (special categories), billing data, etc.
• Which categories of data subjects: patients, legal representatives, staff, suppliers where applicable.

Action you can take (this week): ask the provider to give an annex listing “types of data” and “operations” (creating patient records, appointments, reminders, billing, export, support). If they don’t have one, ask them to draft it.

2) Documented instructions: what the provider may do

The contract must state that the provider only processes data in accordance with your instructions. In practice, most problems come from not defining what counts as an “instruction”.

Make clear:

• Which operations they may perform without asking each time (e.g., maintenance, backups, support).
• Which operations require prior authorisation (e.g., accessing real data to diagnose a fault).
• How instructions are documented: ticket, email, support portal.

Action you can take: set an internal rule: “support involving real data only with a ticket and authorisation from the clinic’s data controller”, and ensure the contract permits and reflects this.

3) Confidentiality: who can see data and what controls apply

“It’s confidential” is not enough. Ask for specifics:

• Provider staff bound by a confidentiality obligation.
• Access control by roles (not all support staff with full access).
• Access logs or, at least, traceability of support interventions.

Action you can take: request the provider’s support procedure: when they access, who authorises it, whether interventions are logged and how they are closed.

Where the data are hosted and what it means for your clinic

“Where the data are hosted” is not a technical curiosity. It affects international transfers, who can intervene and how you respond to an inspection or a breach.

What to ask (without jargon)

In a 10-minute conversation you can clarify the essentials:

1. In which country or countries are the data and backups stored?
2. Is any processing performed outside the EEA at any point (support, monitoring, analytics)?
3. Which entities act as sub-processors? (see next section)
4. How are my data separated from other clinics’ data? (multi-tenant, environments, etc.)

If there is an international transfer, it must be covered by the GDPR mechanisms (for example, adequacy decisions or standard contractual clauses). You don’t have to resolve it “by eye”: require the provider to explain and document it.

Action you can take

Add a mandatory question to your procurement checklist: “Confirm in writing where the data are hosted and where the backups are stored”. Without that answer, the service onboarding should not be activated.

Sub-processors: the real chain of providers

In a clinic it’s common for a main provider to subcontract parts: hosting, messaging, monitoring, support. Those third parties are sub-processors.

What must appear in the contract

The GDPR requires the data controller (your clinic) to have control over that chain. Practically, look for:

• A list of current sub-processors (name and function).
• How they will inform you of additions or changes of sub-processors.
• Whether you have a right to object and how to exercise it (timeframe and channel).
• That the provider imposes equivalent obligations on the sub-processor as in the main contract.

Operationally: if the provider changes hosting company tomorrow or adds a tool that “sees” data, you must be notified beforehand or at least have a pre-agreed procedure.

Action you can take

Request the “list of sub-processors” as a separate document and keep it with the contract. In your quarterly review, check whether it has changed and whether they notified you as agreed.

Security measures: what to ask for without becoming technical

Las medidas de seguridad deben ser adecuadas al riesgo, y en sanidad el listón sube porque hablamos de datos de salud (categorías especiales). La AEPD stresses a proactive accountability approach: you must be able to demonstrate that you chose and controlled your providers.

Minimum measures that make sense in a clinic

Without requesting “technical datasheets”, ask for clear commitments on:

• Access control: named users, passwords, roles.
• Action logging: who accesses, what changes, when (especially in clinical record and billing).
• Encryption: in transit and, where appropriate, at rest (ask for written confirmation).
• Backups: defined frequency, restoration tests and environment separation.
• Vulnerability and patch management: how updates are applied and in what internal timeframes.
• Support: channels, requester identification and limits of access.

Avoid phrases like “we will apply adequate measures”. Ask them to specify which measures and how they are verified.

What to review in your own clinic (not just the provider)

The provider won’t fix poor internal practice. Check:

• Employee onboarding and offboarding: individual accounts and immediate deactivation at the end of the relationship.
• Role-based permissions: front desk shouldn’t see everything a clinician sees, and accounting shouldn’t need access to clinical notes.
• Exports: who can extract lists and for which purpose.

Action you can take: on Monday, review the system’s user list and confirm there are no generic accounts (“FrontDesk”, “Admin”) or ex-employees still active.

Incidents and breaches: how you are notified and who does what

When there is a breach (loss, unauthorised access, ransomware), the clinic needs two things: to be notified quickly and to be able to act. The GDPR sets out notification obligations in certain cases; don’t wait to read it in the middle of a problem.

What the contract should state

Include, at a minimum:

• Notification channel (specific email, phone, portal).
• What information they will give you: type of incident, affected systems, data involved, measures applied.
• Cooperation: which logs or evidence they can provide and in what format.
• Coordination: who is the point of contact and committed response times (don’t invent numbers; ask them to define them).

Action you can take

Define a one-page internal mini‑protocol: “if the provider notifies an incident, notify clinic manager + DPO/adviser, freeze changes, gather tickets and communications”. Keep it with the contract.

End of service: return, deletion and data blocking

The exit phase is the most delicate: migrations, supplier changes, clinic closure or restructuring. If it’s not agreed, it’s improvised.

What to close down in the contract

The contract should specify:

• Return of data: format, delivery method and scope (patient records, documents, schedule, invoices, attachments).
• Deletion: what is deleted, when and how it is evidenced.
• Retention: if retained for legal or technical reasons explain it (for example, backups retained for a period), and how access is restricted.
• Migration assistance: what support they provide and on what terms (even if as a paid service, have a defined route).

In a clinic, the typical problem is discovering too late that attachments (signed consents, scanned reports) are not included in the standard export.

Action you can take

Before signing, request a sample export or an exact description of the “exit package”: what is included and what is not. If you use practice management software such as ClinicaDigital Software, insist that the contract describes the exit procedure without ambiguity.

How to put this into practice in your clinic

1. Management (today): list providers that access or host data and mark which have no signed contract.
   Verification: there is a document per provider in your “GDPR/Providers” folder.

2. Front desk + IT lead (tomorrow): check “where the data are hosted” and whether there are sub-processors in critical services (schedule/clinical record, backups, messaging).
   Verification: you have an email or contractual annex stating country of hosting and list of sub-processors.

3. Medical director or quality manager (this week): validate that support instructions are limited (when they may view real data and how authorisation works).
   Verification: there is an internal “support with real data” procedure and it is used to open tickets.

4. Administration (Friday): review end-of-service clauses: export, return and deletion. If missing, request an addendum.
   Verification: the contract describes export format and deletion, or there is a written commitment from the provider.

5. Data protection officer / adviser (end of week): check consistency with your record of processing activities and contracts.
   Verification: the provider register is updated and matches the contracts and annexes stored.

Frequently Asked Questions

When do I have to sign a data processor contract?

You must sign it before the provider accesses or hosts personal data on behalf of the clinic. If they are already operating, regularise it as soon as possible and document the signature date. Generic terms do not replace a contract if they do not cover the content required by the GDPR.

What happens if the provider uses undeclared sub-processors?

That becomes a compliance risk and a loss of control over the processing. Demand the list of sub-processors, the notification mechanism for changes and your right to object. If they refuse in writing, consider changing provider.

How do I verify where the data are actually hosted?

Request it in writing in the contract or an annex: country of hosting and country of backups. Also ask whether there is access from outside the EEA for support or administration. If the answer is vague, insist until it is verifiable.

Is the contract valid if signed by my accounting firm on my behalf?

It is valid only if the signatory has sufficient powers or authorisation from the clinic to contract and give instructions to the data processor. Confirm internally who may sign and keep evidence of that representation. If in doubt, have it signed by management or administration with power of attorney.

This article is for informational purposes and is not legal or tax advice. Consult your adviser before making decisions.

External Links

• ¿Qué debe contener un contrato de tratamiento de datos personales? | Empresas | INCIBE
• contrato, el encargado del tratamiento
• Responsable o encargado del tratamiento de datos | Data protection guide for small business | European Data Protection Board
• ¿Cómo sé si soy un responsable o un encargado del tratamiento? | AEPD
• 2.8.- RESPONSABLE Y ENCARGADO DEL TRATAMIENTO | AEPD
• El RGPD
• Si hay transferencia internacional, debe estar cubierta por los mecanismos del RGPD
• Las medidas de seguridad deben ser adecuadas al riesgo, y en sanidad el listón sube porque hablamos de datos de salud (categorías especiales). La AEPD
• Cuando hay una brecha (pérdida, acceso indebido, ransomware), la clínica necesita dos cosas: enterarse rápido y poder actuar. El RGPD
• Tienes que firmarlo antes de que el proveedor acceda o aloje datos personales por cuenta de la clínica. Si ya está en marcha, regularízalo cuanto antes y documenta la fecha de firma. No lo sustituyen condiciones genéricas si no cubren el contenido exigido por el RGPD