The question always arrives at the same point in the conversation: "Fine, but is it GDPR compliant?". It is the right question, and it is also the one nobody can answer with a flat yes, because compliance is not a property of software. The GDPR does not certify programs: it sets obligations for whoever processes the data. A medical practice can use a tool with American infrastructure lawfully, and can breach the regulation with a European practice management system, depending on how it is configured and what is put into it.

This article sets out what has to be checked, decided and written down before GoHighLevel — or any equivalent CRM — is allowed into a European medical practice. It is not legal advice: it is the checklist we work through before switching a system on, to be validated by your own data protection adviser.

Who is the controller and who is the processor

The first point is also the most misunderstood. The practice is the controller: it decides which data to collect, for what purposes and for how long. The platform is a processor, meaning it processes that data on the practice's behalf and only on its documented instructions.

Practical consequences follow, and no vendor can take them on for you:

  • the privacy notice to patients is written by the practice, and it has to mention the use of third-party tools for communications;
  • the record of processing activities is kept by the practice, and the CRM belongs in it;
  • the data protection impact assessment, where one is required, is carried out by the practice;
  • access, rectification and erasure requests are received and handled by the practice, using the tools the platform provides.

If a vendor tells you "we take care of the GDPR for you", they have just described something they cannot do. They can give you the instruments; the accountability stays with you.

The data processing agreement

Article 28 of the GDPR requires a written contract between controller and processor. Without that signed document, using the platform for patient data is irregular no matter how secure the technology is.

What it has to cover: the subject matter and duration of the processing, the categories of data and of data subjects, the controller's documented instructions, a confidentiality obligation, security measures, the rules on sub-processors, assistance to the controller with data subject rights and with breaches, and what happens to the data when the relationship ends.

HighLevel publishes its own data processing agreement and treats it as entered into when the customer accepts the terms of service. In the version consulted on 31 July 2026, marked as last updated in July 2026, the agreement incorporates the standard contractual clauses for transfers and provides for written notice of new sub-processors, with thirty days to object. Two things still have to be done by hand, because these documents change over time and an article is not a contractual source: read the version in force at the moment of activation, and file the list of sub-processors together with the breach notification procedure.

Where the data sits

HighLevel is a US company. Its privacy and security page states that the platform is hosted on Google Cloud Platform, and the public sub-processor list places data storage with Google Cloud and Amazon Web Services in the United States: the only entry outside the US in the entire list is the support company in India. No EU data residency option appears anywhere in the public documentation (sources consulted on 31 July 2026). For a European account, then, the realistic starting point is that the data is processed in the United States.

The legal point, in any case, is not "data must stay in Europe": the GDPR permits transfers to third countries where they are covered by appropriate safeguards. For the United States the relevant instrument today is the adequacy decision on the Data Privacy Framework, alongside or replaced by standard contractual clauses with a transfer impact assessment. The three concrete questions to put to the vendor are:

  1. On what legal basis does the transfer take place (framework certification, standard clauses, or both)?
  2. Is there a transfer risk assessment that the practice can attach to its own documentation?
  3. Which sub-processors handle the data, and where?

Keep the answers. If you are ever inspected, the question will not be "was the software compliant", but "how did you assess and document the choice".

A note of realism is worth adding: the same questions apply to email, to video consultation services and to the cloud practice management system the practice already uses. The CRM does not introduce a new problem, it makes visible a problem that often already exists undocumented.

HIPAA is not the GDPR

This is the most common misconception among practices evaluating American platforms for healthcare.

HighLevel offers an add-on oriented towards HIPAA compliance: the official documentation, last updated on 11 June 2026 and consulted on 31 July 2026, puts it at US$297 per month, with a Business Associate Agreement included, applied to every sub-account under the agency account and with no way to switch it off once purchased. That irreversibility is worth weighing before you click. The main point, though, is a different one: HIPAA is United States legislation on health data, it follows a different logic, it applies to entities defined under American law, and it produces no compliance effect in Europe. Switching that module on does not make processing GDPR compliant, just as signing a European agreement does not make you HIPAA compliant.

It is worth understanding what the add-on does bring in practical terms: typically tighter access controls, audit logging, and restrictions on the processing of certain data categories. Those are security measures with real value in a European setting too, but they are to be assessed as technical measures under Article 32 of the GDPR, not as a compliance badge.

What does not go into the CRM

This is the design decision that removes most of the problem upstream, and it is an organisational choice rather than a technical one.

Health data falls under the special categories of Article 9 of the GDPR: its presence raises the risk level, lengthens the list of obligations and makes an impact assessment considerably more likely. The simple route is not to let it in.

What belongs in the CRM: name, contact details, preferred channel, contact source, the logistical status of the enquiry, consent records, appointment dates, and the history of messages sent.

What does not belong in the CRM: diagnoses, treatments, reports, test results, clinical notes, the reason for the visit where it reveals a condition, and service categories that amount to a diagnosis. The clinical record stays in the healthcare system, with its own obligations and its own access controls.

Watch the less obvious point: the separation breaks down in the details. A tag named after a condition, a note typed in a hurry by the front desk, a calendar entry describing the treatment, a "notes" field used as a diary. You need written rules on what may be typed, and a periodic review of tags and fields. It is the kind of maintenance nobody schedules and that prevents most of the trouble.

Consent and legal bases, without the confusion

A CRM does not "require consent": every processing operation has its own legal basis, and telling them apart avoids both overreach and breaches.

  • Reminders and service messages about an appointment already booked serve the performance of the service the patient asked for; marketing consent is not the relevant basis.
  • Recall and promotional messages to people with no appointment in the diary require specific, documented and revocable marketing consent. The consent tag has to be a condition inside the workflow, not something someone remembers to check.
  • Messages to colleagues and professionals — a guide downloaded from the website, for instance — are a B2B audience with different rules, but an unsubscribe option is always required.

Consent, where it is needed, has to be traceable: when it was collected, how, and with what wording. A ticked box whose origin nobody can establish is worth as much as no consent at all if it is ever challenged. And a withdrawal has to be executed everywhere, not only in the list the request came from.

There is also a constraint that comes from a different body of law and that the CRM knows nothing about: healthcare advertising rules. In Italy, Law 145/2018 as amended by Decree-Law 69/2023 prohibits attention-grabbing or suggestive elements — discounts, offers, promotions — in healthcare communication, which means nothing of the kind may be sent to patients. Comparable restrictions exist across other European jurisdictions in different forms, and they have to be checked against the country where the practice operates. No technical configuration protects you from badly written wording.

Data subject rights and retention

Three things to test before going live, because they are always discovered at the worst moment.

Export. If a patient asks for a copy of their data, the practice has to be able to extract it in full: contact record, messages sent, tags, notes. It is worth trying it once on a test contact.

Erasure. Deletion has to be effective, including copies in lists and connected systems, and it has to be documented. One point about backups is worth knowing in advance: HighLevel's processing agreement provides for deletion or return of the data at the end of the relationship, but expressly excludes copies archived on backup systems, which stay isolated and protected (version consulted on 31 July 2026). How long they stay there is not stated in the public document: ask the vendor in writing and file the answer with your retention policy.

Retention. The GDPR requires data not to be kept longer than necessary. You need a written policy: how long a contact who never became a patient is kept, how long the message history is kept, and what happens to the data if the practice stops using the platform. That last point — return and deletion at the end of the relationship — belongs in the processing agreement.

The operational summary

Before switching the system on, a practice should have: a signed and filed processing agreement, the list of sub-processors, a documented legal basis for the transfer outside the EU, an updated privacy notice, an updated record of processing activities, written rules on what does not enter the CRM, a map of legal bases by message type, a retention policy, a procedure for data subject rights, and a real-world test of export and erasure.

It is a long list, and no platform ticks it off for you. But it is a finite list: you do it once, document it, and update it when something changes. What the platform actually does is described on the GoHighLevel for medical practices page; the workflows that follow from it, with their own boundaries, are in the article on seven GoHighLevel automations for a medical practice.

Frequently asked questions

Is GoHighLevel GDPR compliant?

The question is badly framed: the GDPR does not certify software. The platform provides contractual and technical instruments; compliance depends on how the practice configures the system, what it puts into it, and which documents it keeps.

Does patient data end up in the United States?

In all likelihood, yes. HighLevel's documentation points to hosting on Google Cloud and places storage with US providers, and no EU data residency option is publicly documented (checked on 31 July 2026). The transfer is still permitted: HighLevel states that it is certified under the EU-U.S. Data Privacy Framework and incorporates the standard contractual clauses into its processing agreement. Documenting the choice, and disclosing it in the privacy notice, is the practice's job.

Is a written agreement with the platform required?

Yes. Article 28 of the GDPR requires one. It has to be obtained, read, accepted through the vendor's procedure and kept on file together with the list of sub-processors.

Does the HIPAA add-on make us GDPR compliant?

No. HIPAA is United States legislation and produces no European compliance. The technical measures that module introduces may be useful, but they count as security measures under Article 32, not as compliance.

Can we record the diagnosis in the CRM to personalise messages?

No, and it would be pointless anyway: compliant messages to patients are generic by definition. Health data stays in the clinical system; only identity, logistical and consent data enter the CRM.

Who helps us set all this up?

The documentation side belongs with your own data protection adviser; the technical configuration of the CRM can be handled by the practice or by an external partner. If you want us to look at where your practice stands today, request an assessment with no commitment; for the wider picture there is the free guide to medical marketing.