In this guide (7)
- 1Why healthcare data requires a different level of protection
- 2Specific technical requirements for healthcare facility websites
- 3NIS2: the second obligation that many healthcare facilities ignore
- 4Performance: why it matters for a clinic too
- 5The DPIA: when it's mandatory and what it must include
- 6The case of the patient reserved area: additional requirements
- 7What actually happens in the event of a breach
The website of a clinic or medical practice handles something no other industry handles to the same extent: health data.
A patient who books an appointment online, who fills out a form for an initial consultation, who uploads test results or describes symptoms through a private area — is entrusting your digital infrastructure with information that the GDPR classifies as a special category of personal data, the one with the highest level of protection provided for by the law.
Yet most Italian clinic and medical practice websites run on WordPress with uncertified plugins, forms that save data in plain text in the database, and no data protection impact assessment ever carried out.
This article explains what the CMS that runs your healthcare facility's website should do — technically and legally. Not to scare you, but because knowing what's at stake is the first step toward handling it properly.
Why healthcare data requires a different level of protection
The GDPR distinguishes between common personal data and special categories of data. Health-related data falls into the special categories — along with genetic, biometric, judicial, religious and sexual data. This classification is not merely formal: it entails additional technical and organizational obligations that apply to anyone processing such data, including private healthcare facilities.
In practice, if your clinic's website collects even just the reason for the visit through a booking form, you are processing special data. If you have a private area where patients view test results or communicate with doctors, you are processing special data. If the contact form allows the patient to describe their clinical situation, you are processing special data.
The technical measures required for this data are not optional: they are legal obligations with penalties of up to 20 million euros or 4% of global annual turnover for the most serious violations.
Specific technical requirements for healthcare facility websites
1. Encryption of data in forms and private areas
Every piece of health data transmitted through the website — bookings, symptom descriptions, test result attachments — must be protected both in transit and at rest.
HTTPS transmission is the minimum requirement, but it is not sufficient for health data. Database storage must include application-level encryption: the data must be unreadable even to anyone who physically accesses the database without the decryption keys. On WordPress, the vast majority of form plugins save data in plain text in the database table — accessible to anyone with access to the phpMyAdmin panel or the database backup.
KeideaCMS uses AES-256 encryption on form data in the database — the same standard used in banking and healthcare. It's not an option to be enabled: it's built into the core of the system. You can learn more about KeideaCMS's security architecture here.
2. Separation between the public environment and the administration panel
On WordPress, the admin panel is reachable from any browser at /wp-admin — publicly accessible, known to all attackers, and the target of automated access attempts every day. For a website that handles health data, this configuration is unacceptable.
The CMS admin panel must be separate from the public environment, accessible only from authorized IPs, and protected by two-factor authentication. Not as an additional configuration — as a default architectural requirement.
3. Logs of access to health data
The GDPR and the guidelines issued by the Italian Data Protection Authority for the healthcare sector require traceability of access to patient data: who accessed which data, when, and from which device. This is not just a security requirement — it's an accountability requirement that makes it possible to respond to any requests from the supervisory authority.
On WordPress, this functionality does not exist by default and requires additional plugins — plugins that in turn add attack surface and depend on the quality of the developer maintaining them.
4. Management of digital informed consent
To collect health data through the website, the patient must give specific, informed and documentable consent. Not the generic cookie banner — explicit consent for the processing of health-related data, with the ability to revoke it at any time and with tracking of the date and method of acquisition.
This consent must be stored in a way that can be demonstrated in the event of a dispute. A correct implementation requires the CMS to handle this logic natively, not through third-party plugins with their own data retention policies that are not always transparent.
5. WAF and protection against SQL injection
An SQL injection attack on a database containing health data is a special category data breach. The obligation to notify the Authority kicks in within 72 hours, the reputational risk is high, and the penalties for failing to adopt adequate technical measures add to those for the breach itself.
A Web Application Firewall built into the CMS core — not added as a plugin — intercepts these requests before they reach the database. This is the difference between architectural security and add-on security: the former solves the problem at its root, the latter reduces the risk without eliminating it.
Once you've chosen the right CMS, the next step is building a professional company website with everything included, from day one online.
NIS2: the second obligation that many healthcare facilities ignore
Since 2024, the European NIS2 directive has extended cybersecurity requirements to a much broader range of entities, explicitly including the healthcare sector. Medium and large private healthcare facilities fall into the category of important entities, with specific obligations for IT risk management and incident notification.
Among the NIS2 requirements relevant to web infrastructure: adoption of proportionate technical measures to manage risks to the security of IT systems, the ability to detect and respond to incidents, and notification to the competent authorities within 24 hours of discovering a significant incident.
A website that manages online bookings, patient reserved areas or clinical communications is part of the IT infrastructure subject to NIS2. It is not a technical detail to delegate to the hosting provider — it is a responsibility of the facility's management.
Performance: why it matters for a clinic too
There is a widespread idea that healthcare facilities don't need fast websites — that patients look for reliability, not speed. This is wrong for two concrete reasons.
The first is ranking. Google uses Core Web Vitals as a ranking factor in organic search. A slow site is penalized in searches for "clinic [city]", "specialist doctor [area]", "appointment booking [specialization]". In a market where many facilities invest in online visibility, site speed directly affects the ability to acquire new patients through organic search.
The second is the patient experience. A patient who arrives at your facility's website worried about their health and finds a slow site, difficult to navigate on mobile, with a booking form that doesn't work properly — doesn't book. They go to the competing facility's site that loads in a second.
KeideaCMS maintains a TTFB under 200ms and Core Web Vitals scores structurally in the green. Not with cache plugins added on top of an unoptimized system — with an architecture designed for speed from the ground up.
The DPIA: when it's mandatory and what it must include
For high-risk processing — and the processing of health data through a website almost always falls into this category — the GDPR requires a Data Protection Impact Assessment (DPIA) before starting the processing.
The DPIA for a site that handles health data must include: a description of the processing and its purposes, an assessment of the necessity and proportionality of the processing operations, an assessment of the risks to the rights and freedoms of data subjects, and the technical and organizational measures adopted to manage those risks.
The section on technical measures is where the CMS infrastructure is examined in detail. A CMS with AES-256 data encryption, integrated WAF, separate admin panel, access logs and managed updates is much more defensible in a DPIA than a WordPress site with various plugins — some of which may have last been updated two years ago.
The case of the patient reserved area: additional requirements
Many clinics and diagnostic facilities are implementing reserved areas where patients can view reports, communicate with doctors, and view their visit history. These systems significantly amplify security requirements.
A patient reserved area requires: robust authentication with two-factor authentication option, sessions with automatic timeout, end-to-end encryption for clinical communications, granular permission control (doctor X only sees patients assigned to them), and a complete log of every access to every document.
Implementing these requirements on WordPress with third-party plugins is technically possible but architecturally fragile: every plugin adds dependencies, every update is a potential breaking point, and the responsibility for compliance remains yours even if the problem lies in the code of a plugin written by a developer on another continent.
What actually happens in the event of a breach
It is worth being explicit about what a healthcare data breach means for a private medical facility.
The obligation to notify the Data Protection Authority arises within 72 hours of discovery. If the exposed data concerns patients' health, they must be notified individually. The Authority can open an investigation that assesses the technical measures adopted — and if it finds them inadequate, the sanctions add up. Media coverage of a healthcare data breach at a private facility has reputational impacts that are not easily recovered.
And then there's professional liability. Doctors and medical directors are responsible for processing their patients' data — not just the IT department or the hosting provider. A breach caused by inadequate technical measures can have consequences that go beyond administrative sanctions.
If you want to concretely assess the current state of your facility's website — security, GDPR and NIS2 compliance, performance — you can request a free audit. You can also see why WordPress isn't the right choice for healthcare facilities here.
