HIPAA Website Security Requirements: What Healthcare Sites Must Implement
HIPAA compliance for a website is not a checkbox — it is a set of specific technical, administrative, and physical safeguards that apply the moment your site collects, stores, transmits, or provides access to Protected Health Information (PHI). Whether you run a patient portal, a telehealth platform, a healthcare SaaS tool, or even a contact form that collects symptoms, HIPAA's Security Rule applies to you.
This guide covers what the Security Rule technically requires at the web layer: the HTTPS configuration, encryption standards, access logging, and operational controls that OCR (the HHS Office for Civil Rights) will examine in an investigation.
Check your compliance posture: Free ZeriFlow security scan →
Who Is Covered: Covered Entities, Business Associates, and the Web Layer
HIPAA applies to two categories of organization:
Covered Entities — healthcare providers, health plans, and healthcare clearinghouses that handle PHI in the course of providing care or processing claims.
Business Associates (BAs) — vendors, contractors, and service providers that create, receive, maintain, or transmit PHI on behalf of a covered entity. This includes cloud hosting providers, analytics platforms, EHR integrators, and SaaS tools used by healthcare organizations.
If you build software for healthcare, you are almost certainly a Business Associate. The implication: you need a signed Business Associate Agreement (BAA) with every covered entity you serve, and you must independently comply with the Security Rule — not just inherit compliance from your customer.
For websites specifically, the threshold is lower than most people assume. A contact form with a "describe your symptoms" field, a patient appointment scheduler, or a provider directory with message capabilities can all constitute ePHI (electronic PHI) transmission.
HTTPS Enforcement: The Minimum Technical Safeguard
The HIPAA Security Rule's Technical Safeguards (45 CFR § 164.312) include the requirement to implement "encryption and decryption" for ePHI in transit (§ 164.312(e)(2)(ii)). While HIPAA uses the word "addressable" (meaning you must implement it or document why an equivalent alternative was used), in practice, there is no credible alternative to TLS for web-based ePHI transmission in 2024.
What HTTPS enforcement means technically:
- HTTP-to-HTTPS redirect — Every request arriving on port 80 must redirect to HTTPS. A user who types your domain without a scheme must end up on TLS.
- HSTS header —
Strict-Transport-Security: max-age=31536000; includeSubDomainstells browsers to always use HTTPS and prevents SSL stripping attacks. - No mixed content — A page served over HTTPS must not load any resources (scripts, images, API calls) over HTTP. Mixed content nullifies the TLS protection for those resources.
- Valid, trusted certificate — Expired certificates, self-signed certificates on patient-facing interfaces, or certificates for the wrong domain are not acceptable.
TLS Configuration for HIPAA: Protocol and Cipher Requirements
HIPAA does not specify minimum TLS versions by name, but HHS guidance and the NIST Special Publication 800-52 (which HHS references) are explicit: TLS 1.2 is the minimum acceptable protocol. TLS 1.3 is preferred.
SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 are deprecated and must be disabled. In addition to protocol version, cipher suite selection matters:
- Disable export-grade ciphers (FREAK, LOGJAM attacks)
- Disable RC4 (BEAST, multiple attacks)
- Disable NULL and anonymous cipher suites
- Prefer ECDHE key exchange for forward secrecy — this ensures that a future compromise of your private key does not decrypt past sessions
Forward secrecy is particularly relevant for healthcare data. Clinical records have a long shelf life; ensuring that intercepted traffic cannot be retroactively decrypted if your keys are later exposed is a meaningful safeguard.
ZeriFlow scans your TLS configuration end-to-end, checking protocol versions, cipher suites, forward secrecy support, and certificate validity — providing the kind of outside-in view that an OCR technical auditor would perform.
Access Controls and Authentication for Patient Portals
§ 164.312(a) requires unique user identification, emergency access procedures, automatic logoff, and encryption/decryption. For web-based healthcare applications:
Unique user identification — Every user must have a unique identifier. Shared accounts are prohibited for any user accessing ePHI.
Multi-Factor Authentication — Not explicitly required by the 2003 Security Rule text, but the 2024 HIPAA Security Rule update (proposed rule) makes MFA mandatory for ePHI access. Given the current regulatory direction and OCR's settlement history, any healthcare web application without MFA is a significant risk.
Automatic session logoff — Sessions must terminate after a defined period of inactivity. The standard is 15 minutes for clinical interfaces; less sensitive patient portals commonly use 30 minutes. The Secure and HttpOnly cookie attributes are required for session tokens.
Role-based access control — Access to ePHI must be restricted to users with a clinical or operational need. Audit logs must record who accessed what.
Audit Logging: What HIPAA Requires You to Record
§ 164.312(b) requires activity in information systems containing ePHI to be recorded and examined. For a web application, this means:
- Authentication events — Every login attempt (successful and failed), with timestamp, user ID, and source IP.
- ePHI access events — Every record view, download, or print.
- Administrative actions — User account creation, permission changes, configuration modifications.
- Data modification events — Every create, update, or delete operation on ePHI.
Log management requirements under HIPAA: - Logs must be retained for six years (HIPAA's documentation retention standard). - Logs must be protected from unauthorized modification — append-only storage or tamper-evident log management systems. - Logs must be regularly reviewed — §164.308(a)(1)(ii)(D) requires information system activity review.
The 2024 proposed update adds requirements for logging access to network devices and audit log backup — moving toward the continuous monitoring posture already standard in SOC 2 and PCI DSS.
Business Associate Agreements and Third-Party Vendors
Every vendor with access to ePHI — cloud hosting, CDN, analytics, support ticketing, email — must sign a BAA. This is a HIPAA-specific contract addendum that obligates the vendor to protect ePHI under the same standards as you.
Common BAA landmines for healthcare websites:
Google Analytics / Google Tag Manager — Standard GA4 does not have a BAA. If you use GTM to fire tracking pixels on pages where users enter health information, you may be transmitting ePHI to Google without a BAA. Solutions: use a BAA-covered analytics tool (Matomo self-hosted, Plausible, or Google Analytics with the DPA/BAA in place), or configure GTM to fire only on non-PHI pages.
Live chat and support tools — Intercom, Zendesk, Freshdesk all offer BAAs, but you must request them explicitly. The default product tier often does not include BAA coverage.
Hosting and infrastructure — AWS, Google Cloud, Microsoft Azure, and most major cloud providers offer BAAs. Your hosting provider must sign one.
Error monitoring — Sentry, Datadog, and similar tools may capture PHI in error traces (stack frames, user context, request bodies). Configure them to scrub PHI or ensure a BAA is in place.
FAQ
Q: Does a healthcare website need HIPAA compliance if it only has a contact form?
A: It depends on what information the contact form collects. A form asking for name and email to request a brochure is unlikely to involve PHI. A form asking for symptoms, diagnosis, medications, or appointment type — in the context of a healthcare provider's website — can constitute PHI. The safe approach: treat any form on a healthcare provider's site that collects health-related information as subject to HIPAA, implement TLS, and do not use third-party form tools without BAAs.
Q: What is the penalty for a HIPAA breach caused by a misconfigured website?
A: OCR penalty tiers range from $141 to $2,134,831 per violation category per year, depending on culpability. "Willful neglect" — which includes knowingly operating without required technical safeguards — carries the highest penalties. The 2023 settlement with a telehealth company for $100,000 over an unsecured API endpoint illustrates the scale of enforcement for web-layer failures.
Q: Is HIPAA compliance required if we are a SaaS company that serves hospitals?
A: Yes, if your software processes, stores, or transmits ePHI on behalf of those hospitals. You are a Business Associate, and you must independently comply with the HIPAA Security Rule — not just sign a BAA and outsource compliance responsibility to your customer. This includes encryption in transit, access logging, access controls, and a formal risk assessment.
Q: Does the proposed 2024 HIPAA Security Rule update change anything for websites?
A: The proposed 2024 update (not yet finalized as of this writing) would make several web-relevant requirements mandatory that were previously "addressable": encryption in transit, MFA, network segmentation, and audit log backup. Most well-run healthcare web operations already implement these; the update primarily closes loopholes used to avoid encryption deployment.
Q: Can we use a shared SSL certificate for HIPAA compliance?
A: A shared SSL certificate (e.g., a wildcard or SAN certificate shared across multiple tenants on a hosting platform) is technically acceptable if properly isolated. The concern is not the certificate sharing itself — it is the infrastructure isolation. If multiple tenants share web server processes or database connections, PHI from one tenant can leak to another. HIPAA requires that ePHI be accessible only to authorized users; multi-tenant isolation must be demonstrated.
Conclusion
HIPAA website security is not optional, and it is not satisfied by a privacy policy page. The Security Rule requires demonstrable technical controls: TLS 1.2+ enforced on every endpoint, automatic logoff, unique user identification, audit logging retained for six years, and BAAs with every vendor that touches ePHI.
The good news is that most of these controls align with general web security best practice — a securely configured site is a HIPAA-compliant site for purposes of the Technical Safeguards. The gap is almost always in the details: a missing HSTS header, an analytics tool without a BAA, or log files that are not retained.