Common GDPR Mistakes on Healthcare Websites: 10 Problems to Check

A useful review starts with the complete journey of personal information rather than the website homepage.

For every collection point, ask:

The answers often reveal problems that a privacy policy review will miss.

For example, an appointment form may send information to WordPress, email, a booking platform and a CRM. Each destination creates a separate question about purpose, access, retention, security and contractual arrangements.

For the broader framework, also review the UK GDPR requirements for healthcare organisations.

Security is important, but GDPR compliance covers more than encryption and passwords.

Your review should also consider lawfulness, transparency, purpose limitation, data minimisation, storage limitation, individual rights and accountability.

A technically secure website can still collect excessive information or retain it indefinitely.

Look closely at fields that collect symptoms, diagnoses, treatment information, referral details, patient portal information or health-related free text.

The ICO defines health data broadly. It can include information collected when someone registers for health services, receives treatment or makes an appointment where the information reveals something about their health.

Implementation insight: Build your audit around actual data flows, not website pages. A single form or integration can create several processing activities that require separate assessment.

What it looks like

A privacy policy may describe general processing but omit the booking provider, analytics tools, live chat, CRM integration or actual retention arrangements.

Another common problem occurs when a website changes significantly but the privacy information remains unchanged.

Why it matters

Privacy information should reflect the processing that actually occurs. A policy cannot correct an incorrectly configured form, tracking script or third-party integration.

The UK GDPR principles include lawfulness, fairness and transparency, purpose limitation, data minimisation, storage limitation and accountability. Your website implementation needs to support those principles in practice.

What to check

How to fix it

Map the real processing first, then update your privacy information.

Repeat the review whenever you introduce a new form, booking system, analytics platform, CRM, patient portal or other significant processing activity.

Implementation insight: Compare your privacy notice against the website's actual network requests, databases and integrations. The technical implementation should provide evidence for the information presented to users.

What it looks like

An appointment form asks for symptoms. A referral form requests clinical information. A contact form invites patients to describe their diagnosis or condition in free text.

The organisation may identify an Article 6 lawful basis but fail to document the separate Article 9 analysis.

Why it matters

Health data is special category data under UK GDPR. Article 6 and Article 9 perform different functions, so identifying one does not automatically satisfy the other.

The processing also needs to be necessary and proportionate for the stated purpose.

What to check

How to fix it

Map every health-related field and remove information that the workflow does not genuinely require.

Document the relevant Article 6 and Article 9 analysis before processing begins. For detailed guidance, refer to the UK GDPR Article 9 requirements for health data.

Implementation insight: Free-text fields deserve particular scrutiny because users can disclose significantly more health information than the original form designer intended.

What it looks like

Analytics loads before the user makes an appropriate choice. Marketing pixels fire immediately. The reject option is difficult to find, or users cannot easily change their preferences later.

A privacy policy may explain tracking without the technical implementation actually enforcing the stated choice.

Why it matters

PECR applies to technologies that store information on, or access information from, a user's terminal equipment. This includes cookies, tracking pixels, web storage, scripts and tags. Where personal data is involved, UK GDPR can also apply.

The technical behaviour therefore matters as much as the wording displayed in the consent interface.

What to check

How to fix it

Categorise technologies correctly and prevent technologies that require consent from operating before the appropriate choice is recorded.

Test the implementation after significant changes to analytics, tag management or third-party embeds.

Implementation insight: Test cookie behaviour using browser developer tools rather than trusting the banner configuration. A green consent interface does not prove that tracking is technically blocked.

What it looks like

A marketing team installs analytics without a privacy review. User identifiers are transmitted unnecessarily. Event names reveal health-related information, or form interactions expose sensitive context to a third-party analytics provider.

Page URLs and search terms can also create unexpected information flows.

Why it matters

Analytics is not automatically unlawful because of the product selected. The assessment depends on what information the configuration collects, why it is collected, where it goes, who receives it and which legal requirements apply.

PECR can also apply to tracking technologies before you consider the separate UK GDPR questions.

What to check

How to fix it

Minimise the information collected and remove health-related parameters that are unnecessary for measurement.

Review vendor roles and contractual arrangements, then document the actual configuration rather than relying solely on the provider's default settings.

Implementation insight: Inspect live network requests during testing. Vendor documentation may describe available features, but your implementation determines what information actually leaves the website.

What it looks like

A form uses HTTPS, but submissions remain stored indefinitely. Copies are sent to several inboxes, downloaded onto staff devices or retained in website backups without a defined lifecycle.

Access may also extend to staff who do not need the information.

Why it matters

HTTPS protects information during transmission, but it does not resolve minimisation, storage, access, retention or downstream processing.

Appropriate security measures need to reflect the risks associated with the information and processing involved.

What to check

How to fix it

Collect only the information required for the stated purpose. Restrict access and establish appropriate retention and deletion controls.

Review where submissions are copied or forwarded, particularly when they may contain health information.

Do not automatically classify Gmail or Outlook as GDPR non-compliant. Assess the actual account configuration, provider relationship, security controls, information involved and organisational requirements.

Implementation insight: Trace a test submission from the browser through every destination. The form database, email account, backup system and staff workflow may each require separate controls.

What it looks like

A booking platform is added through an iframe, plugin or API without documenting where information goes.

The organisation may not have reviewed the provider's role, subprocessors, hosting arrangements, international access, retention or deletion process.

Why it matters

A booking provider may process personal data on your behalf or have another role, depending on the actual arrangement.

The product name does not determine the legal relationship. You need to understand what the provider does with the information and under whose instructions.

What to check

How to fix it

Complete the vendor assessment before integration.

Document the processing relationship, configure only the required fields and review the arrangement when the provider changes its service, terms or processing activities.

Implementation insight: Treat the booking system as part of your website architecture rather than an isolated marketing feature. Its database and integrations become part of your overall data flow.

What it looks like

A chat widget appears across the website and patients enter symptoms, diagnoses or other clinical information into free-text conversations.

Transcripts may then be stored by a third party and accessed by support teams.

Why it matters

Free-text chat can become a health data channel even when the organisation never intended it to operate as one.

A general customer support tool may therefore create different privacy and security considerations when used by patients.

What to check

How to fix it

Tell users clearly what information they should not submit where appropriate.

Limit transcript retention, restrict access and assess whether the provider is suitable for the information involved.

Where clinical information needs to be exchanged, use a communication pathway designed for that purpose.

Implementation insight: Review the wording around the chat widget as part of the technical control. User behaviour can turn a general support tool into a sensitive information channel.

What it looks like

Contact submissions remain in WordPress indefinitely. Old booking enquiries remain accessible. Former accounts stay active unnecessarily, while backups contain historical personal data without a defined lifecycle.

CRM and website retention practices may also differ.

Why it matters

Storage limitation is a core UK GDPR principle. Keeping information indefinitely because storage is inexpensive does not establish a valid retention rationale.

What to check

How to fix it

Define retention according to the processing purpose and applicable legal or professional requirements.

Automate deletion where practical and assess backups separately, because deleting a live record does not necessarily remove historical copies immediately.

Implementation insight: Create a retention map across connected systems. Deleting information from WordPress has limited value if the same information remains indefinitely in email, CRM exports or third-party platforms.

What it looks like

The privacy policy explains individual rights, but staff do not know who handles requests or where relevant information is stored.

Data may be fragmented across the website, CRM, booking system, email and support tools.

Why it matters

Individual rights require operational processes, not only policy wording.

A fragmented architecture can make it difficult to locate, correct, restrict or delete information when appropriate.

What to check

How to fix it

Assign ownership for rights requests and map which systems hold personal information.

Document escalation routes and vendor responsibilities, then test the process periodically.

Implementation insight: Include rights handling when designing integrations. A technically convenient system can become a governance problem if your team cannot reliably identify where a person's information resides.

What it looks like

A website passed an internal review several years ago, but new plugins, booking tools, analytics, advertising technology or patient functionality have since been introduced.

The privacy notice and governance documentation may not reflect those changes.

Why it matters

Website processing changes throughout the product lifecycle. The ICO states that data protection by design and by default should be considered from the design stage and throughout the lifecycle of processing.

A launch review therefore cannot replace ongoing governance.

How to fix it

Add privacy review to your website change process.

Recheck forms, cookies, analytics, retention, vendor contracts and data flows after significant releases.

Website changes that should trigger a GDPR review

Implementation insight: Make privacy review part of release management. A new plugin or integration should not reach production without considering what information it collects, where it sends it and how long it remains available.

A structured audit is more useful than reviewing the privacy policy once a year.

Record contact forms, appointment forms, referral forms, newsletter subscriptions, patient registration, chat and portal functions.

Identify cookies, pixels, analytics, tag managers, embedded services and other storage or access technologies.

Document the CMS, email systems, CRM, booking provider, cloud services, APIs and other third parties receiving information.

Look specifically for symptoms, conditions, treatments, diagnoses and health-related free text.

Review Article 6, Article 9, PECR, privacy information, DPA arrangements, retention and DPIA requirements where appropriate.

Submit test forms, inspect network requests, review browser storage, test cookie behaviour, inspect permissions and verify deletion processes.

Classify findings as critical, high, medium or low based on the potential impact and context.

Implementation insight: Keep evidence with each finding. Screenshots, test submissions, network captures, configuration records and vendor documents make remediation easier to verify later.

Not every finding carries the same risk. Prioritisation should consider the nature of the information, likelihood, severity, affected individuals and processing context.

Start with:

A serious issue may require immediate restriction of processing while the organisation completes its assessment.

Where a personal data breach occurs, the ICO states that a notifiable breach must be reported without undue delay and, where feasible, within 72 hours of awareness. Organisations should also maintain appropriate breach records.

Implementation insight: Do not rank issues simply by how easy they are to fix. A minor wording change may be less important than an uncontrolled third-party data flow.

A review should happen whenever the website's processing changes materially.

Consider a review:

The ICO's data protection by design guidance supports considering privacy from initial planning through the lifecycle of the service or system.

Implementation insight: Add a GDPR review trigger to your website change management process. This makes privacy part of delivery governance rather than an emergency exercise after launch.

Qrolic Health approaches healthcare website privacy as a technical and governance problem that must be reflected in the actual architecture.

In our work with patient-facing healthcare platforms, we look beyond the privacy policy and inspect where information moves between forms, databases, APIs, third-party services and staff workflows.

That approach helps identify gaps across:

The objective is not to label a website “GDPR compliant” based on a checklist alone. The practical goal is to translate your privacy and governance requirements into website architecture and technical controls that your team can review and maintain.

For organisations planning NHS-facing digital services, see NHS compliant website design and development.

Common GDPR mistakes on healthcare websites rarely come from one missing sentence in a privacy policy. They usually emerge from the connection between forms, tracking, booking platforms, analytics, patient workflows, third parties, retention and staff access.

A meaningful review therefore needs to follow the information itself. Identify what enters the website, where it travels, why it is processed, who receives it, how long it remains available and what technical controls govern each stage.

For healthcare organisations, health information requires particular attention because Article 6 and Article 9 assessments may both apply. Cookie technologies, vendors, retention and individual rights also need practical implementation controls.

If your audit has identified gaps, the next step is to convert those findings into a prioritised remediation plan and an architecture your team can maintain.