HIPAA-Compliant Website on Drupal: What It Actually Takes

No website is HIPAA compliant out of the box, and no content management system is either, Drupal included. HIPAA regulates organisations and the protected health information (PHI) they handle, not software. A healthcare website becomes a HIPAA problem in specific places: where it collects health details through a form, where patients log in, and where tracking code sends visitor data to someone else. Get those three right and the rest of the site is an ordinary, well-built website.

We read every healthcare case study published on drupal.org over the last two years to see how the teams building these sites actually think about it. The answer is instructive: accessibility comes up in half of them, and HIPAA in one.

What “HIPAA-compliant website” actually means

HIPAA’s Privacy and Security Rules apply to covered entities (healthcare providers, health plans and clearinghouses) and to the business associates that handle PHI on their behalf. PHI is health information that can be tied to a person: a name, an email address or an IP address next to a condition, an appointment or a test result. The Security Rule then asks for administrative, physical and technical safeguards around electronic PHI, including access controls, audit controls, integrity protection, authentication and transmission security.

A page explaining knee replacement surgery holds no PHI. A form on that page asking for your name, email and which knee hurts does. That is why the useful question for a healthcare website is not “is the site compliant?” but “where on the site does PHI enter, where does it go, and who signed for it?”

What 46 healthcare Drupal projects show

We coded all 46 case studies tagged Healthcare on drupal.org between November 2024 and October 2026: hospitals and health systems, pharma brands, insurers, public-health bodies and research organisations. For each one we recorded which topics the write-up mentions.

Three things stand out. Accessibility (52%) and design systems (50%) lead, because a hospital site is a large, long-lived publishing platform that many departments edit, and both problems get worse with every new page. Migration shows up in more than a third, which matches what we see in the work itself: many healthcare sites were built on Drupal 7 or an older proprietary CMS and are being rebuilt on Drupal 10 or 11.

And HIPAA appears once, in a case study from a hospital in Colombia. Part of that is geography: the set includes NHS trusts in England, a Saudi national health centre and European pharma, none of them under HIPAA. But the bigger reason is architectural. Most of these sites are deliberately built to hold no patient data, which is the right call and the first lesson of this article. A mention in a case study is not proof of what a project did, so treat the chart as a picture of priorities rather than a compliance audit.

The three places PHI gets into a healthcare site

1. Forms that ask about health

Appointment requests, referral forms, symptom checkers and “ask a nurse” forms all collect PHI. You have two sound options. The first is to embed a HIPAA-eligible form service that signs a BAA, so the data never touches Drupal. The second is to keep the form in Drupal’s Webform module and treat Drupal as part of your HIPAA environment: encrypt submissions with Webform Encrypt (still in beta for Drupal 10 and 11), keep the keys outside the database with the Key module, host on infrastructure that signs a BAA, and purge submissions on a schedule.

The detail that catches most teams is the notification email. A Webform that emails the full submission to a shared inbox has just sent PHI through your mail provider. Send a “new submission waiting” alert instead, and make staff read the entry inside the secured site.

2. Patient logins

Medical records, results, secure messages and billing belong in the patient portal your EHR vendor runs, usually on its own domain. Drupal’s job is to link to it clearly and get out of the way. If your Drupal site does have a logged-in area that shows anything about a person’s care, that area is in scope: two-factor authentication, automatic logout, an audit trail, no page caching of personal content, and a host with a BAA.

3. Tracking technology

This is where the expensive mistakes have happened. In December 2022 the HHS Office for Civil Rights issued guidance treating tracking code on hospital websites as a potential disclosure of PHI. In June 2024 a federal court in Texas, in American Hospital Association v. Becerra, vacated the part of that guidance covering unauthenticated pages, and HHS withdrew its appeal that August. The ruling was about public pages; pages behind a login were not part of it.

The court case did not end the lawsuits. Advocate Aurora Health settled a class action over Meta and Google pixels for $12.225 million in 2024, and Mass General Brigham paid $18.4 million to settle claims about cookies and analytics on its public websites without visitor consent. The safe pattern is simple: no advertising pixels on logged-in pages, form steps or confirmation pages; consent before any analytics, handled in Drupal by Klaro or EU Cookie Compliance; and no analytics or chat vendor on pages that collect PHI unless it signs a BAA.

Hosting and the BAA

Because Drupal is open-source software, there is no Drupal company to sign a Business Associate Agreement. The contract that matters is with whoever hosts the site and every service that touches PHI. Acquia, the managed Drupal platform co-founded by Drupal’s creator, says on its healthcare page that it offers a HIPAA BAA, and the major clouds sign BAAs for their HIPAA-eligible services. Whoever you use, get the answer in writing and check what it covers: backups, disaster-recovery copies, logs and support staff access, not just the web servers.

If the site holds no PHI because forms and logins live with BAA-covered vendors, ordinary Drupal hosting is fine for the public pages. Our Drupal hosting comparison covers speed and cost for that part of the decision.

The Drupal module stack for a HIPAA-conscious build

Modules do not make a site compliant; a risk analysis, policies, training and signed BAAs do. But when Drupal is part of the environment, these drupal.org projects cover the technical safeguards, and all of them support Drupal 10 or 11 as of October 2026:

• Data: Webform Encrypt and Encrypt for submissions, Field Encryption for sensitive fields (its current release needs Drupal 11.3), Key for keys stored outside the database, and Drupal’s private file system for uploads.
• Access: Two-factor Authentication (TFA), Automated Logout, Password Policy, Login Security and Session Limit.
• Audit: Admin Audit Trail to record who changed what, plus the host’s server and database logs.
• Hardening: Security Kit for security headers and Security Review to catch configuration mistakes. Our Drupal security best practices guide covers the rest of the hardening list.

What is changing, and what to do about it now

On 6 January 2025 HHS proposed a major update to the HIPAA Security Rule. It would make encryption of electronic PHI mandatory at rest and in transit, and require multi-factor authentication for systems that access it. It is still a proposal: HHS missed its May 2026 target, and its regulatory agenda now lists the final rule for around July 2027. On a new build, encryption and two-factor login cost little, so build as if the rule were already in force.

The deadline that is actually on the calendar is accessibility. Under HHS’s Section 504 rule, organisations that receive HHS funding must make their websites and apps conform to WCAG 2.1 Level AA. In May 2026 HHS moved the dates back a year: 11 May 2027 for organisations with 15 or more employees, and 10 May 2028 for smaller ones. It is no surprise that half the healthcare case studies above lead with accessibility.

The launch checklist

If you are planning a healthcare rebuild, the cheapest moment to get this right is before the first template is designed: decide where every form posts, where every login goes and which scripts may load on which pages, then build the public site around that map. If you are moving off Drupal 7 or an older platform, our Drupal migration team scopes exactly this as part of the plan, and our Drupal support plans cover the security updates afterwards. Send us the site and we will come back with the map and a fixed price.

Sources

• drupal.org case studies: 46 tagged Healthcare, November 2024 to October 2026, coded by Gspikes in October 2026
• Holland & Knight on American Hospital Association v. Becerra (June 2024) and Fierce Healthcare on the withdrawn appeal
• HHS: Office for Civil Rights extends web and mobile accessibility compliance deadline (7 May 2026)
• HIPAA Journal: HIPAA updates and changes in 2026, on the status of the Security Rule proposal
• HIPAA Journal on the Advocate Aurora Health settlement and the Mass General Brigham settlement
• Acquia’s healthcare page, on its HIPAA BAA