Which HIPAA requirements Drupal helps with for patient forms and data
Drupal helps with some HIPAA Security Rule requirements for patient forms and data, but it does not make a site HIPAA compliant on its own. The Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information they create, receive, maintain or transmit (45 CFR 164.302). A Drupal site that collects intake forms, stores submissions or publishes care content with PHI is therefore inside that scope, and the organization owns the compliance outcome. Drupal is open-source software licensed under GPL-2.0-or-later with no paid edition, so the license does not carry any HIPAA obligation of its own, and a vendor cannot sell a HIPAA label for the platform.
Most of the work sits in controls the team configures and operates: unique user identification and role-based access for staff who open submissions, automatic logoff, audit logging of who viewed or exported a record, encryption of data at rest and in transit, and the decision about which PHI should never be stored in Drupal at all. Several of these are addressable implementation specifications under 45 CFR 164.312, which means the organization must assess whether each is reasonable, document the decision, and implement an equivalent measure where needed. Some items, such as the business associate contract under 45 CFR 164.314 and the hosting provider's own safeguards, sit outside the Drupal codebase and need to be confirmed in writing with your legal and hosting counterparts.
There is no HIPAA certification. HHS states that no Security Rule standard requires certification and that HHS does not recognize private certifications, which do not prevent a later finding of violation. DeployOpen prepares the system, its configuration and the evidence an assessor will ask for, including risk analysis inputs, access reviews and logging records, but it does not issue audit reports, attestations or certifications. Independent assessors and your compliance function make those determinations. Before scoping the work, confirm which PHI flows reach the site, which standards your organization has already documented, and whether the 2025 proposed revision to the Security Rule, which has not been finalized, will change your planned controls.
Mapping Security Rule technical safeguards in 45 CFR 164.312 to Drupal configuration
This table maps each technical safeguard standard and implementation specification in 45 CFR 164.312 to the Drupal configuration that supports it and the records an assessor may ask for. Specifications marked Required must be implemented, while Addressable ones need a documented assessment and an equivalent measure where reasonable. No Drupal module certifies HIPAA compliance, so treat each row as configuration that supports a safeguard, not as proof of it.
| Standard or specification | Drupal configuration | Evidence to keep | Status |
|---|---|---|---|
| Unique user identification, 164.312(a)(2)(i) | Individual accounts for every staff member, no shared logins, roles limited to need-to-know by content type and Webform | User export, role configuration export, SSO account mapping | Required |
| Emergency access procedure, 164.312(a)(2)(ii) | A documented break-glass administrator path that works when the identity provider is down; confirm how recovery accounts are stored and reviewed | Written procedure, sealed recovery credential log, test record | Required |
| Automatic logoff, 164.312(a)(2)(iii) | Session lifetime and idle timeout settings for signed-in users; confirm which setting or module enforces idle logoff | Configuration export, timeout test results | Addressable |
| Encryption and decryption, 164.312(a)(2)(iv) | Encrypt sensitive Webform data with Key and an encryption module; database and backup encryption at the hosting layer | Key management record, encryption configuration, host storage encryption confirmation | Addressable |
| Audit controls, 164.312(b) | Core Database Logging or Syslog records account and form events; keep PHI out of log messages and set retention | Log samples, retention settings, periodic review records | Standard, no specification |
| Integrity of ePHI, 164.312(c) | Webform revision history and restricted edit and delete permissions; a mechanism to detect alteration needs confirmation | Permission matrix, submission change logs | Addressable (164.312(c)(2)) |
| Person or entity authentication, 164.312(d) | Multi-factor sign-in through a SAML or OIDC identity provider; confirm MFA enforcement at the provider | Identity provider MFA policy, service provider configuration, sign-in logs | Standard, no specification |
| Transmission security, 164.312(e) | TLS on all Drupal endpoints, form email and API traffic, with integrity controls and encryption for transmitted PHI | TLS scan results, certificate inventory, mail transport configuration | Addressable (both specifications) |
Evidence auditors and OCR investigators will ask for from a Drupal site
A HIPAA review of a Drupal site looks at what the platform team can show, not what it intends to do. The cards below cover the records that connect access, change, incident response and risk decisions, so the team can answer questions with dated, retrievable evidence. Each record supports a review; none of them is a certification or an audit result.
Role and access configuration exports
Export roles, permissions and user-to-role assignments from configuration on a schedule and keep each export under version control. Changes to who can view webform submissions or patient-linked content should appear as reviewable diffs with a named approver. Compare the export against the care team's documented need to know, because an access model that ignores role boundaries is the kind of gap a regulator will test first. Confirm that exports cover submission-view and export permissions specifically, not only content editing.
SSO login records from the identity provider
Keep sign-in and failed-sign-in records from the identity provider that fronts the Drupal site, such as the SAML or OpenID Connect provider, rather than relying only on Drupal's own user log. Identity provider records show multi-factor use, session lifetime and which accounts were disabled, which the Drupal site may not record. Confirm how account provisioning and deprovisioning reach Drupal, since accounts created on first sign-in must still be removed or reduced when staff leave the care team.
Drupal and web server logs
Retain Drupal's watchdog or syslog output for submission views, exports, role changes and failed logins, alongside web server access logs for the forms and submission paths. Logs are only useful if they are protected from editing, sent to a central store and retained for a period your counsel sets. Confirm which Webform and access events your installed modules actually write to the log, and test that a submission view appears in the log before you rely on it.
Security advisory response records
Record when each Drupal core or contributed security advisory affecting your site was reviewed, and when the update was applied in staging and production. Core security releases follow a fixed Wednesday window, and the Drupal Security Team publishes advisories with CVE identifiers, so you can tie each change to a published item. Keep the decision record for any advisory you deferred, including the compensating control. Dates from your ticketing system and deployment logs should agree with each other.
Risk analysis and addressable decisions
Document the risk analysis for ePHI on the site, with each addressable implementation specification under 45 CFR 164.306(d) marked as implemented, not applicable, or replaced by an equivalent measure, and the reason for each decision. Encryption of stored submissions and automatic logoff are common examples where the reasoning matters more than the setting. Keep the analysis dated and tied to the current architecture, and revisit it after major changes such as a Drupal upgrade or a new integration.
Signed business associate contracts
Keep the signed business associate agreement for each vendor that creates, receives, maintains or transmits ePHI for the site, including the hosting provider, the form or email services and any implementation partner with access to production data. Under 45 CFR 164.314(a), the contract must require compliance with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and require reporting of security incidents. Check that each subcontractor chain is documented, because a missing downstream agreement is a common gap in a review.
Where PHI should live when Webform collects it
The first decision for any Drupal form that may collect protected health information is whether the submission should be stored in Drupal at all. A Webform submission is a row in the site's database, so the Drupal site becomes a system that creates, receives and maintains electronic protected health information, and the Security Rule applies to it in full. The alternative is to route PHI to a system built for it, such as a HIPAA-eligible EHR or patient platform, and keep the Drupal site as a front door that stores as little as possible. If the second route is chosen, the vendor must sign a business associate contract that meets 45 CFR 164.314(a)(2)(i), which requires the vendor to comply with the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents. Confirm with each vendor whether it will sign that contract, which hosting regions and subprocessors it uses, and whether its platform is HIPAA-eligible for the specific service you plan to use, since eligibility is a vendor statement to verify and not a certification.
Where Drupal does store submissions, the database and the file system are both in scope. Plan encryption at rest for the database volumes, backups and any uploaded files that Webform saves to the public or private file system, and confirm the encryption specification you choose against the addressable items in 45 CFR 164.312. Set a submission retention period in the Webform settings and in a scheduled purge, and decide who may export submissions and how deletion is evidenced. Export files, CSVs and downloads are copies of PHI and need the same controls as the database.
Keep PHI out of places it tends to leak: notification emails that quote field values, debug and watchdog logs, error pages, and contributed modules that touch submission data without a business associate arrangement with the vendor who maintains them. Review every Webform handler, mail template and logging setting before go-live, and confirm that any third-party module or SaaS integration that receives field data is covered by a contract with the same terms. These checks belong in the design phase because they are cheaper to build in than to remove after launch.
Configuration sequence for a HIPAA-scoped Drupal site
The sequence turns a Drupal site that will handle electronic protected health information into a documented configuration, with each decision traced to a Security Rule standard. It is a planning order for building and evidencing safeguards, not a certification path, because HIPAA has no certification.
Scope which forms and content carry ePHI
Start by listing every Webform, content type, file upload, email notification and integration that will create, receive, store or transmit electronic protected health information. The product owner and the privacy lead confirm the list with a field-level inventory, marking each item as ePHI, possibly ePHI or non-PHI. Done means the inventory is signed off and every later step refers back to it, so no patient data path is left unexamined.
Run the documented risk analysis
Use the inventory to run the risk analysis that the Security Rule requires, mapping threats and vulnerabilities to each ePHI path, hosting component and user group. NIST SP 800-66 Rev. 2 (February 2024) offers sample questions for each standard and is a useful checklist, though HHS treats it as informational. Done means a dated risk register exists with owners and accepted or planned treatments for each finding.
Connect the identity provider with unique user IDs and MFA
Route Drupal sign-in through your corporate identity provider using the contributed SAML Authentication module (samlauth) or the OpenID Connect module, so each person has a unique identifier and multi-factor authentication is enforced at the identity provider. Confirm that the module version supports your Drupal release, and that accounts created on first sign-in are reviewed against your joiner rules. Done means test users can sign in only through the approved provider and no shared accounts remain.
Define roles and least-privilege access
Build Drupal roles around the care or business functions that need each form and record, and restrict view, edit and export permissions per content type and per Webform. Remove default permissions that grant broad access to submissions, and document who may approve role changes. Done means a role matrix is exported with the configuration, and a test account for each role confirms it sees only the data its function requires.
Configure Webform storage and routing
Decide which submissions are stored in Drupal at all, and for those that are, how they are encrypted at rest and in transit, and which fields are routed to systems built for patient data instead. Apply the same rules to notification emails so PHI does not travel through unprotected channels. Confirm encryption behavior with the Webform version and your database and storage vendors, since this is configuration you must verify rather than assume. Done means a routing diagram matches the live configuration and a test submission is traced end to end.
Set automatic logoff and session limits
Configure session lifetime and idle timeout at the Drupal and identity provider layers so that inactive sessions end automatically, which addresses the addressable automatic logoff specification. Record the chosen values and the reason for them in the risk analysis. Done means a timed test confirms that an idle session ends and the user must sign in again.
Enable audit logging and set log retention
Turn on logging for sign-ins, failed attempts, permission changes, configuration changes and access to submissions, then forward logs to a store that the site team cannot silently alter. Set a retention period that your legal and compliance owners approve, since the period is a policy decision and not a fixed rule in the researched facts. Done means a test access event appears in the central log with the user, time and record reference.
Confirm hosting, backups and BAA coverage
Confirm in writing that each hosting, backup, email and monitoring provider that touches ePHI will sign a business associate agreement under 45 CFR 164.314(a), and that the agreement flows the same obligations to their subcontractors. Verify that backups are encrypted and that restore tests have been run. Done means a register lists each provider, its signed BAA status and the location of stored backups.
Document addressable decisions and keep the evidence
For each addressable implementation specification, record whether it is reasonable and appropriate in your environment, and if not, document the reason and the equivalent alternative measure, as 45 CFR 164.306(d) requires. Store the configuration export, role matrix, test results and BAA register together so the evidence stays current with each release. Done means every addressable decision has a written rationale and an owner, ready for review by your privacy officer, an independent assessor or OCR if asked.
What Drupal and its modules do not cover for HIPAA
Drupal and its contributed modules can enforce some technical safeguards on a site, but a large share of the Security Rule sits with the covered entity or business associate. The cards below name the work that stays with your organization, your hosting provider and your compliance function, even when the Drupal build is correct.
Administrative safeguards under 164.308
Risk analysis, risk management, sanction policies, workforce security, information access management and contingency planning are organizational duties under 45 CFR 164.308. A module can record who submitted or viewed a form, but it cannot decide who in your workforce should hold a role, or run the periodic risk analysis that justifies your configuration. Confirm who owns each of these standards before the build starts.
Physical safeguards under 164.310
Facility access controls, workstation use and workstation security under 45 CFR 164.310 apply to the places and devices where patient data is viewed or stored. Drupal has no control over badge readers, locked server rooms, or the laptops of staff editing forms. Your data center or cloud provider may cover parts of this, but you must confirm which controls they inherit and which remain yours.
Policies, training and documentation
Standards in 164.314 and 164.316 require written policies, documentation of decisions, and retention of that documentation. Webform configuration exports and Drupal update logs are useful evidence, but they are not policies. Security awareness training for editors, developers and help desk staff also remains an organizational obligation that no module delivers.
Business associate contracts
A business associate contract under 45 CFR 164.314(a)(2)(i) must bind every party that touches ePHI, including the agency that hosts your Drupal site and any contributed-module vendor with access to data. Confirm that the contract requires security incident reporting, flows terms to subcontractors and covers the hosting environment. A Drupal project cannot sign this on your behalf.
Hosting provider controls
The provider running your database, web servers, backups and object storage operates controls that Drupal cannot replace, including host-level logging, disk encryption keys and network isolation. Ask each provider which safeguards it supports, what it will sign under a BAA, and which logs it retains. Gaps here affect every Drupal control built above them.
No certification and a pending rule
HHS states that no Security Rule standard requires certification, and it does not recognize private certifications, so a vendor badge does not establish HIPAA compliance. The proposed Security Rule revision published at 90 FR 898 had no final rule as of October 2026, and its requirements may change. Re-check the Federal Register and the module behavior after any final rule is published.
Confirming module behavior on your site
Webform, encryption, SSO and logging modules behave differently across versions and configurations, and a setting that is safe on one site may be unsafe on another. Test each claimed control against your Drupal version, PHP version and installed modules, and record the results. Re-test after every core or contributed update, since security releases can change defaults.
Questions buyers ask before hiring help on Drupal and HIPAA
What drives the cost of a Drupal HIPAA project?
The main cost drivers are how many forms collect PHI, how many systems receive that data, how identity and access are set up, and where the site is hosted. A project with one intake form that stores nothing beyond the form submission costs far less to scope than a patient portal with several forms, a CRM sync and a separate clinical system. Quotes are built from a written scope, so ask the vendor to list each PHI form, each integration, each identity provider and each hosting component as a separate line. Expect one-time costs for design, build, configuration and testing, and recurring costs for hosting, patching, backups, log retention and access reviews. Ask which of these are included and which are billed separately.
How long does it take to scope and configure a PHI-handling Drupal site?
Scoping usually takes longer than configuration because the team has to settle which data is PHI, where it is created, where it is stored and who needs to see it. Scoping work includes mapping each form and field, deciding what leaves the Drupal site, and agreeing on access roles and logging. Configuration then depends on the number of forms, integrations and identity setups. Ask for a written timeline that separates scoping, build, testing and the handover of operating procedures, and confirm which dates depend on the covered entity's own reviews and sign-offs.
What does the covered entity need to provide for the work?
The covered entity needs to supply the inputs that only it can provide: its risk analysis results or the data needed to produce them, named owners for privacy and security policies, and a compliance lead who can make decisions on behalf of the organization. Without these, the technical work cannot be checked against the organization's own risk decisions. The Security Rule expects an entity to assess addressable implementation specifications and document its reasoning, so the covered entity must be able to say which alternatives it accepted. Ask the partner to name exactly which decisions and documents it needs from your side and when.
Can our in-house team build a HIPAA-ready Drupal site without a partner?
Yes, an experienced in-house team can build this, but the work spans more areas than Drupal development alone. The team needs skills in Drupal form handling, encryption and key management, identity federation, logging, network design and hosting under a business associate agreement. It also needs time to document decisions against the Security Rule and to test access controls. Assess your team against each area, identify gaps and decide whether to train, hire or buy specific pieces such as a security review. A partner can cover a defined part of this, which makes the split of responsibilities the first thing to agree in writing.
Is there a HIPAA certification, and does DeployOpen issue one?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not stop HHS from later finding a violation. DeployOpen does not issue audit reports, attestations or certifications. It can plan and configure controls, prepare evidence and support your own assessment, but independent auditors and certification bodies provide any third-party assessment you choose to obtain. Ask any vendor who offers a HIPAA certificate to explain exactly what was assessed, by whom and against which criteria.
What happens to the business associate agreement chain when a contributed module is involved?
A contributed module does not sign a business associate agreement, so the agreement sits with the parties that handle PHI: your organization, the hosting provider, any integration vendor and, where applicable, DeployOpen. Under 45 CFR 164.314, a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI and report security incidents. Module code is part of your system, so you must decide who maintains it, who receives security advisories and how patches are applied within your incident process. Ask each party to confirm in writing which PHI flows it touches and which subcontractors it uses.
What is the financial risk of getting PHI handling wrong?
The exposure is real, and it grows with the number of violations and how long they persist. For penalties assessed on or after January 28, 2026, the inflation-adjusted HIPAA civil money penalty ranges from $145 per violation to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3, 91 FR 3666). Enforcement also includes complaint investigations and audits by the HHS Office for Civil Rights. Treat the penalty figure as a reason to document decisions and test controls, not as a budget estimate, and have counsel confirm how it applies to your organization.
Do we need to wait for the proposed Security Rule update before we start?
No. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898), but as of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. The current rule in 45 CFR Part 164 Subpart C still applies. Designing your Drupal site against the current standards and documenting decisions now makes later changes easier to assess. Confirm the status of the proposed rule with counsel before each major milestone, because the Unified Agenda dates can move.
Keeping a HIPAA-scoped Drupal site current
Patch timeliness is a Security Rule concern, not only a web team habit. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule. For a site that stores or routes ePHI, the practical question is how quickly your team can take a security release through staging, regression testing and production on that Wednesday, and who is accountable when it cannot. Write that window into your risk analysis and your change process, and confirm the response time your own governance requires. Contributed modules, including the Webform and any integration modules that touch patient data, follow their own advisory cycle through the Drupal Security Team, so the inventory of installed projects matters as much as core. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. A HIPAA-scoped site still on Drupal 10 after that date will no longer receive security coverage from the community, so the upgrade needs a funded plan well before the deadline. Drupal 12 also raises the PHP floor to 8.5 or later, while Drupal 11 requires PHP 8.3 or later. Those version floors often force changes to the operating system, the web server image and the managed database, which means hosting work, not just a core update. Confirm with your hosting provider which PHP versions and database engines they support before you choose a target version. Sites still on Drupal 7 face the sharpest problem. Drupal 7 security support ended on January 5, 2025, and Drupal 7 sites cannot be updated in place to Drupal 10 or later; they must be migrated into a new site and their themes rebuilt. If migration cannot finish quickly, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors, as described on the Drupal 7 end of life page. Treat that as a bridge with its own contract, scope and exit date, and record the arrangement as a documented risk decision under the addressable and required specifications you have chosen to address.
How DeployOpen works on this
DeployOpen plans and builds Drupal sites inside the client's own infrastructure, so protected health information stays under the covered entity's or business associate's control. We start from a written scope that maps each form, data field and integration to the Security Rule safeguards it touches, then build, test, document and hand over the result.
How we scope
- Inventory every Webform, field and integration that could capture or transmit electronic protected health information.
- Confirm with your compliance lead which systems are covered entities or business associates and which contracts apply.
- Agree in writing which forms stay on Drupal, which route to a system built for PHI, and who owns each decision.
How we build
- Configure Webform storage, encryption at rest and role-based access for PHI-bearing forms, with settings recorded in configuration export.
- Build routing to the external system your organization chooses for clinical data, with tested transport security and error handling.
- Test access control, audit logging and session timeout behavior against the scope before any patient data enters the site.
How we hand over
- Deliver a written record of the configuration, data flows, roles and logging settings that your risk analysis can reference.
- Document the hosting boundary, backup and restore steps, and the responsibilities each party keeps under the business associate contract.
- Walk your platform and security teams through operating runbooks so they can run and change the site without us.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, Drupal security update handling and periodic testing are available as a retainer.
- Ask us to confirm the current HHS rule status and any hosting provider's BAA terms before go-live, since they can change.
Sources and further reading
- 45 CFR Part 164 Subpart C, Security Standards for the Protection of Electronic Protected Health Information ↗
- Appendix A to Subpart C of Part 164, Security Standards: Matrix ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
- The Drupal Security Team ↗
- Drupal core release schedule ↗
