Building a healthcare website in 2026 without a structured HIPAA compliance program is not a calculated risk. It is a compliance failure waiting to be documented by OCR. The average healthcare data breach now costs $7.42 million. OCR resolved 21 investigations with financial penalties in 2025, the second-highest annual total on record. The 2025 Security Rule updates have moved MFA, encryption at rest, and network segmentation from addressable options to required controls. And the most commonly exploited gaps are not in core EHR systems. They are in web-facing properties: contact forms, appointment schedulers, chat widgets, and third-party analytics tags that process patient data in ways the development team never explicitly reviewed. This guide covers what the current compliance requirements actually mean for a healthcare website build, where the highest enforcement risk sits, and how to approach the project without creating new liability.
Table Of Contents
Table Of Contents
What HIPAA Actually Requires of a Website
The confusion most healthcare IT teams run into is treating HIPAA compliance as a hosting question. If the server is HIPAA-compliant and the form data is encrypted, the assumption is that the website is covered. It is not, and the gap between that assumption and the actual requirement is where most enforcement actions are finding their footing.
HIPAA organizes its obligations into four rules. The Privacy Rule defines when Protected Health Information (PHI) may be used or disclosed. The Notice of Privacy Practices is required, as are provisions for patient rights and a minimum necessary standard for PHI access. The Security Rule requires administrative, physical, and technical safeguards on all ePHI systems to protect them against unauthorized access or disclosure. The Breach Notification Rule mandates that covered entities notify HHS, patients, and in some cases, the media of a breach within a specific time frame. The Enforcement Rule regulates how the Office for Civil Rights (OCR) investigates and penalizes violations of HIPAA, broken down into four tiers of violation which go from $145 per violation (unintentional) up to $2,190,294 per violation (willful neglect not corrected; these amounts are adjusted annually for inflation) (Source:Medha Cloud).
For a website specifically, the Security Rule is where most compliance work lives. Technical safeguards required for any web property that handles ePHI include: TLS 1.3 or higher for data in transit, encryption of data at rest, multi-factor authentication for any system access, role-based access controls limiting who can reach what data, audit logging of all ePHI access and modifications, automatic session timeouts, and documented incident response procedures that include the 60-day breach notification window.
The 2025 HIPAA Security Rule updates, published by HHS as a Notice of Proposed Rulemaking, have elevated several previously “addressable” controls to required status. MFA is no longer optional for covered entities. Network segmentation is now a required safeguard rather than a best practice. Annual HIPAA compliance audits for all covered entities and business associates are being proposed as mandatory rather than recommended. The shift is from “you should consider these controls” to “demonstrate you have implemented them or explain why not” (Source:CBIZ).
Where Web-Facing Risk Actually Concentrates
Healthcare IT Directors who have managed enterprise infrastructure security often find that the highest compliance risk on their web properties is not in the parts they managed most carefully. It is in the parts the marketing team configured independently.
A contact form that asks for a patient’s name, date of birth, and description of their medical concern is collecting ePHI. If that form sends submissions to a standard email inbox without encryption, routes through a third-party form service that has not signed a Business Associate Agreement, or stores responses in a CRM not configured for HIPAA, the form is a violation. This is not a hypothetical. It is a documented pattern in OCR enforcement, and it shows up repeatedly in smaller practices where IT did not know marketing added a new intake form.
Third-party code in the browser is the other high-risk surface. Modern websites load scripts from many external domains: analytics platforms, advertising pixels, session recording tools, chatbots, appointment schedulers, CDN providers, and captcha services. When a patient visits a healthcare site and those scripts execute in their browser, the question of whether those scripts are accessing, logging, or transmitting ePHI becomes a compliance question that requires an explicit answer. HTTP Archive data shows that the average website loads resources from dozens of external domains. For a healthcare site, each of those external relationships requires evaluation.
If a pixel from a major advertising platform is firing on a page where a patient can view their appointment details or submit health information, that pixel is potentially transmitting ePHI to an advertising platform that almost certainly does not have a BAA with your organization. OCR has taken enforcement action specifically around tracking technologies on healthcare websites, and that enforcement activity has increased since 2022 (Source:Feroot Security).
The practical audit question for any healthcare website is not just “is the server secure?” It is “what scripts execute in the patient’s browser on every page, what data do they access, where does that data go, and does a BAA cover every vendor in that chain?”
Business Associate Agreements: The Contract No One Is Reading Carefully Enough
A Business Associate Agreement is the contractual mechanism that extends HIPAA obligations to vendors who handle ePHI on behalf of a covered entity. Your web hosting provider, your CMS vendor, your form processing service, your patient portal vendor, your CRM, your email platform, your analytics provider, and any other third party that touches patient data in the course of supporting your website needs to have signed a BAA with your organization before they handle that data.
The gap that shows up consistently in OCR enforcement is not that organizations have no BAAs. It is that the BAA coverage is incomplete. A vendor is added to the marketing stack, configured by someone who did not flag it to IT or compliance, and the fact that it processes patient data is not identified until an incident creates a backward-looking audit. Business associates are involved in 34% of healthcare breaches (Source:Medha Cloud). In most of those cases, the BAA existed but either did not accurately describe the scope of data processing or covered a different set of services than what the vendor was actually doing.
The due diligence for a healthcare website build requires an explicit mapping of every third-party service, what patient data it accesses or processes, and whether a BAA covering that specific scope is in place. That mapping should be a living document, updated every time a new script, plugin, integration, or platform is added to the site.
The BAA also needs to cover your web development agency if they will have any access to systems containing ePHI during the build or testing process. This is a requirement most smaller healthcare organizations miss. The developer who deploys the site to a server containing patient data is acting as a business associate for the duration of that access. Document it and cover it contractually.
Technical Safeguards for a HIPAA-Compliant Healthcare Website: The Practical Checklist
This is not a comprehensive substitute for a documented risk analysis, which is its own required HIPAA deliverable. It is the technical checklist that belongs in every healthcare website build scope, regardless of the broader compliance program.
Hosting. Select a HIPAA-compliant hosting provider who will sign a BAA. AWS, Google Cloud, and Microsoft Azure all offer BAA coverage for their healthcare configurations. Managed healthcare hosting providers like HIPAA Vault or Atlantic.Net also offer pre-configured HIPAA environments. Shared hosting, generic WordPress hosts, and any provider who will not sign a BAA are not appropriate for a healthcare web property handling ePHI. An estimated 47 percent decrease in breach risk occurs when healthcare firms use HIPAA-compliant cloud hosting versus using self-hosted systems (Source:Medha Cloud).
Encryption. TLS 1.3 minimum for all data in transit. Encryption at rest for any stored patient data, including form submissions, database records, and backup copies. The proposed 2025 Security Rule update would make encryption of all ePHI at rest mandatory rather than addressable. Build to that standard now rather than retrofitting later.
Authentication. Multi-factor authentication for every administrative account, every CMS login, every server access path, and every patient portal entry point. Session timeouts of 15 to 30 minutes for inactive authenticated sessions. Automatic logout on browser close for sessions containing ePHI.
Access controls. For those accessing patient records are role-based limiting each user’s access to the minimum amount of protected health information required to perform their job functions. An example is separating an administrative user’s account from an account used for creating or editing the content. Service accounts will have least privilege when used for integrations or APIs.
Audit logging. Immutable logs of all access to systems containing ePHI, all data modifications, all authentication events, and all administrative actions. Logs retained for the HIPAA-required minimum of six years. Log integrity protection preventing tampering or deletion.
Form and data handling. Every form that could receive PHI must have explicit handling procedures: where does the submission go, how is it encrypted in transit, where is it stored, who has access, and is the receiving system covered by a BAA. Automated confirmation emails containing PHI need the same treatment. Generic email platforms like Gmail or standard Mailchimp are not HIPAA-compliant without specific configurations and BAAs.
Third-party script governance. Maintain an inventory of every script loaded by your site. For each one: what data can it access in the browser, where does it send that data, and is there a BAA covering that relationship. Disable or replace any script that accesses patient data without BAA coverage. Consider a Content Security Policy (CSP) header that restricts which external domains can execute scripts in the patient’s browser.
Patient portal security. If the website includes a patient portal, the portal requires penetration testing before launch and on a defined schedule thereafter. Vulnerability scanning should run continuously. The new 2025 Security Rule changes require all covered entities to do mandatory penetration testing at regular intervals.
Privacy policy and Notice of Privacy Practices. The Privacy Policies & Notice of Privacy Practices shall be up to date, accurate and capable of easy access. The HIPAA/i.e.(Health Care Portability & Accountability Act) Covered Entity must have a Notice of Privacy Practices as a requirement. The Notice of Privacy Practices also explains how PHI (Protected Health Information) is utilized and disclosed, as well as the use of digital channels for sending/receiving PHI.
The 2025 Security Rule Changes and What They Mean for Your Build
The HHS proposed Security Rule updates, published in January 2025, represent the most significant changes to HIPAA’s technical requirements since the original Security Rule was finalized in 2003. For healthcare website development, the most operationally significant changes are:
MFA is required, not addressable. Every access point to systems containing ePHI needs multi-factor authentication. This was addressable before, which meant covered entities could document a rationale for not implementing it. That flexibility is going away.
Network segmentation is required. Systems that store or process ePHI must be isolated from general network traffic. For web properties, this means patient portal backends and any system that stores form submissions or appointment data cannot be on the same network segment as general office infrastructure.
Encryption at rest is required. Data encryption in storage is proposed to be mandatory rather than addressable. Every computer system that has ePHI stored internally or externally, including physical media on web servers, databases, back-up systems and Cloud systems, should implement data encryption while the computer system is powered off.
The proposed annual compliance audit will be required and the annual review of all HIPAA controls with an updated risk assessment and documented evidence of remediation for any identified gaps.
Incident response plans must be tested. Not just documented. Tested and updated at defined intervals (Source:CBIZ).
The practical implication for a website build starting now: design to the proposed rule, not the current rule. The NPRM is expected to finalize, and retrofitting a site built to older standards will cost more and take longer than building to the incoming requirements from the start.
Enforcement: What OCR Is Actually Targeting
Understanding where enforcement concentrates helps IT Directors prioritize remediation and build effort. The 2025 enforcement pattern is instructive.
OCR has resolved a total of 21 investigations with financial sanctions in 2025, the second-highest number of such investigations resolved in any given calendar year. A major area of focus for enforcement in 2025 was compliance with the risk analysis provision contained in the Security Rule of HIPAA. Many of the 2025 settlement agreements were with organizations that had not completed any documented risk analysis, or had done so but had not taken action on the results of that analysis. OCR continues to enforce both the requirement to conduct a risk analysis, as well as the requirement to manage risks identified through that process.
55% of OCR settlements in 2022 were imposed on small medical practices, a trend that continued into 2025. The idea that large hospital systems are the only targets for enforcement is untrue. In fact, smaller practices have been found to have a greater number of documentation issues (missing), BAA coverage issues (incomplete), insufficient security training, and all of these areas are what enforcement will be focusing on.
80% or more of the reported breaches occurring in 2025 will be primarily due to hacking or IT incidents with the vast majority being an attack type of ransomware. The attack surface associated with these incidents consist of web facing systems (i.e., patient portals, appointment scheduling tools, and contact forms open to clinical systems when not properly isolated) (Source:FaxSIPit).
The Sept 2025 OCR Cadia Healthcare settlement was completely focused on Web Client-level access & authorization controls (i.e., web-based systems). They are front-door access points to patient data and are being treated accordingly.
What This Means for Selecting a Development Partner
A healthcare website development project requires a partner who understands HIPAA as a technical constraint on the build, not as an afterthought the compliance team addresses after launch.
The questions to ask any development agency or vendor before engagement:
Have they built HIPAA-compliant healthcare websites before, and can they provide references from clients in the same regulatory category? Do they have documented experience with HIPAA technical safeguards in a web development context, not just a general security background? Will they sign a Business Associate Agreement for the duration of the project and for any ongoing access to systems containing ePHI? Do they have a process for third-party script auditing and a Content Security Policy implementation in their standard healthcare builds? Can they walk through their testing and QA process specifically for HIPAA compliance, including how they handle test data and staging environments?
The development agency’s security posture during the build is as relevant as the security posture of the finished site. A developer with administrative access to a server containing patient data is handling ePHI, regardless of whether they are looking at it. The BAA and the contractual provisions around data handling apply to the build process, not just the post-launch operation.
Healthcare data breaches cost an average of $7.42 million. Penalties under HIPAA are tiered from $145 (per violation) to $2.19 million (per violation). The Office for Civil Rights (OCR), as the enforcement agency under HIPAA, entered into twenty-one settlements in 2025. OCR has also focused increasingly on compliance with web-facing access control and risk assessment standards.
The highest web-facing risk is not in the server infrastructure. It is in third-party scripts executing in patients’ browsers, unsecured forms collecting ePHI, and business associate relationships that are undocumented or incomplete.
The 2025 Security Rule updates elevate MFA, encryption at rest, and network segmentation from addressable to required. Build to the proposed standard now rather than retrofitting.
Every vendor that handles ePHI in the course of supporting your website needs a BAA. This includes hosting providers, CMS platforms, form services, analytics tools, CRMs, email platforms, and the development agency with access during the build.
Risk analysis is both a required deliverable and a current enforcement priority. Documenting risks is necessary but not sufficient. OCR is enforcing the requirement to manage risks identified in the analysis.
Smaller practices are disproportionately represented in enforcement actions. Compliance effort is not proportional to organization size. The obligations are the same.
Frequently Asked Questions
What makes a healthcare website HIPAA compliant?
A HIPAA-compliant healthcare website has technical safeguards covering data in transit (TLS 1.3 minimum), data at rest (encryption required), authentication (MFA for all system access), access controls (role-based, least privilege), audit logging (six-year retention minimum), and documented incident response procedures. It also has signed Business Associate Agreements with every vendor that handles ePHI in the course of supporting the site, and a completed risk analysis that has been acted upon. HIPAA compliance is not a product or a certificate. It is a documented, ongoing program.
Do contact forms on a healthcare website require HIPAA compliance?
Yes, if those forms collect information that could identify a patient and connect them to their health condition, treatment, or payment information. A form asking for name, date of birth, and a description of a medical concern is collecting ePHI. The form submission must be encrypted in transit, stored in a HIPAA-compliant system, handled only by authorized personnel, and routed through vendors who have signed BAAs. A standard web contact form routed to a regular email inbox is not HIPAA compliant.
What is a Business Associate Agreement and why does every vendor need one?
A Business Associate Agreement is a contractual commitment that a vendor handling ePHI on your behalf will safeguard that data in accordance with HIPAA requirements, report breaches, and restrict access to authorized purposes. Any vendor whose service involves touching, storing, or transmitting patient data must sign one before they begin. This includes your hosting provider, CMS, form service, CRM, email platform, analytics provider, chatbot, appointment scheduler, and the development agency if they access systems containing patient data during the build.
What HIPAA violations are most common on healthcare websites?
The missing/incomplete risk analysis documents; unsecured web form(s) collecting PHI; third-party marketing scripts transmitting ePHI without BAA coverage; inadequate authentication (no MFA on admin accounts or patient portals); and insufficient audit logging, along with business associate relationship(s) not supported by a signed BAA(s), can all be helped through structured development standards/requirements and an established pre-launch compliance review process.
How often does a HIPAA-compliant healthcare website need to be audited?
The current Security Rule requires regular reviews without specifying a fixed interval. The proposed 2025 Security Rule updates would make annual compliance audits mandatory for all covered entities and business associates. Best practice for web properties is quarterly review of third-party script inventory, annual penetration testing, and annual documentation review covering risk analysis findings and remediation status.
Conclusion
Building a healthcare website in 2026 is a compliance engineering project as much as it is a design and development project. The decisions made during the build about hosting, authentication, third-party integrations, form handling, and vendor contracts determine the organization’s exposure for years after launch. Getting those decisions right requires a development partner who understands HIPAA as a technical discipline, not just as a checklist to submit to a compliance officer after the site goes live.
KrishaWeb’s web design and development services include healthcare website builds with HIPAA technical safeguards designed into the architecture from the start: compliant hosting selection, BAA guidance, third-party script auditing, MFA implementation, audit logging, and documented handoff for your compliance program. Our AI consulting team helps healthcare organizations implement patient engagement tools and personalization that operate within the HIPAA boundary rather than creating new exposure outside it.
The Free Healthcare Website Quote includes a compliance scoping conversation to identify your specific regulatory requirements, the technical safeguards your project requires, and the BAA coverage you need before development begins.
A Technical Architect, proficient in WordPress, Drupal, Laravel, and DevOps tasks, crafts robust IT solutions with a blend of expertise and versatility in web development and infrastructure management.
KrishaLabs
KrishaStudio
KrishaStore
