一家医疗初创公司在2023年初给我打了电话。创始人不错，预算充足，简报清晰：患者就诊表单、预约调度，也许以后还会加入远程医疗小工具。"我们用的是WP Engine，"CTO告诉我。我问WP Engine是否已签署他们的BAA。长时间的沉默。"BAA是什么？"
问题就在这里，不在代码里，不在插件栈里，而在于大多数开发者从不阅读、大多数主机商悄悄回避的书面文件中。
关键是：HIPAA合规性不是你可以切换的功能。它是一个法律框架，而业务伙伴协议是使你的托管提供商成为该框架正式部分的合同。如果没有签署的BAA，即使你的服务器运行TLS 1.3，你已加密数据库中的每个字段，也没关系。你仍然有风险。你的客户也是。
让我讲讲我对哪些平台将在2026年签署的实际了解，更重要的是，哪些平台说得好听但不会真正签字。
---
BAA 实际是什么（以及不是什么）
业务合作协议（BAA）是HIPAA隐私规则下的一份合同，将供应商与保护健康信息（PHI）相关的特定义务绑定在一起。当你托管医疗网站时，你的主机商接触PHI，即使只是在基础设施层面。这使他们成为业务合作方。就这么简单。
BAA不会自动使你达到合规要求。我经常看到这一点被误解。BAA意味着主机商接受他们的责任份额并同意采取保障措施。你的应用层、表单、WordPress插件、日志记录，这些还是你的责任。
Seahawk 在 2022 年有一个项目是为一个美国的物理治疗组织运营一个 WordPress 网站。客户与他们的电子邮件提供商签订了 BAA（很好），与 EHR 供应商签订了 BAA（显然），但与网络主机没有签订任何协议。他们的网站通过 Gravity Forms 收集症状数据。每个提交都被发送到 Gmail 账户。一个工作流中的三个独立违规。我们花了大约六周时间才理清这一切。
---
2026 年实际会签署的主机商
AWS、GCP和Azure：真正的选择
如果你需要BAA并且需要确定性，超大规模云提供商就是你的答案。这三个，Amazon Web Services、Google Cloud Platform和Microsoft Azure，都提供BAA并维护符合HIPAA条件的服务清单。
AWS 是我最常选择的。BAA 涵盖了一系列扎实的服务：EC2、RDS、S3、CloudFront、Lambda 等等。至关重要的是，并非每个 AWS 服务都符合条件。DynamoDB 在列表中；并非所有实验性服务都在。在你进行任何架构设计之前，你必须查看当前的合格服务页面。
GCP的BAA涵盖BigQuery、Cloud SQL、Compute Engine和Cloud Storage等服务。Azure在医疗保健领域拥有最广泛的企业采用率，其BAA和合规文档已经成熟，如果你的客户已经在Microsoft生态系统中（大多数企业医疗机构都是这样），Azure往往在组织层面上更有意义。
这三个的问题是：你得不到托管WordPress。你得到的是基础设施。需要有人来构建和维护栈、操作系统补丁、WAF配置、备份、静态加密和传输中加密。在Seahawk，我们为医疗客户使用了AWS，运行Nginx、PHP-FPM和MySQL的加固EC2实例。这可行。不过，这比直接给某人WP Engine的登录凭证要多得多的运营开销。
Kinsta：情况下的赞成
Kinsta 运行在 GCP 上。他们为更高级别计划（Business 1 及以上，最后一次检查时如此）的客户提供 BAA 签署。这很重要，因为 Kinsta 确实是一流的托管型 WordPress 主机。快速。可靠。很好的测试环境。
但是，这一点值得强调，Kinsta 的 BAA 覆盖范围比直接使用 GCP 要窄一些。你既要依赖 Kinsta 的内部控制，也要依赖 GCP 的。对于许多医疗保健 WordPress 项目来说，这没问题。但如果涉及大量非常敏感的数据，我会想在承诺之前准确了解他们的安全文档说了什么。
Cloudways，否
Cloudways 在代理商圈子里很受欢迎。性价比不错。我们在几十个非敏感项目上用过。但根据我最后的了解，Cloudways 不提供 HIPAA BAA。他们甚至运行在底层的 AWS 和 GCP 上，这有点讽刺。托管层引入了不确定性，他们不会为 HIPAA 目的在合同上为此担责。
Pantheon，否（大多数计划）
Pantheon 对 Drupal 和 WordPress 代理商来说非常优秀。HIPAA 合规不是他们的市场。他们已经把这说得很清楚了。别被企业级的品牌宣传迷惑了。
WP Engine，否
我知道。他们有合规文档。他们谈论安全。他们不会签署 HIPAA BAA。他们的服务条款明确禁止在他们的平台上存储 PHI。这使其不符合任何真正的医疗保健用例资格。我在这篇文章开头提到的那个初创公司？这正是他们所处的情况。
Liquid Web / Nexcess，可能，有限制条件
Liquid Web 提供过符合 HIPAA 的托管主机服务，附带 BAA 签署，通常是在他们的专用服务器或 VPS 产品上而不是共享计划。值得直接与他们的销售团队交谈。他们的合规态势已经改善。但在我构建任何东西之前，我想先拿到 BAA。
---
你的 WordPress 堆栈在 BAA 之外需要什么
BAA 是基础，不是建筑本身。以下是在应用层对符合 HIPAA 要求的 WordPress 站点实际需要发生的事情。
表单和数据收集
- Gravity Forms在正确设置下可以使用,但原生的Gravity Forms默认在WordPress数据库中存储提交。对于PHI,你要么需要禁用数据库存储并将数据安全地传送到HIPAA合规的目标地址,要么仔细使用他们的加密字段附加组件。
- Cognito Forms和FormAssembly都提供带BAA的HIPAA合规版本。如果表单是主要的数据收集点,这些通常比费力处理GF要干净得多。
- 永远不要使用免费的联系表单插件，这些插件在没有检查其合规态势的情况下将数据发送到第三方服务器。
电子邮件
这一点会害死人。你的 WordPress 网站可能通过 wp_mail() 发送电子邮件，它默认使用 PHP mail 或连接的 SMTP 插件。标准 Gmail、标准 Mailchimp、标准 SendGrid，这些都不会在入门级套餐上签署 HIPAA BAA。
Paubox 是我一直推荐给中小型医疗保健客户的。HIPAA 合规电子邮件，包含 BAA，定价直白。Google Workspace 也为其医疗保健客户提供 BAA，但需要特定的计划和正式的申请流程，不适用于标准 Google 账户。
插件和第三方集成
每个会向外联系的插件、每个分析脚本、每个实时聊天小工具，取决于页面上的数据，都可能涉及 PHI。进行适当的审计。我使用 Query Monitor 来识别哪些是在发出外部请求，然后参照每个供应商的合规文档交叉检查。
HubSpot会签署BAA。Intercom不会（在标准套餐中）。Hotjar在没有经过非常仔细的范围界定的情况下，几乎肯定不应该在医疗保健网站上运行。
---
如何实际获得签署的BAA
这比较偏向程序性而非技术性，但我见过项目在这里停滞。
- 识别每个接触或可能接触 PHI 的供应商：主机、CDN、电子邮件、表单、分析、支持聊天、备份提供商。
- 向每个供应商的销售或合规团队请求BAA文档。不要假设。要求书面文件。
- 审查范围，一个仅涵盖特定服务或特定数据类型的 BAA 需要在你签署之前理解清楚。
- 将签署的协议存储在你的客户法律团队可以访问的地方。不仅仅是在你的收件箱中。
- 每年重新审查。供应商会改变政策，服务会被弃用，你在2024年签署的BAA可能在2026年就有漏洞了。
HHS关于业务合作伙伴的指导实际上是可读的。如果你是新手,值得花三十分钟阅读。
---
没人谈论的CDN问题
你已经搞定了主机。你有了BAA。你锁定了应用层。然后你在它前面放上了Cloudflare。
Cloudflare会签署BAA，但仅限于企业计划，起价会让大多数小型医疗客户望而却步。免费和Pro层级？没有BAA。这意味着Cloudflare实际上是在没有BAA的情况下解密和检查你的HTTPS流量，而你的网站上可能有PHI在传输中。
对于较小的项目，我通过使用AWS CloudFront（符合BAA条件）作为CDN层来解决这个问题，当网站已经在EC2上或在应用负载均衡器后面时。这不如Cloudflare仪表板那么花哨，但从合规的角度来说是干净的。
---
我在2026年真正会做的事
如果一个医疗客户明天找我提出WordPress需求，大致上我会这样架构：
- 主机：AWS EC2（带有签署的 BAA）运行强化的 LEMP 栈，或者 Kinsta Business 并拿到他们的 BAA
- 邮件：Paubox 用于交易和提供商相关的电子邮件
- 表单：FormAssembly 或 Gravity Forms，禁用数据库存储并使用加密提交路由
- CDN：AWS CloudFront，而不是 Cloudflare 免费/专业版
- 分析：在同一个BAA覆盖的基础设施上自主托管Matomo，任何URL或参数中可能包含PHI的地方都不要用Google Analytics。
- 备份：AWS S3（符合 BAA 资格）并支持服务器端加密
比标准 WordPress 构建更昂贵吗？是的。在运营上更复杂吗？也是的。但另一种选择是客户面临 HIPAA 违规通知流程、从每次违规每天 100 美元起的潜在罚款，以及关于为什么开发人员从未提及任何这些的一次非常尴尬的谈话。
---
常见问题
"符合HIPAA的托管"在法律上有意义吗?
没有。这是一个市场营销用语。有法律意义的是签署的BAA(业务关联协议)。任何主机提供商都可以称自己为HIPAA就绪、HIPAA友好或HIPAA某某。没有BAA，这些词语只是装饰性的。始终明确询问："你们会与我们签署业务关联协议吗?"
如果我的网站只有一个联系表单，还需要BAA吗?
如果联系表单收集可能构成PHI的信息——症状、诊断、预约原因、任何与患者身份和健康状况相关的内容——那么这个数据链中的每个供应商都应该有BAA。仅收集姓名、电话和偏好时间的通用"预约"表单属于灰色地带，但我仍然建议获得BAA。
我可以使用WordPress.com做医疗保健网站吗?
WordPress.com(托管平台，不是自托管的WordPress软件)不提供HIPAA BAA。句号。这不同于在符合要求的基础设施上运行的自托管WordPress。软件本身没问题。托管平台不适合PHI。
如果我正在使用的供应商被收购，新所有者取消了BAA，会怎样?
这是真实风险，我见过小型SaaS工具发生这种情况。你的BAA应该包含终止条款，在供应商不再能满足HIPAA义务时触发。收到收购公告邮件时，别直接删除，要检查新实体是否维持合规承诺。
HIPAA只是美国的问题吗?
没错，HIPAA是美国联邦法律。但如果你为英国或欧盟医疗客户开发，NHS Digital标准、《数据安全和保护工具包》以及适用于卫生数据的GDPR有类似的数据处理协议要求。框架不同，逻辑一样。
---
大多数开发者,如果诚实的话,在有人问起之前根本不会想到 BAA。到那时要么你幸运地没问题,要么你在紧张的客户催促下仓促地改造整个技术栈。
最好在项目开始前就了解这些要求,而不是在开发到一半时才发现你的主机商拒绝签署那份真正重要的文件。
相关阅读：2026年无头与WordPress安全性对比：为什么选择Next.js和Astro、Next.js及无头架构。