HIPAA-compliant website hosting: what it covers and when you need it

HIPAA-compliant website hosting is hosting arranged so that, if your website creates, receives, maintains or transmits protected health information for a covered entity, the vendor holding that information has signed the contract the HIPAA rules require and runs the safeguards that contract points to. If your site never touches protected health information, we recommend putting your effort into keeping it that way rather than shopping for a label. If it does, the label alone is not enough. You need a signed agreement, a clear map of where data goes, and someone on your side who is accountable for the forms and scripts that move it.

This guide is written for both care providers and healthcare companies. It explains what the regulation text says, where WordPress, Webflow and Framer sites usually sit, and which decisions to settle before you sign anything. It is not legal advice. Your privacy officer or counsel should make the final call on whether HIPAA applies to you and to each vendor.

What the phrase actually means

The regulation sections quoted in this guide define who is regulated and what their contracts must say. None of them defines a “HIPAA-compliant host”. Two definitions do most of the work.

A covered entity is a health plan, a health care clearinghouse, or “a health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter” (45 CFR 160.103). A business associate is a person who, on behalf of a covered entity, “creates, receives, maintains, or transmits protected health information” for a regulated function, and the same definition expressly includes a subcontractor that does those things on behalf of a business associate (45 CFR 160.103).

Apply those words to hosting. A server that stores form submissions containing protected health information maintains it. A form relay that forwards those submissions to an inbox transmits it. Either vendor may fall inside the business associate definition. A host serving only public pages about services, locations and opening hours may not, because no protected health information passes through it. That distinction is the whole question.

The underlying category is broad. Individually identifiable health information includes “demographic information collected from an individual” when it is created or received by a health care provider, relates to a person’s health, care or payment for care, and either identifies the person or could reasonably be used to identify them (45 CFR 160.103). A name and phone number on an appointment request can therefore matter more than it looks. Ask your privacy officer to rule on your specific forms rather than guessing.

When your website needs it

Does your healthcare website need HIPAA-compliant hosting? Start by tracing where information enters the site, then decide. These are the entry points we recommend checking on every page:

• Contact or appointment forms that ask for symptoms, reason for visit, insurance or date of birth, or that sit on a provider’s site where any request implies care.
• Uploads, chat or embedded intake tools, including widgets supplied by a scheduling or telehealth vendor.
• Third-party scripts that see form data, such as analytics, advertising or session-recording tags loaded on pages where forms live.
• Logins or patient portals, where a person signs in to view or send anything about their care.

Where health information enters the site determines which vendor needs an agreement. If none of these entry points exist, a standard host with sound security practice is a reasonable choice. We recommend writing that decision down, with the reasons, so the next person who adds a form knows where the boundary sits. If one or more apply, you have three options: move that function to a vendor that will sign an agreement covering it, put the whole site on hosting covered by an agreement, or remove the function.

The contrast comes down to two kinds of site:

• Brochure site with no patient data: a design and content project.
• Forms that collect health information: a design project plus a data-handling decision that needs a named owner in your organization.

What a hosting agreement covers, and what it does not

When a vendor is a business associate, the contract has required contents. Under 45 CFR 164.504(e)(2), the contract must, among other things:

• establish the permitted and required uses and disclosures of protected health information by the vendor;
• provide that the vendor will use appropriate safeguards and comply, where applicable, with subpart C of part 164 with respect to electronic protected health information;
• require the vendor to report any use or disclosure not provided for by the contract, including breaches of unsecured protected health information;
• require the vendor to ensure its subcontractors agree to the same restrictions and conditions;
• require return or destruction of the information at termination, if feasible; and
• authorize termination by the covered entity if the vendor violates a material term.

A second section adds to this. 45 CFR 164.314(a) says the contract must provide that the business associate will comply with the applicable requirements of that subpart, ensure its subcontractors agree to comply, and report security incidents it becomes aware of.

The technical safeguards are in 45 CFR 164.312, which applies to covered entities and business associates alike. It covers access control (unique user identification and an emergency access procedure are marked required; automatic logoff and encryption are marked addressable), audit controls, integrity, person or entity authentication, and transmission security, where encryption is again addressable.

What the agreement does not cover is the part teams tend to miss. A host can sign an agreement for its infrastructure and still have no say over a form plugin your team installed, an analytics tag pasted into the site header, or an export of submissions sitting in a staff member’s downloads folder. The agreement sets out the vendor’s obligations. Your configuration, your staff accounts and every other tool on the page stay with you. When you read any vendor’s agreement, check exactly which products and plans it names, and we recommend treating anything not named as outside it.

Where WordPress, Webflow and Framer fit

This guide does not state whether any particular WordPress host, Webflow or Framer will sign a business associate agreement, or on which plans. Read each vendor’s current agreement and terms yourself, and get any answer in writing before you rely on it.

What the platforms’ own documentation does show is what each is built to hold and how access is controlled:

• Webflow describes a CMS Collection as “a database where you can store content to reference throughout your site”, with templates such as blog posts, authors and team members, and notes that site managers on Enterprise plans or partners can limit which members can edit a Collection (Webflow Help Center).
• Framer’s developer documentation says plugins “can read and write to the Framer CMS” and that Managed Collections are controlled by plugins to sync data between Framer and a third party (Framer Developers). If you use a sync plugin, confirm what data it pulls in.
• WordPress has six pre-defined roles that let the site owner control what users can do. Its documentation warns that enabling the unfiltered_html capability for untrusted users “may result in their posting malicious or poorly formatted code” and advises granting only the capabilities a role needs (WordPress.org).

Our recommendation for most healthcare marketing sites on any of the three platforms is simple. Split the marketing site from sensitive intake:

1. Marketing site on WordPress, Webflow or Framer, holding public content such as services, providers, locations, education and news, with no protected health information stored in the CMS or the form layer.
2. Sensitive intake in a separate system, such as a scheduling, intake or portal vendor that has signed an agreement covering that function, linked or embedded from the marketing site.

The split lets you choose a platform for publishing needs rather than for which host will sign what, and it narrows the vendors your privacy officer has to review. The tradeoff is a handoff: patients move from your site into another tool, which can feel disjointed unless the design carries them across clearly. Embedding the vendor’s widget softens the jump, but ask your developer to confirm whether scripts on the surrounding page can read what is typed into it.

Healthcare companies that are not covered entities

A healthcare company that is not a health plan, clearinghouse or covered provider can still fall under the business associate definition if it handles protected health information on behalf of a covered entity (45 CFR 160.103).

A separate federal rule may also be relevant. The FTC’s Health Breach Notification Rule applies to vendors of personal health records, PHR related entities and third party service providers, and “does not apply to HIPAA-covered entities, or to any other entity to the extent that it engages in activities as a business associate of a HIPAA-covered entity” (16 CFR 318.1). Its definitions describe health care services or supplies as including any online service, such as a website or mobile application, that provides mechanisms to track diseases, health conditions, medications, symptoms, fitness, sleep, mental health and similar information (16 CFR 318.2). If your product does any of that, have counsel review which rule applies before deciding where the marketing site and the product data live.

For companies, the hosting question is often less about the marketing site and more about keeping product data out of it. A waitlist form asking only for an email address carries a different risk from a form inviting visitors to describe their condition. We recommend building the first and avoiding the second unless counsel has signed off.

Who owns what

Who owns what on a healthcare website is easier to settle before launch than after an incident. The split below is our recommended starting point; your signed contracts decide the actual allocation.

Party	What they should own
Your organization	Deciding whether HIPAA or another rule applies, approving every form field, signing agreements, and managing staff accounts and retention.
Hosting or platform vendor	The obligations in its signed agreement and terms, for the products and plans those documents name.
Website designer or developer	Building forms and integrations to the approved scope, keeping its own access minimal, documenting every script and data flow, and handing over admin access at launch.
Intake or scheduling vendor	Handling submitted information under its own agreement with you.

Raise one point directly. If your developer can see form submissions that contain protected health information, the business associate definition may reach them too, including as a subcontractor (45 CFR 160.103). Ask whether that access is needed at all. We recommend that developers test with dummy data and never see live submissions.

Scope tradeoffs, with hypothetical examples

These examples are hypothetical and simplified. They show how the decision plays out and do not describe real organizations.

Hypothetical: a single-location therapy practice

The practice has confirmed it is a covered entity. Its current site has an appointment form asking for name, phone, date of birth and reason for visit, and submissions are emailed to the front desk. Option one is to move the whole site to hosting covered by an agreement and also review the email path, since the inbox now holds those submissions. Option two is to replace the form with a link to the practice’s scheduling vendor, already under an agreement, and keep the marketing site on whichever platform suits the team’s editing habits. In our view option two leaves fewer systems to review, while option one keeps visitors on a single domain. The practice’s privacy officer makes the choice.

Hypothetical: a digital health startup with a tracking app

The company’s marketing site runs on Framer, and its app tracks sleep and mood. The site’s only form is a waitlist asking for an email address. A sensible scope keeps all app data in the product’s own infrastructure, keeps the waitlist minimal, and asks counsel whether the FTC rule applies to the app. Paying for special hosting on the marketing site would not address where the actual health data lives.

Hypothetical: a multi-location group changing platforms

The group is moving from a self-hosted WordPress site to Webflow. Before cutover, check whether the old form plugin stored submissions in the WordPress database, and decide with the privacy officer whether to export, retain or delete them under your retention policy. If URLs stay the same, Google’s documentation points hosting changes to separate guidance for infrastructure changes. If URLs change, the same documentation says to expect temporary ranking fluctuation while Google recrawls and to keep redirects generally for at least one year (Google Search Central). No migration plan can promise unchanged rankings. Our guide on migrating a medical practice website without losing useful URLs, on the Insights page, covers the redirect side in more depth.

Questions to ask before you sign

1. Will you sign a business associate agreement, and which products and plans does it name?
2. Which subcontractors handle the data, and do they sign equivalent terms?
3. Where are form submissions stored, for how long, and who on our side can see them?
4. How do you support unique user accounts, activity logs and session timeouts for anyone viewing that data?
5. How and when will you report a security incident to us?
6. At termination, how is our data returned or destroyed?

For your designer or developer, ask which third-party scripts will load on pages with forms, whether they will ever see live submissions, and how admin access is handed over at launch.

FAQs

Is WordPress, Webflow or Framer HIPAA compliant?

The regulations quoted here place obligations on covered entities and business associates, not on website builders as products. Whether a given vendor will sign an agreement, and for which plans, is a question for that vendor’s current terms.

Do we need it if our site has only a contact form?

It depends on who you are and what the form asks. A general inquiry form on a company site differs from an appointment request on a provider’s site. Have your privacy officer review the exact fields against the definitions in 45 CFR 160.103.

Does an SSL certificate make hosting HIPAA compliant?

Encryption in transit relates to the transmission security standard in 45 CFR 164.312(e), where encryption is addressable. It is one safeguard among several in that section, and it is not a substitute for the contract terms in 164.504(e) when a vendor is a business associate.

Can Health Site Works make our website HIPAA compliant?

No. Health Site Works designs and builds healthcare marketing websites, redesigns and migrations on Framer, WordPress and Webflow, and does not guarantee compliance outcomes. Clinical systems, patient portals and sensitive intake need separate scope and provider review.

How is pricing set?

Pricing is set case by case after scoping, based on actual need, and there is no public rate card. The pricing page explains the approach.

If you are planning a redesign or migration and want the marketing site scoped around these boundaries, review our services and the healthcare design projects on our Selected work page, then send an inquiry through the contact page. A submission starts a conversation; it is not a booking. Please leave health details out of it.