A guide to hospital website hosting: which pages fall under HIPAA, and what the host should cover
HIPAA Compliant Hosting · https://hipaacomplianthosting.com/blog/hospital-website-hosting
Last updated: November 11, 2026
A hospital's public website is not all under HIPAA. As of November 11, 2026, the pages and systems that create, receive, maintain or transmit protected health information (PHI) are. The host of those parts is a business associate, so hospital website hosting for them needs a business associate agreement (BAA).
This guide to hospital website hosting is for the web or marketing lead who runs the site. It also serves the IT or compliance reviewer who approves the host, and the agency that maintains the site. It maps where PHI enters, what a host should cover and what stays with your team. We sell managed hosting, so weigh this as a disclosure.
TL;DR: Quick answer
Not every page. HHS's Office for Civil Rights (OCR) gives this example: a visit to a hospital's job postings or visiting hours page discloses no PHI.
Firm ground. OCR's guidance says appointment forms, symptom checkers, portal login pages and logged-in pages can involve PHI.
Narrowed ground. A June 20, 2024 court order vacated one part of OCR's tracking bulletin: an IP address linked to a visit to certain public pages.
The BAA. HHS says storing electronic PHI (ePHI) with a cloud provider that has not signed a BAA violates the HIPAA Rules. A signed BAA is the first test for hospital website hosting.
The split. A host covers its servers. Your CMS, plugins, forms and tags usually stay with you and your agency. Put that split in writing before you sign for hospital website hosting.
Which pages of a hospital website fall under HIPAA?
The pages that fall under HIPAA are the ones where the site creates, receives, maintains or transmits PHI. HHS says a name or phone number alone is not necessarily PHI. Tied to a health condition, care or payment for care, it is. OCR says identifiable health information collected on a covered entity's website generally is PHI, even from someone who is not a patient.
Our guide to a HIPAA compliant website explains the general rule. The page map below shows where PHI usually enters a typical hospital site. Copy it, note where each feature runs and mark each row before you compare hospital website hosting quotes.
Page or feature | Usually touches PHI? | Why | What to check |
|---|---|---|---|
Appointment and referral request forms | Yes | A contact detail tied to a request for care. OCR's example is an appointment page that collects an email address or a reason for care. | Storage, the notification email and the form vendor. |
Contact forms that invite health details | Often | HHS says a name alone is not necessarily PHI. A health detail added to it is. | Free-text boxes, reason menus and class or support group sign-ups. |
Patient portal link and login page | Link: no. Login page: yes | OCR says sign-in details collected by a tracking tool on a portal login page are a disclosure of PHI. | Whose server shows the login page, and which tags load on it. |
Bill pay | Yes | HHS lists a hospital bill as an example of PHI. Payment for care is part of the PHI definition. | Whether the page runs on your server or a billing vendor's. |
Find a doctor and condition pages | Not by a visit alone | A 2024 court order vacated OCR's guidance on an IP address plus a visit to such pages. | Any request form on the page. |
Careers, locations and visiting hours | No | OCR's own example: a visit to a job postings or visiting hours page discloses no PHI. OCR lists location pages beside them as general information. | Forms that ask for health details. |
Donations | Usually no | Our reading: a gift alone says nothing about care. Patient data used for fundraising under 45 CFR 164.514(f) is still PHI. | Whether the donor system draws on patient records. |
Symptom checkers and chat | Often | OCR says a symptom checker page may give tracking tools access to PHI. It does not name chat. Our reading: the same test applies. | The vendor, its BAA and where transcripts are kept. |
Site search | It depends | Not named by HHS. Our reading: a health term stored with an identifier meets the test. | Whether queries are logged with an identifier. |
Price transparency files | No | 45 CFR 180.50 lists charges and payer rates for the file, not patient records. | That the file stays public and open to automated searches and direct downloads. |
Analytics and tracking tags | Depends on the page | Our reading: a tag takes on the status of its page. | Which tags load on forms, login pages and the portal. |
Column two is our reading of each row's sources. Lines marked "our reading" are ours, not HHS statements. For the checks themselves, use our HIPAA compliance checklist for websites. The rows you mark yes, often or it depends decide what hospital website hosting must cover.
Do analytics and tracking tags put a public hospital page under HIPAA?
It depends on the page, and a court vacated one part of OCR's answer. OCR says tracking tools on many public pages have no access to PHI, and HIPAA does not regulate that use. On logged-in pages, such as a patient portal, it says tracking tools generally have access to PHI.
OCR issued its tracking bulletin in December 2022 and revised it on March 18, 2024. On June 20, 2024, a federal court in the Northern District of Texas declared one part unlawful and vacated it. The vacated part said HIPAA duties arise when a tool links an IP address to a visit to certain public pages. Those are pages about specific health conditions or healthcare providers. The order says the rest of the bulletin is not limited by the ruling. HHS's appeal was dismissed on September 4, 2024, on HHS's own motion.
As of November 11, 2026, the bulletin is still posted. HHS's page still says HHS is evaluating its next steps. So treat forms, sign-in pages and portals as the firm ground.
Our guide to HIPAA tracking technologies covers what each tag may collect. Our record of healthcare pixel lawsuits covers the court cases. For hospital website hosting, the point is narrower: your team or agency usually adds the tags, not the host.
Does hospital website hosting need a BAA?
Yes, for every part of the site that stores or sends PHI. Under 45 CFR 160.103, a business associate creates, receives, maintains or transmits PHI on a covered entity's behalf. HHS says a cloud provider that stores ePHI for a covered entity is a business associate.
45 CFR 164.308(b) makes the written contract a required item. What it must say is in our guide to the business associate agreement.
So hospital website hosting that carries forms, login pages or stored submissions needs a BAA. That BAA covers the host's own services. Each other vendor that receives PHI, an agency included, needs its own BAA.
A BAA is where hospital website hosting starts, not where the hospital's duties end.
What should the host cover, and what stays with the hospital and its agency?
The host should cover the server layer under a BAA. The hospital and its agency keep the CMS, the forms, the tags and their own risk analysis. HHS's cloud guidance says the provider and the customer should confirm in writing how each will address the Security Rule. The table is a starting split for a hospital website hosting contract.
Under 45 CFR 164.306(d), items marked required in the table must be implemented. Addressable items must be assessed, then implemented or, with the reason documented, replaced by an equivalent measure where reasonable.
Layer | What a host should cover | What stays with the hospital and its agency | Security Rule citation |
|---|---|---|---|
The BAA | A signed BAA for the servers and services it runs. | A BAA with every other vendor that receives PHI. | 45 CFR 164.308(b), required. |
Server, operating system and PHP | Applying updates, or a written statement of who does. | Testing the site after server and PHP updates. | No named patching item. OCR places it under risk analysis and risk management, 164.308(a)(1), required. |
CMS core, modules, plugins and themes | Usually nothing, unless the contract says so. | Applying updates, testing them and removing unused code. | No named patching item. Risk analysis and risk management, 164.308(a)(1), required. |
Encryption | Encrypted server storage, and TLS for traffic to the site. | Keeping PHI out of plain email alerts and exports. | 164.312(a)(2)(iv) and 164.312(e)(2)(ii), addressable. |
Access | Controlling who can reach the server and its admin tools. | A unique login for each CMS user, removed when the person leaves. | 164.312(a)(2)(i), required, for unique user IDs. |
Audit logs | Records of activity on the server. | Records of CMS logins and form access, and a regular review. | 164.312(b). It names no retention period. |
Backups and restore | Server backups and restore tests. | Knowing what the backups hold, and the site's recovery plan. | 164.308(a)(7), required. Testing is addressable. |
Risk analysis | Its own, for the ePHI it holds. | Its own, covering the website, its forms and its tags. | 164.308(a)(1)(ii)(A), required. |
HHS adds that a provider is not responsible for compliance failures caused solely by the customer, depending on the facts of the case. So a hospital website hosting contract should name each layer.
Who patches Drupal or WordPress: the host, the hospital or the agency?
Usually the hospital or its agency patches the CMS, and the host patches the server. WordPress's own hardening guide says hosts are often responsible for the infrastructure, not for the application you install.
WordPress's update guide says most sites can apply minor and security updates in the background. WordPress's plugin guidelines put security on the plugin developer. Drupal's Security Team says it issues security advisories and tells users the steps they must take to protect themselves. Our reading: taking those steps falls to whoever maintains the site.
So name who patches each layer, in the hospital website hosting contract and in the agency's contract. Our Drupal guide lists which Drupal hosts sign a BAA.
What should you bring to a hospital website hosting quote?
Bring a one-page inventory of the site: what runs it, where PHI enters and who maintains it. The table works for any hospital website hosting quote, whoever the host is. Copy it, and leave passwords and patient data out.
Item | What to write down |
|---|---|
Sites and domains | Every public site, microsite and subdomain, and which ones share one codebase. |
CMS and versions | Drupal or WordPress, its version and the PHP version it needs. |
Modules, plugins and themes | Attach the full list, with custom code marked. |
Forms | Each form, what it asks, where submissions are stored and who gets the email. |
PHI rows from your page map | Every row you marked yes, often or it depends. |
Other vendors | Your agency and the portal, bill pay, chat, search and scheduling vendors, and whether each has signed a BAA. |
Tags | Every analytics and advertising tag, and the pages it loads on. |
Traffic and storage | Monthly visits, busiest days, database size and file storage. |
People and access | Who patches the CMS today, and who needs access. |
Availability and recovery | How long the site can be down, and whether you need more than one zone. |
What do our standard plans cover, and where do they stop?
Our plans run on single-tenant AWS. Each plan is one server in one AWS availability zone. We sell this, so weigh it as a disclosure.
Our team applies OS and PHP updates. Your application code, your CMS (WordPress core included), plugins, themes, modules and extensions, and their updates, stay with you and your agency. We tell you when something you run has a known vulnerability. Supported platforms include WordPress and Drupal.
We sign the BAA within 24 hours of signup, before patient data moves. Our BAA covers the servers and services we run. Email, SMS, EHR, form and AI model vendors need their own BAA. Root access comes only with an Enterprise engagement.
Every plan includes CloudFront CDN, a web application firewall (WAF) and EBS storage with 7-day snapshot retention. It also includes encryption at rest and in transit, six-year audit logging and tested encrypted backups.
Managed plans from $229 a month. The Performance tier starts at $259 a month, for platforms including Drupal, Strapi, Docker and Phalcon.
When do you not need us?
In three cases you may not need us, or not a standard plan.
Your public site is a brochure with no forms, and every PHI function runs on your EHR vendor's portal. If the site truly holds no PHI, its host is not a business associate, and hospital website hosting for it needs no BAA.
Your site must run in more than one zone. Standard plans are one server in one AWS availability zone, and a multi-zone design is quoted separately. Failover is available as an add-on, quoted separately. Our guide to HIPAA compliant infrastructure covers those decisions.
Your policy keeps PHI workloads in a cloud account your own team runs.
In the first and third cases, another kind of host may fit better. If one managed server fits your site, send your site inventory with a quote request.
Frequently asked questions
What is required for a hospital website to stay HIPAA compliant?
The parts that handle PHI need a BAA with each vendor, Privacy Rule disclosure limits, Security Rule safeguards and a risk analysis of the site. No single list exists for websites. HHS's Office for Civil Rights says it does not endorse, certify or recommend specific technology or products. So HHS approves no hospital website hosting plan.
Does hospital website hosting need a BAA if the public site has no forms?
Not if the site truly holds no PHI. A host is a business associate only when it creates, receives, maintains or transmits PHI for the hospital. One form that invites health details changes the answer.
Does a patient portal sign-in link put the public site under HIPAA?
No, a link alone does not. The login page is different. OCR says sign-in details collected by a tracking tool on a portal login page are a disclosure of PHI. Check whose server shows that page.
Are hospital price transparency files PHI?
No. Under 45 CFR 180.50 the file lists charges and payer rates, not patient records. The rule says it must be free, open without an account and reachable by automated searches and direct downloads. So hospital website hosting should keep that file public.
Recap: hospital website hosting
A hospital's public site is not all under HIPAA. Map the pages that handle PHI, and get a BAA with the host of those parts. Put the split of duties in writing, layer by layer. Bring a site inventory to every hospital website hosting quote. Your CMS, forms, tags and risk analysis stay with you.
This guide is general information, not legal advice. The rules and HHS pages are as read on November 11, 2026, and they can change. Whether hospital website hosting meets the HIPAA Rules for your site depends on your own setup, contracts and risk analysis. Confirm with qualified counsel. We sell HIPAA compliant hosting. Reviewed November 2026.
Sources
HHS: Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates (last reviewed June 26, 2024).
U.S. District Court, N.D. Tex.: American Hospital Association v. Becerra, Opinion and Order (June 20, 2024).
U.S. Court of Appeals, Fifth Circuit: docket No. 24-10775 on CourtListener (appeal dismissed September 4, 2024).
HHS: Guidance on HIPAA and Cloud Computing (last reviewed December 23, 2022).
HHS: Guidance on de-identification of protected health information (last reviewed February 3, 2025).
HHS: January 2026 OCR Cybersecurity Newsletter (last reviewed January 8, 2026).
Cornell LII: 45 CFR 160.103, 164.306 and 164.308.
Cornell LII: 45 CFR 164.312, 164.514 and 180.50.
WordPress: Hardening WordPress (last updated October 14, 2026), Updating WordPress (last updated November 7, 2026) and Detailed Plugin Guidelines.
Drupal: Security Team general information (last updated May 29, 2025).