A HIPAA-ready Drupal build on Varbase is a Drupal 11 site whose access control, authentication, audit logging, and integrity safeguards are configured to meet HIPAA's technical safeguards (45 CFR §164.312), running on HIPAA-eligible hosting under a signed Business Associate Agreement. No CMS is "HIPAA compliant" on its own. Varbase supplies hardened defaults through its security recipe; the covered entity is responsible for compliance.

Can a Drupal Site Actually Be HIPAA Compliant?

No content management system is HIPAA compliant on its own, Drupal included. HIPAA doesn't certify software. Compliance is a system that spans three layers: the CMS and its configuration, the hosting environment under a BAA, and the covered entity's own policies. A gap in any one undermines the other two.

That sets the scope. Drupal and Varbase cover a large share of HIPAA's technical safeguards at the application layer, which is what the rest of this article maps. They can't sign your BAA, run your risk analysis, or train your workforce; those stay with you.

Suitability isn't the worry it once was. Drupal already runs in some of the most regulated environments in the US: the leading managed Drupal cloud is FedRAMP-authorized for federal workloads and meets the HIPAA Security Rule for ePHI.

The question for a healthcare build was never whether Drupal can carry sensitive data. It's how the platform is configured, and who owns each control.

Which HIPAA Technical Safeguards Can a Varbase Build Cover Out of the Box?

A Varbase build covers most of HIPAA's technical safeguards at the application layer on day one, through its Security Base, Users Base, and Admin Base recipes. The rest belong to hosting and governance. The table below splits every safeguard across the three ownership layers.

HIPAA Technical Safeguards: Platform vs. Configuration vs. Hosting on Varbase

HIPAA safeguardWhat a Varbase build providesWhat your team configures
Access control (unique user ID, least privilege)Distinct role hierarchy (Users Base); per-user Drupal accounts; content/field/section-level access by roleAutomatic logoff (addressable); emergency-access procedure (required); role-to-job mapping
Person/entity authenticationPassword Policy; Flood control; Username Enumeration Prevention; CAPTCHA, reCAPTCHA, Honeypot, Antibot; Security Kit headersAdd and configure MFA; lock down non-web password paths.
Audit controlsContent revision history, Admin Audit Trail suite, Syslog outputLog retention (six years); regular log review
IntegrityRevisions and audit trail detect improper changes.Mechanism to authenticate ePHI (addressable)
Transmission securitySecurity Kit security headersEnforce HTTPS/TLS on all ePHI traffic.

How Does Varbase Handle Access Control and User Roles?

Varbase enforces access control through Drupal's per-user accounts and a pre-defined role hierarchy from the Varbase Users Base recipe. Roles ship distinct: Super Admin, Site Admin, SEO Admin, Content Admin, Content Editor, plus Drupal's Authenticated and Anonymous roles.

Access applies to all content and, with configuration, can be limited down to specific fields or sections by role and other factors. That maps to HIPAA's access-control standard and its required unique user identification specification: every user has their own account, so no shared login can blur who did what.

What Does Varbase Give You for Login and Authentication Hardening?

Varbase hardens authentication through the Varbase Security Base recipe, which installs the Password Policy module and a set of login-protection modules. Password Policy, reported on more than 54,000 sites, enforces length, character-type, history, and username constraints, plus expiration.

Varbase Password Policy admin screen listing enforced constraints: minimum 8-character length, four required character types, no username in password, and password history, applied to the Authenticated user and Content editor roles.

 

Login protection comes from Flood control for brute-force lockout, Username Enumeration Prevention to remove the forgot-password message that confirms a valid account, and CAPTCHA, reCAPTCHA, Honeypot, and Antibot for bot and spam defense. Security Kit adds hardened security headers.

Multi-factor authentication is the notable gap. Drupal supports MFA through a contributed two-factor module, but it isn't part of the Security Base recipe's default set, so a HIPAA build adds and configures it.

One honest limitation to design around: the Password Policy applies only to passwords set through the web interface. Passwords changed through Drush or web services can bypass the constraints, so lock down those paths on a build that handles ePHI.

How Does a Varbase Build Cover Audit Logging?

Varbase covers audit logging through two layers: content revision history and the Admin Audit Trail suite from the Varbase Admin Base recipe. Revisions record who changed a piece of content, when, and what they edited.

Admin Audit Trail extends that to create, update, and delete events across nodes, media, files, users, taxonomy, and menus, plus a dedicated log of authentication events, including logins, logouts, and password requests. Drupal core's Syslog can forward all of it to your system log or a SIEM.

 

Varbase Admin Audit Trail report showing a table of timestamped administrative actions with type, operation, path, description, user, IP address, and record ID, including an admin login event.

 

HIPAA's audit-controls standard is a required safeguard, and it expects retained, reviewable logs, generally for six years. Varbase generates the events. Your team owns retention, review cadence, and monitoring.

Why Start a Healthcare Build on Varbase Rather Than Vanilla Drupal?

On Varbase, the application-layer security HIPAA cares about is installed and configured on day one, not assembled module by module. The Security Base recipe brings more than a dozen security modules as one hardened set: Password Policy and its constraint modules, Flood control, Username Enumeration Prevention, CAPTCHA, reCAPTCHA, Honeypot, Antibot, and Security Kit. The Users Base and Admin Base recipes add the role hierarchy and the Admin Audit Trail suite.

On vanilla Drupal, a team selects, installs, configures, and tests each of those pieces itself, then repeats the exercise for roles and audit logging. Varbase ships all three as tested recipes, so the baseline that maps to HIPAA's access-control, authentication, and audit-control standards is present from the first deploy. 

That is the head start the security recipe is built to give: a hardened baseline with minimal configuration instead of weeks of security scaffolding.

The advantage carries past launch. Drupal issues security releases on its own schedule, and a patch sometimes lands while another fix is already in flight. Vardot maintains varbase-patches, a curated Composer patch set that tracks which Drupal core and contrib patches still apply as core moves, so keeping a regulated site current isn't a manual, per-patch investigation for your team. 

On a HIPAA build, that removes a recurring way for a known vulnerability to sit unpatched while someone works out whether last month's patch is still needed.

What About Encryption and Hosting, the Parts Varbase Doesn't Do?

Is Encryption Required for a HIPAA Drupal Build?

Under today's rule, encryption of ePHI at rest and in transit is an addressable specification: you implement it or document an equivalent, risk-based control. 

Vardot's builds keep the database isolated so it isn't reachable from outside the server, which reduces exposure. That isolation is a real control, but "addressable" has never meant optional, and treating it that way is a common finding in enforcement.

That flexibility is closing. The HIPAA Security Rule update proposed in January 2025 would remove the addressable/required distinction, making encryption at rest and in transit, and MFA, mandatory. It's still a proposed rule as of mid-2026, but the direction is set, so build to it now.

What Hosting Is HIPAA-Compliant for a Drupal Site?

Hosting is a hard requirement, not a preference. Any provider that stores or transmits ePHI is a business associate and must sign a BAA; many mainstream hosts won't. Choose HIPAA-eligible managed hosting and get the BAA in writing before any PHI touches the environment.

Vardot deploys sensitive builds to hosts that offer this. Acquia, for one, runs a HIPAA environment that logically separates HIPAA customers and will sign a BAA. 

Worth noting how Acquia frames it: the platform is "HIPAA-ready," meaning it lets you meet your obligations, and the customer stays responsible for Drupal patching, password configuration, and MFA. That is the three-layer split, stated by the host itself.


Where Do Healthcare Drupal Builds Actually Fail?

Where we land: what sinks a healthcare Drupal build is rarely whether the platform can do it. The recipe gives you a hardened baseline in minutes, and that speed is the trap.

 Teams treat the defaults as the finish line, when a baseline is a starting point, not a compliant system, and the gap between 'modules installed' and 'safeguards operating and evidenced' is where audits find failures.

The second failure is ownership. Half of what HIPAA asks for lives outside the CMS entirely, in the hosting BAA and in the covered entity's own policies. 

A team that assumes the platform covers all of it, or that hosting covers all of it, ends up with a gap in the middle that nobody scoped. In the regulated public-sector and healthcare buildings we see, that middle column is where the real work sits.

Where Does a Healthcare Build Go From Here?

As a Drupal Diamond Certified Partner with 200+ platforms delivered and one of the world's top 20 contributors to Drupal core, Vardot builds HIPAA-ready Varbase platforms for healthcare and other regulated organizations. 

Starting on Varbase gives you the hardened baseline; our security and compliance audit maps every HIPAA safeguard to platform, configuration, or hosting, so no control sits unowned before your first form goes live.

Healthcare HIPPA