How To Make a HIPAA Compliant Website: All Requirements

Building a HIPAA compliant website isn’t just a technical challenge—it’s a legal necessity when handling Protected Health Information (PHI). If your site collects, transmits, or stores any PHI, you’re required to meet strict HIPAA requirements. This goes far beyond simply adding a privacy policy or securing your web forms; it’s about establishing end-to-end safeguards that protect patient data at every touchpoint.

In this guide, we’ll walk you through every requirement for a truly HIPAA compliant website, from secure BAA hosting to advanced access controls and retention policies. We’ll explain why tools like TLS, HSTS, and CSP are essential, how to use secure forms, and why features like S/MIME for email or WordPress hardening matter. We’ll also clarify the difference between patient portals and marketing sites, so you know exactly what applies to you.

Our approach is practical and actionable, focusing on the real-world steps you need to take—no jargon or fluff. Whether you’re a healthcare provider, a developer, or an admin, we’ll help you understand how to manage third-party tracking pixels, implement robust logging, ensure de-identification, and keep your platform up-to-date. By the end, you’ll have a clear roadmap for making your HIPAA website secure, compliant, and trustworthy.

Ready to break down the requirements and get peace of mind? Let’s dive in and make sure your website checks every HIPAA compliance box, from hosting and secure forms to retention and deletion policies.

Hosting and BAAs

When it comes to creating a HIPAA website, your choice of hosting provider and the establishment of a Business Associate Agreement (BAA) are foundational steps that determine the security and legal compliance of your entire digital operation.

HIPAA-compliant hosting isn’t just about picking any web server; it’s about selecting a provider who understands the unique requirements of healthcare data. A proper BAA hosting solution means the provider is willing to formally accept responsibility for safeguarding PHI, and will sign a BAA that spells out their obligations under HIPAA. Without this agreement in place, your organization is at risk, no matter how robust your technical controls might be.

• BAA hosting providers must implement physical, technical, and administrative safeguards—this includes secure data centers, access controls, regular staff training, and incident response policies. It’s crucial to verify these safeguards are in active use, not just listed on marketing materials.
• Look for transparency around data handling practices. Reputable BAA hosting providers will openly discuss their backup routines, disaster recovery plans, and encryption methods—ensuring your data is secured both at rest and in transit via strong protocols like TLS.
• Every third-party service that touches PHI must also sign a BAA. This extends to email providers (for secure communications such as S/MIME), cloud storage, analytics, and even managed WordPress hosts. If a vendor won’t sign a BAA, they can’t be used for PHI.

Hosting isn’t just about storage—it’s about control and oversight. Your hosting provider should support or provide:

• Comprehensive logging of access and system activity, to support audit trails and breach detection.
• Support for advanced browser policies such as HSTS (HTTP Strict Transport Security) and CSP (Content Security Policy), which help prevent unauthorized access and code injection attacks.
• Tools and guidance for WordPress hardening if you’re using WordPress, including regular updates, secure configuration, and plugin monitoring—all critical to prevent vulnerabilities that could expose PHI.

Practical tip: Before signing with any hosting provider, review their BAA closely. Understand their breach notification processes and ensure you’re not left exposed by hidden loopholes. A quality BAA hosting partner will guide you through these details, not leave you guessing.

By prioritizing BAA hosting and demanding a comprehensive Business Associate Agreement, you lay the legal and technical groundwork for a secure, HIPAA-compliant website. It’s one of the smartest ways to protect your users, your organization, and your peace of mind as you build out secure forms, enable robust encryption, and manage PHI with the care it deserves.

TLS/HSTS and secure headers

TLS/HSTS and Secure Headers

When building a HIPAA website, the security of data in transit is non-negotiable. Transport Layer Security (TLS) is the gold standard for encrypting information sent between a user’s browser and your server. Without TLS, all data—including PHI submitted via secure forms—is exposed to interception and tampering. For HIPAA compliance, your website must enforce TLS on every page, not just those that collect sensitive data.

But TLS alone isn’t enough. HTTP Strict Transport Security (HSTS) is a critical layer that tells browsers to always interact with your site using secure connections. By enabling HSTS, you help prevent downgrade attacks and accidental exposure via unsecured (HTTP) requests. This ensures that even if someone types your address without “https://”, their browser will force a secure connection—protecting PHI every time.

• Enforce TLS 1.2 or higher: Older versions are vulnerable. Your server configuration should block outdated protocols and ciphers.
• Enable HSTS with a long max-age: Set the Strict-Transport-Security header to at least 6 months. Consider the “includeSubDomains” and “preload” directives for maximum coverage.
• Regularly test your HTTPS configuration: Tools like SSL Labs’ SSL Server Test can identify weak spots in your setup.

Beyond encryption, secure HTTP headers add essential protections. They help defend against a range of web attacks—including cross-site scripting and clickjacking—that could otherwise compromise PHI or other sensitive data.

• Content Security Policy (CSP): The CSP header prevents browsers from running malicious scripts. This is especially important on a HIPAA website, where injected code could leak PHI. Only allow scripts and resources from trusted domains.
• X-Frame-Options: This header blocks your site from being loaded in frames, stopping clickjacking attempts.
• X-Content-Type-Options: Setting this to “nosniff” prevents browsers from interpreting files as a different MIME type, reducing attack surface.
• Referrer-Policy: Control what information is sent to third-party sites to avoid accidental exposure of sensitive URLs.

Implementing these headers is straightforward on most BAA hosting platforms or with WordPress hardening plugins, making it easy to layer in defense without sacrificing usability. If you use third-party providers, ensure they support full header customization; not all hosts do.

Finally, logging should never capture PHI in URL parameters, headers, or body content. Secure headers can help minimize accidental leaks by restricting browser behavior, but it’s up to us to review server and application logs for compliance, especially when using tracking pixels or analytics tools. De-identification and careful configuration are your best friends here.

By prioritizing strong TLS, HSTS, and secure headers, we lay the groundwork for a truly secure HIPAA website—one that safeguards patient trust and meets every regulatory demand.

Forms and PHI handling

Forms and PHI Handling

Every form on your HIPAA website acts as a direct gateway for Protected Health Information (PHI)—and that means every detail must be locked down from the moment a user types it in. If patients are sharing sensitive details, requesting appointments, or submitting insurance data, you need more than just secure forms; you need a full strategy for PHI protection from input to storage.

Let’s break down the essential requirements for keeping PHI safe via web forms:

• Use Secure Forms with End-to-End Encryption. All forms that collect PHI must use strong encryption both in transit and at rest. This starts with enabling TLS (Transport Layer Security) on your entire website, not just select pages. TLS ensures that information entered into forms is unreadable to anyone intercepting network traffic. Make sure your hosting is truly BAA hosting—your hosting provider must sign a Business Associate Agreement (BAA) to guarantee HIPAA-level security standards.
• Enforce Browser Security Policies. Use HTTP security headers like HSTS (HTTP Strict Transport Security) to force browsers to interact only over secure HTTPS connections. CSP (Content Security Policy) headers should be implemented to minimize the risk of malicious scripts or data leaks through cross-site scripting attacks. These measures reduce opportunities for PHI to be intercepted or manipulated.
• Limit Third-Party Integrations and Trackers. Many web platforms, including WordPress, can load third-party scripts or tracking pixels. Never include tracking pixels on form pages that handle PHI, as these can inadvertently transmit patient information to third parties—this is a common source of accidental HIPAA violations.
• Validate and De-identify When Possible. Only collect the minimum necessary information in your forms. Where practical, implement de-identification techniques so that personal identifiers are stripped from datasets used for analytics or testing. This way, even if data is exposed, it can’t be traced back to an individual.
• Secure Email Transmission. If your forms send PHI via email, these messages must be encrypted. Technologies like S/MIME (Secure/Multipurpose Internet Mail Extensions) allow for robust end-to-end email encryption, but both sender and recipient must be configured to use it. Never rely on standard email for PHI unless encryption is in place.
• Implement Comprehensive Logging. Every access or submission of PHI should be logged securely. Logging is critical for auditing and breach detection, but logs themselves must be protected and never expose PHI. Use access controls and regular reviews to monitor who is viewing or exporting sensitive data.
• Harden Your CMS and Plugins. If you’re using WordPress, invest time in WordPress hardening. This means keeping plugins and themes updated, removing unused components, and using only HIPAA-compliant, well-maintained plugins for forms and file uploads. Restrict admin access, enforce strong passwords, and consider additional security plugins that align with HIPAA requirements.
• Work Only with HIPAA-Compliant Vendors. Every vendor or service that touches PHI—from form builders to cloud storage—must sign a BAA and follow strict HIPAA protocols. This includes form plugins, secure file storage, and even email delivery providers.

In summary, handling PHI through website forms isn’t just about encryption—it’s about creating a seamless chain of trust and accountability for every piece of patient data. By following these best practices, we can confidently build forms that not only meet HIPAA requirements but also give patients the confidence that their health information is treated with the utmost care and security.

Email transmission and S/MIME

Email transmission is one of the biggest risk areas when it comes to protecting PHI on a HIPAA website. While web forms and data storage often get the most attention, it’s easy to overlook that every message you send containing PHI must be secured—especially if it leaves your internal network. Failing to secure email transmissions can lead to unauthorized exposure, data theft, or compliance penalties.

Standard email by itself is not secure. By default, email messages travel across the internet in plain text, making them vulnerable to interception. That’s why HIPAA requires covered entities and their business associates to ensure that all electronic PHI (ePHI) is encrypted whenever it's transmitted outside a secure firewall.

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a widely recognized solution to this problem. S/MIME uses robust encryption and digital signatures to protect email content:

• Encryption ensures that only the intended recipient can read the email content—even if the message is intercepted in transit.
• Digital signatures verify the sender’s identity and confirm that the email hasn’t been tampered with.

With S/MIME, your organization can lock down email transmissions containing PHI, satisfying a core HIPAA requirement for secure communications. Setting up S/MIME typically involves issuing digital certificates to all staff who send or receive sensitive information. Many popular email platforms (like Outlook and Gmail for Workspace) support S/MIME, but you’ll need to configure them correctly and ensure certificates are managed securely.

Practical steps for HIPAA-compliant email transmission:

• Enable S/MIME or another form of end-to-end encryption for any system that sends PHI by email.
• Train staff to recognize when to use secure email versus standard email—never send PHI through unencrypted channels.
• Work with BAA hosting providers or secure email vendors who will sign a Business Associate Agreement (BAA) and can demonstrate HIPAA-compliant practices.
• Log all email transmissions containing PHI and regularly review logs for unauthorized access attempts.
• Establish policies for handling misdirected emails and breaches, including rapid de-identification procedures if PHI is exposed.

Remember, it’s not enough to rely solely on TLS (Transport Layer Security) for email in transit. While TLS does encrypt the connection between mail servers, it doesn’t prevent exposure if the recipient’s server doesn’t support encryption—or if PHI is accessed after arrival. That’s why S/MIME, with its message-level encryption and authentication, is the gold standard for HIPAA-compliant email.

Taking these steps ensures that your HIPAA website isn’t just secure on the front end, but also protects sensitive data as it travels through every digital channel—including email. Prioritizing S/MIME and robust email policies shows your commitment to patient privacy and shields your organization from unnecessary risk.

Access control and logging

Access control and logging are at the heart of HIPAA compliance for any website that handles Protected Health Information (PHI). These measures ensure that only the right people can access sensitive data, and that every interaction is tracked and auditable in case something goes wrong. Let’s break down what you need to know.

Access control starts with the principle of least privilege: only users who absolutely need access to PHI for their job functions should be able to see or handle it. This isn’t just a best practice—it’s a fundamental HIPAA requirement. For your HIPAA website, this means:

• Role-based permissions: Assign roles (like admin, healthcare provider, or patient) that define exactly what each user can see and do within your system.
• Unique user identification: Every user must have a unique login. Shared accounts are a red flag for auditors and a real security risk.
• Strong authentication: Require complex passwords, and wherever possible, implement multi-factor authentication (MFA) to add another layer of protection.
• Session management: Sessions should automatically timeout after periods of inactivity to prevent unauthorized access from unattended devices.
• Regular review: Periodically audit who has access to what, and promptly revoke access for users who no longer need it.

Logging complements access control by keeping a detailed record of who did what, when, and how. If there’s ever a breach or even a simple mistake, comprehensive logs help you understand what happened and take corrective action. Here’s what robust logging looks like on a HIPAA website:

• Comprehensive event logging: Log every access, modification, or deletion of PHI. This includes successful and failed login attempts, changes to user permissions, and data exports.
• Centralized and secure storage: Store logs in a secure, tamper-evident location—never in the same database as your primary PHI.
• Automated alerts: Set up alerts for suspicious activities, such as repeated failed logins or attempts to access data outside a user’s role.
• Retention policies: Keep logs for the period required by HIPAA (typically six years), and ensure they’re available for audits or investigations.
• Regular log reviews: Schedule routine checks of your logs to spot patterns or anomalies early, before they turn into problems.

Don’t forget about your technology stack: If you use WordPress, invest in WordPress hardening plugins or features that restrict dashboard access, monitor user activity, and prevent unauthorized plugin installations. For added security, combine access control with technologies like TLS for encrypted communication, Content Security Policy (CSP) to block malicious scripts, and strong logging to create an airtight audit trail.

By rigorously controlling access and keeping thorough logs, you’re not just checking a HIPAA box—you’re building a culture of accountability and trust. This approach protects your patients, your team, and your organization from unnecessary risk, making your HIPAA website a safe place for sensitive health data.

CMS hardening and updates

CMS hardening and updates are critical steps in protecting your HIPAA website from evolving cyber threats. Content Management Systems (CMS) like WordPress, Drupal, or Joomla are highly popular—but that makes them frequent targets for attackers. If your website processes or stores PHI, every vulnerability in your CMS becomes a potential risk to sensitive data and your compliance status.

Start with strict update routines. Outdated core CMS files, plugins, and themes are among the leading causes of breaches. We recommend setting up automated updates for your CMS wherever possible. For plugins or themes where automatic updates aren’t available, establish a regular schedule to manually check and apply updates. Prioritize those that address security flaws or vulnerabilities.

WordPress hardening is especially important. For those using WordPress, follow best practices such as:

• Disabling file editing within the dashboard to prevent unauthorized code changes.
• Using strong, unique passwords for all user accounts and enforcing multi-factor authentication (MFA).
• Limiting login attempts and monitoring suspicious login activity.
• Installing only trusted, actively maintained plugins or themes—never use software from unverified sources.
• Setting strict user roles and permissions, granting access to PHI or admin functions only when necessary.
• Regularly backing up your website and storing backups securely, following de-identification guidelines for any PHI in backups.

Secure your administrative access. Restrict the CMS admin panel to specific IP addresses or secure VPNs, and always require TLS (HTTPS) for all logins and dashboards. Consider adding HTTP security headers, like HSTS and CSP, to prevent clickjacking and other attacks that can lead to unauthorized access or data loss.

Logging is your safety net. Maintain detailed audit logs for all CMS changes—plugin updates, user access, and content edits. Store logs securely and review them regularly for signs of suspicious activity. Remember, HIPAA requires you to be able to detect, respond to, and mitigate breaches swiftly.

Remove what you don’t need. Uninstall unused plugins, themes, and users. The less attack surface your website presents, the lower the risk of compromise. Each unnecessary component is a potential vector for an attacker and unnecessary exposure for PHI.

Don’t overlook secure forms and tracking pixels. Make sure all data collection forms are protected with strong encryption (TLS) and that any tracking pixels or analytics scripts do not transmit PHI or identifying data to third parties. Review and minimize the use of third-party scripts, and ensure any vendor handling PHI signs a BAA (Business Associate Agreement) and meets HIPAA requirements.

Stay proactive, not just reactive. Regular vulnerability scans and security assessments can help uncover weaknesses before they’re exploited. Combine these technical safeguards with ongoing staff awareness to keep your HIPAA website—and your patients’ trust—secure.

Third-party scripts/pixels

Third-party scripts and tracking pixels present a significant risk to HIPAA compliance, often flying under the radar during website development. These scripts—like analytics trackers, advertising pixels, chatbots, or social media embeds—routinely collect user data and transmit it offsite, sometimes without your direct control or visibility. If your HIPAA website handles Protected Health Information (PHI), even the smallest data leak through third-party code can trigger a breach and hefty penalties.

Why are tracking pixels and scripts a problem? These technologies are designed to capture detailed user interactions, IP addresses, device details, and sometimes form submissions. If any of this data is or could be tied to PHI—even indirectly—it falls under HIPAA regulation. For example, a scheduling form that uses a third-party script to “improve UX” could inadvertently transmit appointment details (and thus PHI) to a non-compliant server outside your control.

• No BAA, No Go: Any third-party service that interacts with PHI must sign a Business Associate Agreement (BAA). Most analytics, ad networks, and tracking platforms do not offer BAAs—meaning they cannot be used on HIPAA-compliant websites.
• De-identification is Not Automatic: Some believe stripping names is enough, but unless data is fully de-identified according to HIPAA standards, it’s still protected. Tracking pixels rarely anonymize data to this degree.
• Security Headers Help, But Aren’t a Solution: Content Security Policy (CSP) and HTTP Strict Transport Security (HSTS) can restrict unauthorized scripts, but they don’t stop intentional use of non-compliant third parties.

How can we stay compliant? The safest approach is to eliminate unnecessary third-party scripts and tracking pixels from your HIPAA website. For essential functionality, use only vendors who provide BAA hosting and verify their compliance. Always document your evaluation process and keep logs of what scripts are in use for ongoing auditing. If analytics are required, look for privacy-first platforms willing to sign a BAA and configure them to avoid capturing any identifiers or PHI.

• Audit Regularly: Review your website’s codebase and plugins—especially on platforms like WordPress, where hidden tracking scripts may be bundled by default. WordPress hardening practices can help minimize plugin risks.
• Secure All Forms: Ensure secure forms are never intercepted by unauthorized third-party scripts. Use TLS (SSL) for all data in transit, and consider S/MIME for secure email notifications.
• Log Access and Changes: Keep detailed logging of what code is deployed, who made changes, and when scripts or pixels are added or removed.

In summary, third-party scripts and tracking pixels are a leading cause of accidental HIPAA violations. By removing non-essential scripts, using only compliant vendors, and thoroughly hardening your website, you protect both patient privacy and your organization from unnecessary risk.

Patient portal vs marketing site

When it comes to HIPAA compliance, the difference between a patient portal and a marketing site is critical. Many organizations overlook this distinction, but understanding it can save you from costly compliance mistakes and help you design the right safeguards for your HIPAA website.

Patient portals are interactive platforms where patients can access, transmit, or upload their personal health information. These sites allow users to request appointments, view lab results, message providers, or complete secure forms with sensitive data. Because patient portals handle PHI, they must comply fully with HIPAA standards. This includes everything from using BAA hosting providers to implementing encryption with TLS, enforcing HSTS, and deploying stringent security headers like CSP. Advanced measures such as S/MIME for secure messaging, robust logging for audit trails, and even WordPress hardening (if you use WordPress) are all required to close any gaps where data could leak or be exposed.

In contrast, marketing sites typically serve to provide information about your organization, share blog posts, or promote services—without collecting or displaying PHI. If your marketing site only contains general content and does not process patient-specific information, HIPAA compliance requirements are minimal. However, the moment you add a feature like a contact or appointment form that asks for health details, the site crosses into the HIPAA-regulated territory and must be secured accordingly.

• For patient portals: You must use secure forms, encrypt all data in transit (TLS), deploy HSTS and CSP, ensure de-identification where possible, maintain detailed logging, and negotiate Business Associate Agreements (BAAs) with all vendors, including your hosting provider.
• For marketing sites: Focus on minimizing the collection of PHI. Avoid unnecessary tracking pixels or analytics tools that could inadvertently capture user health data. If you need user insights, ensure all data is de-identified to protect privacy.

The line between these two types of sites can blur, especially as marketing features and patient interactions overlap. That’s why it’s essential to regularly review your site’s functionality and data flow. Even something as simple as a newsletter signup form could trigger HIPAA obligations if it requests health information. Always err on the side of caution: treat any feature that might collect PHI with the same rigor as your patient portal.

By clearly defining the purpose of each part of your website, you’ll be able to confidently apply the appropriate technical and administrative controls—keeping your organization compliant and patient trust intact.

Retention and deletion policies

Retention and deletion policies are a fundamental pillar of HIPAA website compliance, ensuring PHI is retained only as long as necessary and securely disposed of when no longer required. Without clear, enforceable rules on how long data is stored—and how it’s deleted—you risk both accidental data exposure and non-compliance penalties. Let’s break down what you need to know and do to get this right.

Why is this important? HIPAA’s Privacy and Security Rules require that you keep PHI only for the minimum time needed for its intended use. Holding onto data longer than necessary increases the risk of a breach, and failing to securely delete it can lead to costly violations. Your retention and deletion policies must be both proactive and precise, especially if you use BAA hosting, secure forms, or logging platforms.

• Define clear retention periods: Document how long each type of PHI will be stored on your HIPAA website. This period should comply with federal and state laws, as well as your organization’s operational needs. For instance, medical records may need to be kept for several years, while contact form submissions via secure forms might only require a short retention period.
• Automate secure deletion: Manual deletion opens the door to human error. Instead, configure your CMS or web application—such as through WordPress hardening plugins—to automatically purge PHI after the retention period ends. Ensure that deleted data is unrecoverable, using secure deletion methods recommended by NIST or similar standards.
• Include all storage locations: Don’t overlook places where PHI might linger, like backups, logs, or even tracking pixels used for analytics. If any logs contain de-identified or identifiable PHI, set clear policies for how they’re rotated and securely deleted. Work with your BAA hosting provider to ensure their backup and deletion protocols align with your requirements.
• Secure deletion applies everywhere: Whether PHI is stored in databases, file systems, email (via S/MIME), or logs, all must be covered by your deletion policy. Ensure your team is trained to never export or store PHI outside secured, HIPAA-compliant environments.
• Document and enforce: Put your retention and deletion policies in writing, including who is responsible for oversight. Regularly review your policy to ensure it remains up-to-date with new regulations, technologies (such as HSTS and CSP for enhanced security), and your organization’s evolving needs.

Practical tip: Use de-identification whenever possible. If you need to retain data for analytics or research, remove all identifying details so it’s no longer PHI, minimizing compliance burdens and risk.

By building robust retention and deletion policies into your HIPAA website, you’re not just ticking a compliance box—you’re actively reducing exposure and showing your patients that you take their privacy seriously. If you need help, BAA hosting providers often offer tools and templates to streamline this process, so don’t hesitate to lean on their expertise.

Creating a HIPAA compliant website is a commitment to both patient privacy and regulatory responsibility. By choosing robust BAA hosting, enabling secure forms, and ensuring all data transmission uses modern TLS, you’re building critical layers of protection for sensitive health information. It doesn’t stop there—implementing HSTS and CSP keeps your site resilient against cyber threats, while S/MIME email encryption and detailed logging give you full oversight and control over PHI.

Let’s not forget about the tools behind the scenes. WordPress hardening measures, careful tracking pixel management, and smart de-identification techniques all work together to minimize risk and demonstrate a proactive compliance stance. Every step you take—from securing entry points to monitoring behind-the-scenes activity—strengthens your defense against breaches and fines.

The path to HIPAA compliance may feel complex, but you’re not alone. With the right technology, ongoing staff training, and a willingness to adapt, your organization can confidently meet every HIPAA website requirement. Stay vigilant, review your practices regularly, and remember: protecting your patients’ data is protecting your reputation and future.

FAQs

Can we use Google Analytics or pixels?

Using Google Analytics or tracking pixels on a HIPAA website is a risky move if your site handles Protected Health Information (PHI) or any data that could be linked back to individual patients. These tools often send data to third-party servers, and unless you have a signed Business Associate Agreement (BAA) with the analytics provider—which Google does not offer for its standard Analytics service—you can't guarantee compliance. This means that any PHI, even if it’s collected through secure forms or logged behind the scenes, could be exposed.

HIPAA compliance requires strict safeguards like TLS for encrypted connections, HSTS to enforce secure HTTPS, CSP to control what scripts run, and robust logging practices. Allowing tracking pixels without de-identification risks sharing sensitive information without the appropriate controls. Even with WordPress hardening or secure BAA hosting, tracking pixels can bypass these protections if not managed properly.

If you must track user behavior, always de-identify the data before it leaves your site. Strip out all PHI and ensure no information can be linked back to an individual. It's smart to audit any third-party scripts, disable unnecessary pixels, and review your consent banners so users know exactly what data is being shared. Ultimately, when it comes to HIPAA websites, privacy should always come before marketing insights.

Do contact forms collect PHI by default?

No, contact forms do not collect Protected Health Information (PHI) by default. The collection of PHI depends on what information users are asked to provide and what data they actually submit. For example, a simple contact form that only requests a name and a general inquiry may not involve PHI. However, if the form asks for or allows entry of health details, diagnoses, insurance numbers, or any information that can identify a patient in relation to their health, then it is considered collecting PHI.

If your HIPAA website uses contact forms for patient communication or appointment requests, you must treat those forms as potential PHI collectors. In this case, implementing secure forms is crucial. This includes using TLS encryption to protect data in transit, enforcing HSTS policies to prevent protocol downgrade attacks, and applying CSP (Content Security Policy) headers to block unauthorized scripts.

Remember, even the possibility of collecting PHI requires you to follow HIPAA safeguards. This includes hosting your site on BAA hosting providers, using WordPress hardening techniques if applicable, careful logging practices, and reviewing the use of tracking pixels or analytics tools that might inadvertently capture sensitive data.

For added protection, consider de-identification strategies for any data stored or transmitted, and if you’re sharing information via email, use S/MIME for secure communications. Ultimately, always evaluate your forms and data flows to ensure full compliance and patient privacy.

Is WordPress compatible with HIPAA?

WordPress itself is not inherently HIPAA compliant out of the box, but it can be used as a foundation for a HIPAA website if the right technical and administrative safeguards are implemented. Since HIPAA focuses on protecting Protected Health Information (PHI), any website that collects, stores, or transmits PHI—including those built on WordPress—must address strict requirements. This means you'll need to pay careful attention to how data is handled, stored, and transmitted.

Achieving HIPAA compliance with WordPress requires specialized BAA hosting (a host willing to sign a Business Associate Agreement), robust server security, and the use of secure forms protected by end-to-end TLS encryption. Additional security layers like HSTS and CSP headers further strengthen data protection, while S/MIME can be used to secure email communications. Logging access to PHI and implementing rigorous WordPress hardening practices—such as disabling unused plugins, enforcing strong authentication, and keeping everything updated—are also critical steps.

It's important to note that most popular WordPress plugins (such as contact forms or analytics tools) are not HIPAA compliant by default. You must ensure any plugins or third-party tools used for handling PHI are secure, avoid tracking pixels that could expose user data, and prioritize de-identification of personal information wherever possible.

In summary: WordPress can support a HIPAA website, but it demands a highly secure, thoughtfully configured environment using secure forms, advanced encryption, BAA hosting, and comprehensive privacy controls. If you're considering this route, be ready to invest in technical expertise and ongoing compliance management.

Do we need a separate patient portal?

Whether you need a separate patient portal depends on how your organization collects and manages Protected Health Information (PHI) through your HIPAA website. If your website only provides general information and does not handle PHI—such as names, health records, or appointment details—you likely do not need a distinct patient portal. However, if you collect, store, or transmit PHI online (for example, through appointment booking or secure forms), having a dedicated, secure patient portal is essential for compliance.

A separate patient portal offers key security advantages. It allows you to implement advanced protections like TLS encryption, HSTS, and CSP to keep PHI safe. You can also enable S/MIME for secure email communication, maintain detailed logging for audit purposes, and harden your WordPress or hosting environment. Most importantly, BAA hosting providers typically require a clear separation between public content and PHI-related functions to ensure all HIPAA safeguards are in place.

Using a dedicated patient portal makes it easier to enforce privacy controls and limit access to sensitive data. This approach also streamlines de-identification processes, minimizes the risk of exposing data through tracking pixels, and helps your team follow best practices for compliance and risk management.

In summary, if your HIPAA website interacts with PHI in any way, a separate, secure patient portal is not just best practice—it’s often a requirement to meet compliance standards and protect patient trust.