If your website collects, transmits, or stores protected health information, it must meet HIPAA safeguards, and the mandatory first step is a risk analysis tailored to your specific site. Start there, then prioritize business associate agreements with every vendor touching that data and technical safeguards like TLS encryption and access controls. Skipping the risk analysis is the single most common reason practices fail an audit.
TL;DR:
- Conduct a thorough risk analysis to identify all touchpoints where protected health information is collected, transmitted, or stored on your site.
- Ensure all third-party vendors, including hosting providers and tools, sign Business Associate Agreements that specify data use, breach reporting, and subcontractor obligations.
- Implement technical safeguards like TLS encryption, multi-factor authentication, and detailed audit logs from the start to meet HIPAA requirements.
- Regularly test your site with vulnerability scans and penetration testing to identify and fix misconfigurations or weak security controls.
- Keep marketing trackers on authenticated pages blocked or replaced with server-side analytics to prevent inadvertent access to PHI and vendor relationships from becoming compliance risks.
Mapping every place PHI touches your site
Before you fix anything, you need to know where protected health information actually lives on your site. Authenticated pages, such as patient portals, work differently than public marketing pages: once a patient logs in, nearly everything they see or submit counts as PHI, while your public "About Us" page usually does not.
A simple inventory catches what teams typically miss:
- Contact and intake forms that collect symptoms, insurance details, or appointment reasons.
- Patient portals and login areas where records, messages, or lab results appear.
- Chat widgets connected to scheduling or triage that store conversation logs.
- Third-party integrations like appointment schedulers, payment processors, or telehealth embeds that send data via API calls or webhooks.
- Server and application logs that may capture PHI in URL parameters or form submissions without anyone noticing.
Document each touchpoint with what data it collects, where it goes, who can access it, and which vendor handles it downstream. This inventory becomes the foundation of your risk analysis, required under the Security Management Process described by HHS's guidance on risk analysis. Skip this step and every later safeguard is a guess.
Safeguards your website needs across three categories
HIPAA's Security Rule organizes protections into three buckets, and a website touches all three even though most of the technical work happens on the back end.
- Administrative safeguards: written policies for data handling, workforce training on PHI recognition, least-privilege access rules so only staff who need patient data can see it, and documented incident response procedures.
- Technical safeguards: TLS/SSL encryption for every page that transmits data, encryption at rest for stored records, multi-factor authentication for any staff or patient login, automatic session timeouts, and audit logs that record who accessed what and when.
- Physical safeguards: controlled access to servers (your own or your host's), locked network equipment, and secure, redundant backups if you manage any on-site infrastructure.
For technical controls, specifics matter more than general intentions. Session timeouts of a few minutes of inactivity are a common baseline for patient portals. Audit logs should retain enough detail to reconstruct who touched a record and when, and many organizations keep those logs for multiple years to align with HIPAA's documentation retention requirements. MFA should apply to every account with access to ePHI, not just administrator logins.
Pro Tip: Build a single access control policy document that lists every role (front desk, clinician, developer, marketing) and exactly what PHI each can see. It turns a vague audit question into a five-minute answer.
None of this happens by accident. Least-privilege access and audit logging need to be designed into the site's architecture from the start, not patched on after a vendor flags a gap.
Vetting hosts and vendors before they touch patient data
Any cloud provider, hosting company, or third-party tool that creates, receives, maintains, or transmits ePHI on your behalf is a business associate under HIPAA, and that relationship requires a signed Business Associate Agreement before any data changes hands. This applies to your web host, your email service, your appointment scheduler, and any analytics tool that touches authenticated pages.
A BAA needs to spell out permitted and prohibited uses of the data, the vendor's breach reporting obligations, and how the vendor flows those same obligations down to any subcontractors it uses. Before signing with a host or platform, ask:
- Who holds the encryption keys, and can the vendor access unencrypted data?
- What logging and audit trail capabilities does the platform provide?
- What is the uptime SLA, and how does the vendor handle failover during an outage?
- Will the vendor sign a BAA at all, or does its terms of service exclude healthcare use?
A generic hosting plan without a BAA is not an option once ePHI is involved, regardless of how good its uptime numbers look.
Running a risk analysis that actually holds up
A risk analysis is not a one-time checkbox. HHS ties it directly to the Security Management Process under 45 C.F.R. § 164.308(a)(1)(ii)(A), and it has to reflect your organization's actual size, complexity, and technical environment rather than a generic template.
- Identify every system, vendor, and touchpoint from your PHI inventory, then assess the likelihood and impact of a breach at each one.
- Prioritize fixes by risk level: an unencrypted patient intake form outranks an outdated favicon every time.
- Assign owners and deadlines for each remediation item, and track completion in writing.
- Monitor continuously through regular log reviews, a defined vulnerability scanning cadence, and recurring staff training sessions.
Treat the risk analysis as a living document. Revisit it whenever you add a new vendor, launch a new form, or change hosting providers, not just once a year on a compliance calendar.
Why analytics and tracking scripts are a hidden risk
Standard marketing analytics can quietly turn into a HIPAA violation. OCR has warned that tracking technologies on authenticated webpages can access PHI and may create a business associate relationship with the tracking vendor, which then requires its own BAA or patient authorization.
Practical steps that keep marketing tools from becoming compliance liabilities:
- Block third-party trackers on any authenticated page, including patient portals and post-login dashboards.
- Use server-side or de-identified analytics on public pages instead of scripts that can capture identifiable browsing behavior tied to a health condition.
- Document every tracker your site runs, what data it captures, and whether it sits on a public or authenticated page.
Pro Tip: Run a browser network tab check on your patient portal login page. If you see calls to ad or analytics domains after login, that tracker needs to go or needs a BAA.
What to do in the first hours after a breach
If ePHI is exposed through your website, the Breach Notification Rule sets firm deadlines and documentation expectations, detailed in HHS's breach notification guidance.
- Contain first: preserve logs, isolate the affected system, and rotate any exposed credentials or encryption keys before doing anything else.
- Assess scope: determine how many individuals were affected, since breaches involving 500 or more people carry different reporting timelines than smaller incidents.
- Notify: affected individuals and HHS OCR within the rule's required windows, using your documented incident response procedure.
- Document: your risk assessment of the incident, including any low-probability-of-compromise determination, in writing for your compliance file.
Speed and paperwork both matter here. A fast technical response without documentation still leaves you exposed during an audit.
A 30/60/90 roadmap for getting compliant
Getting a website audit-ready is a sequencing problem more than a technical one. Start with what regulators check first.
- Days 1 to 30: complete the risk analysis, inventory every vendor touching ePHI, and get BAAs signed with your host, email provider, and any form or chat tool.
- Days 31 to 60: implement TLS everywhere, enable encryption at rest, add MFA to all staff and patient logins, and configure audit logging.
- Days 61 to 90: remove or reconfigure third-party trackers on authenticated pages, post your Notice of Privacy Practices, and run a first vulnerability scan.
Auditors typically expect to see written policies, training logs, signed BAAs, and a dated risk analysis, not just a secure-looking site. HHS's own Security Rule guidance frames these as safeguards chosen for your specific environment, which means there is no single checklist that satisfies every practice equally, your documentation has to match what you actually built.
Getting patient consent right on your site
A consent form on your website is only as good as what it actually authorizes. HIPAA's Privacy Rule distinguishes between routine treatment, payment, and operations, which generally do not require separate patient authorization, and other uses like marketing communications or sharing data with a third-party research partner, which do.
Any online consent or authorization form should state clearly what data is being collected, exactly how it will be used, who will see it, and how long it will be retained. A vague checkbox that says "I agree to the privacy policy" does not meet that bar for anything beyond basic site use. For telehealth intake, appointment requests, or any form that shares data with an outside vendor, the form needs its own explicit, plain-language authorization separate from your general Notice of Privacy Practices.
Electronic signatures are acceptable, but the form and its submission need the same technical safeguards as any other PHI touchpoint: TLS encryption in transit, restricted access to stored responses, and an audit trail showing when and how consent was given. Keep records of the exact version of the consent language a patient agreed to, since forms change over time and you may need to reproduce what a specific patient actually saw and accepted.
Build your consent flow so it fails safely: if a required authorization is not confirmed, the form should not submit, rather than silently proceeding without valid consent.
Keeping linked email communications secure
Many healthcare websites link directly to email for appointment requests, prescription refills, or general questions, and that link is a common weak point. Standard email is not encrypted end to end by default, so any message containing PHI needs a secure alternative before it ever leaves the browser.
The safest pattern is routing website email links to a secure patient messaging system or an encrypted email gateway rather than a plain "mailto:" link that opens an unencrypted client. If your practice does use email for PHI, it needs to run through a provider that will sign a BAA and offers encryption in transit, ideally with encryption at rest for stored messages too.
Practical guardrails for any email flow linked from your website:
- Avoid asking patients to email sensitive details through unencrypted forms or standard email links.
- Route sensitive communication through a secure portal instead, with email used only to notify the patient that a message is waiting.
- Confirm your email or messaging vendor will sign a BAA before it goes live on the site.
A single unencrypted "contact us" email address that accepts symptom descriptions or insurance numbers can undo the encryption work done everywhere else on the site.
Backups and disaster recovery under HIPAA
A HIPAA compliant website needs a recovery plan for the data behind it, not just protection while everything is running normally. The Security Rule expects covered entities to have data backup and disaster recovery procedures so that ePHI remains available and unaltered even after a system failure, ransomware incident, or natural disaster.
That means backups need the same protections as live data: encryption at rest, restricted access, and logging of who restores or accesses a backup copy. A backup stored in plain text on an unsecured drive defeats the purpose of encrypting your live database.
Practically, this looks like automated, encrypted backups on a defined schedule, stored with a provider willing to sign a BAA, and tested periodically to confirm a restore actually works. A backup nobody has tested is a plan that exists only on paper. Document your recovery time objective (how quickly systems come back online) and recovery point objective (how much data loss is acceptable) so your team has a clear target during an actual incident rather than making decisions under pressure.
Collecting only the data you actually need
The Privacy Rule's minimum necessary standard applies to your website just as much as it applies to a front desk conversation: collect only the PHI required for the specific purpose of the form or feature in front of the patient. An appointment request form does not need a full medical history, and a newsletter signup does not need a diagnosis code.
Review every form on your site against this question: does this field serve the immediate purpose, or is it collecting data "just in case"? Extra fields increase your risk surface without adding value, since every additional data point is something you now have to secure, retain, and eventually delete.
This also shapes how you design defaults. Optional fields should stay optional rather than required, and any field capturing sensitive detail should include a short explanation of why it is needed. Regularly audit your forms as your practice adds new services or vendors, since minimum necessary is not a one-time design decision, it is a standard your site needs to keep meeting as features change.
Testing your site before someone else finds the gap
Encryption and access controls only work if they are configured correctly, and the only way to confirm that is testing. Regular vulnerability assessments and periodic penetration testing catch the misconfigurations that a policy document cannot, an exposed API endpoint, a login page vulnerable to brute force, or a form that leaks data in error messages.
A vulnerability scan is an automated check for known weaknesses and should run on a defined cadence, often monthly or quarterly depending on how frequently the site changes. Penetration testing goes further: a tester actively attempts to exploit weaknesses the way an attacker would, and it is typically run annually or after any major change to the site's architecture, such as a new patient portal or a new payment integration.
Findings from either process feed directly back into your risk analysis. A vulnerability that scores high on both likelihood and impact should move to the top of your remediation list, not sit in a report nobody revisits. Keep dated records of every scan and test along with what was fixed and when, since this documentation is exactly what an auditor will ask to see if a complaint or breach investigation ever reaches your organization.
What we have learned building healthcare websites
The most common failure we see is not weak encryption, it is scope: a practice secures its portal but forgets a chat widget or an old form still logging submissions in plain text. Building compliance checks into every development sprint, rather than bolting them on before launch, catches these gaps while they are still cheap to fix.
— Loic
Building a HIPAA aligned website with Westcode
Our approach includes building secure websites and coordinating vendor relationships involved, such as BAA paperwork, hosting configuration, and compliance documentation. We emphasize client involvement throughout the development process, from initial discovery through launch, to ensure transparency in the site's data handling.
If your practice needs a site rebuilt around these safeguards, or an existing one audited for gaps, start with our web design and development services to scope the work. Practices integrating connected devices or automation into patient workflows can also review our connected devices and AI automation service pages for how those integrations fit into a secure build.
Where to verify these rules yourself
Every safeguard described here traces back to federal guidance, and it is worth reading the primary sources directly rather than relying on secondhand summaries. Start with HHS's guidance on risk analysis, its business associate rules, the breach notification rule, and the bulletin on online tracking technologies. For broader vendor and compliance workflow context, our post on PIPEDA compliance for AI agents in Canada covers similar vendor and BAA coordination challenges, though it applies to a different jurisdiction.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
FAQ
What websites are HIPAA compliant?
No website is HIPAA compliant on its own. Compliance depends on the safeguards, policies, and vendor agreements behind it, including encryption, access controls, a completed risk analysis, and signed BAAs with every vendor that touches ePHI.
How to know if a website is HIPAA compliant?
Check for TLS encryption on every page, a visible Notice of Privacy Practices, and confirm that any vendor handling patient data has signed a BAA as HHS requires. A completed, documented risk analysis is the clearest internal sign, since it is the first requirement under the Security Management Process.
Does a website need to be HIPAA compliant?
Only if it collects, transmits, or stores protected health information, such as through patient portals, intake forms, or scheduling tools tied to patient identity. A purely informational site with no patient data collection generally falls outside HIPAA's technical safeguard requirements.
What online platforms are HIPAA compliant?
No platform is inherently HIPAA compliant by default, including major hosting and cloud providers, until it is configured correctly and the vendor signs a BAA. Ask any host or SaaS tool directly whether it will sign a BAA and how it handles encryption key management before using it for patient data.
