HIPAA 合规性检查清单 2026：网站、SaaS 和软件
如果你正在构建涉及健康数据的软件——无论是远程医疗平台、患者门户、健康追踪 SaaS，甚至是医疗保健提供商的营销网站——HIPAA 合规性并非可选项。到 2026 年，规则变得更加严格。
2026 年 HIPAA 安全规则最终规则消除了许多团队依赖的灵活性空间。MFA 现在是必需的，而不是可寻址的。静态加密和传输中加密现在是必需的，而不是可寻址的。如果你的合规态势是基于针对这两项的文档化例外，那么该态势已不再适用。
我花费多年时间构建 HIPAA 合规的网络应用程序，我发现团队最常犯的错误是将合规性视为文书工作。实际上并非如此。这是一个具有法律后果的工程问题。本检查清单是从这个角度编写的——少一些法律术语，多一些针对开发人员、CTO 和产品负责人的实际实施指导，他们需要交付合规软件。
目录
- 理解三大 HIPAA 核心规则
- 谁需要合规：涵盖实体与业务伙伴
- 2026 年安全规则最终规则：发生了什么变化
- 隐私规则检查清单：网站和 SaaS
- 安全规则检查清单：行政保障措施
- 安全规则检查清单：物理保障措施
- 安全规则检查清单：技术保障措施
- 违规通知规则检查清单
- 大多数团队遗漏的网站特定 HIPAA 问题
- HIPAA 合规性对比：云提供商
- 文档和审计就绪状态
- 常见问题
理解三大 HIPAA 核心规则
HIPAA 将合规义务组织成不同的规则。对于软件和网络团队来说，其中三个规则最为重要：
隐私规则
隐私规则管理受保护健康信息 (PHI) 如何使用和披露。PHI 是与可识别个人相关的任何健康信息——医疗记录、实验室结果、保险详情、预约日期，甚至与健康数据一起收集的 IP 地址。
关键要求：
- 隐私惯例通知必须发布且易于访问
- "最小必要" 标准适用：只访问和共享你实际需要的 PHI
- 患者有权访问、修改和请求其 PHI 披露的会计
- 用于治疗、支付和医疗保健运营之外用途的授权是必需的
安全规则
安全规则专门保护电子 PHI (ePHI)。它要求三类保障措施：行政、物理和技术。对于 SaaS 和网络应用，技术保障措施是大部分工程工作进行的地方——访问控制、审计日志、加密、完整性控制和传输安全。
安全规则映射到 45 CFR 第 164 部分，每项保障措施都有特定部分：访问控制 (164.312(a))、审计控制 (164.312(b))、完整性控制 (164.312(c))、身份验证 (164.312(d)) 和传输安全 (164.312(e))。
违规通知规则
当未受保护的 PHI 被暴露时，你必须通知受影响的个人、HHS，有时还要通知媒体。时钟从发现违规的那一刻开始滴答——而不是完成调查的时候。下面有更多具体的时间表。
还有执法规则管理 OCR 如何调查和处罚违规行为，但上述三个规则是你的合规计划的核心。
谁需要合规：涵盖实体与业务伙伴
这是很多 SaaS 团队感到困惑的地方。你不需要成为医院才能受 HIPAA 约束。
涵盖实体是以电子方式传输健康信息的健康计划、医疗保健信息交换所和医疗保健提供者。
业务伙伴是代表涵盖实体创建、接收、维护或传输 PHI 的供应商。如果你的 SaaS 产品为医疗保健客户端处理健康数据，你就是业务伙伴。句号。
自 HIPAA Omnibus 规则以来，业务伙伴承担直接合规义务。你不能躲在客户的合规计划后面。你需要自己的。
这意味着：
- 你必须与每个提供服务的涵盖实体签署业务伙伴协议 (BAA)
- 你必须与自己的子处理器（AWS、GCP、你的数据库提供商、你的电子邮件服务）签署 BAA
- 你必须独立实施安全规则保障措施
- 你直接受 OCR 执法约束
2026 年安全规则最终规则：发生了什么变化
原始安全规则 (2003) 将实施规范分为 "必需" 和 "可寻址"。必需意味着你必须这样做。可寻址意味着你必须实施它、文档化为什么使用了等效措施，或文档化为什么不合理。实际上，许多组织将 "可寻址" 视为 "可选的"。
2026 年最终规则消除了两个关键领域的这种模糊性：
| 控制 | 前期状态 | 2026 年状态 | 影响 |
|---|---|---|---|
| 多因素认证 | 可寻址 | 必需 | 所有访问 ePHI 的系统必须强制执行 MFA。无例外。 |
| 静态加密 | 可寻址 | 必需 | 所有 ePHI 存储必须加密。不再接受补偿控制。 |
| 传输加密 | 可寻址 | 必需 | 所有 ePHI 传输必须加密。TLS 1.2 最低版本。 |
| 风险分析 | 必需 | 必需（扩展） | 必须连续进行，而非每年一次。预期自动监控。 |
| 审计日志 | 必需 | 必需（扩展） | 日志必须不可变且根据文档化政策保留。 |
如果你一直依赖 MFA 或加密的文档化例外，你需要立即进行补救。根据更新的规则，该态势不再是防守。
隐私规则检查清单：网站和 SaaS
这是网站特别容易犯错的地方。你的医疗保健产品营销网站有许多网络团队没有考虑到的隐私规则义务。
- 发布隐私惯例通知 (NPP) — 必须在你的网站上显著易访问。不要埋在页脚链接迷宫中。
- 实施最小必要标准 — 你的表单应仅收集你实际需要的 PHI。那份 15 字段的摄入表单？审核每个字段。
- 履行患者访问请求 — 如果你的软件存储 PHI，你必须为患者提供一种方式在 30 天内访问其记录。
- 实施授权工作流 — 用于治疗/支付/运营之外的任何 PHI 使用都需要显式患者授权。
- 跟踪披露 — 维护至少六年来每次 PHI 披露的会计。
- 培训你的工作人员 — 每个接触 PHI 的人都需要隐私规则培训。文档化它。
- 指定隐私官 — 有人必须负责这件事。它可以是共享角色，但必须文档化。
- 审查第三方追踪 — 这是网站的大问题。Google Analytics、Meta Pixel、HubSpot 追踪——如果这些工具能够捕获 PHI（它们经常可以），你就有隐私规则问题。
安全规则检查清单：行政保障措施
行政保障措施是管理你的安全计划的政策和程序。它们通常是合规中最不吸引人的部分，但这是 OCR 在调查期间首先查看的内容。
- 进行风险分析 — 不是一次性练习。2026 年规则预期进行连续风险评估。映射每个接触 ePHI 的系统，识别威胁，评估漏洞，并文档化你的风险级别。
- 实施风险管理计划 — 对于确定的每项风险，文档化你如何缓解它。接受的风险必须用理由正式文档化。
- 分配安全官 — 有人拥有安全计划。文档化谁。
- 实施工作人员访问控制 — 基于角色的访问政策。谁可以访问什么 ePHI 以及为什么。
- 进行安全意识培训 — 最少每年，但每季度更好。文档化出席。
- 实施处罚政策 — 当有人违反政策时会发生什么？文档化它。
- 审查信息系统活动 — 定期审查审计日志。不仅仅收集它们——实际审查它们。
- 制定应急计划 — 数据备份、灾难恢复、应急操作。至少每年测试一次。
- 评估 BAA — 审查所有业务伙伴协议。每个接触 ePHI 的供应商都需要一个。
安全规则检查清单：物理保障措施
对于在云基础设施上运行的 SaaS 团队，物理保障措施大多转移到你的云提供商——但你仍然有义务。
- 设施访问控制 — 如果你有 ePHI 可访问的办公室，控制物理访问。徽章读卡器、访问者日志、锁定的服务器房间。
- 工作站安全 — 由访问生产 ePHI 的开发人员使用的笔记本电脑必须具有完全磁盘加密、屏幕锁定政策和远程擦除能力。
- 设备和媒体控制 — 处置存储 ePHI 的硬件的政策。文档化销毁方法。
- 云提供商验证 — 验证你的云提供商的物理安全认证。AWS、GCP 和 Azure 都发布涵盖物理控制的 SOC 2 报告——请求并审查它们。
安全规则检查清单：技术保障措施
这是工程团队花费大部分工作的地方。每项保障措施都映射到可测试的控制。
访问控制 (164.312(a))
- 唯一用户标识 — 每个用户获得唯一 ID。不共享账户。永不。
- 应急访问程序 — 在紧急情况下访问 ePHI 的文档化过程。
- 自动注销 — 所有访问 ePHI 的系统上的会话超时。15 分钟是合理的默认值。
- 加密和解密 — ePHI 必须在静态时加密。AES-256 是标准。
# 示例：验证 AWS RDS 上的静态加密
import boto3
def check_rds_encryption():
rds = boto3.client('rds')
instances = rds.describe_db_instances()
for db in instances['DBInstances']:
if not db['StorageEncrypted']:
print(f"WARNING: {db['DBInstanceIdentifier']} is NOT encrypted")
# 根据 2026 年规则，这现在是合规违规
else:
print(f"OK: {db['DBInstanceIdentifier']} encrypted with {db['KmsKeyId']}")
审计控制 (164.312(b))
- 记录所有 ePHI 访问 — 每次读取、写入、更新和删除。
- 使日志不可变 — 使用仅追加存储。CloudWatch Logs 带保留政策，或发送到不可变 SIEM。
- 根据政策保留日志 — 六年是匹配 HIPAA 一般保留要求的安全默认值。
- 自动化日志审查 — 为异常访问模式设置警报。开发人员在凌晨 3 点查询 10,000 条患者记录应该触发警报。
// 示例：用于 ePHI 访问日志记录的 Express 中间件
const logPhiAccess = (req, res, next) => {
const logEntry = {
timestamp: new Date().toISOString(),
userId: req.user?.id,
action: req.method,
resource: req.originalUrl,
sourceIp: req.ip,
userAgent: req.get('User-Agent'),
// 不要在审计日志中记录实际 PHI
resourceType: 'ePHI',
};
// 发送到不可变日志存储
auditLogger.write(logEntry);
next();
};
app.use('/api/patients/*', logPhiAccess);
完整性控制 (164.312(c))
- 实施机制验证 ePHI 未被改变 — 校验和、数字签名或数据库级完整性控制。
- 防止未授权修改 — 写入访问应严格限制。
身份验证 (164.312(d))
- 验证访问 ePHI 的任何人的身份 — 需要强身份验证。
- 实施 MFA — 现在在 2026 年规则下强制执行。TOTP、硬件密钥或基于推送的 MFA。基于短信的 MFA 技术上合规但不推荐，由于 SIM 交换风险。
传输安全 (164.312(e))
- 在传输中加密 ePHI — TLS 1.2 最低版本。TLS 1.3 首选。
- 强制处处使用 HTTPS — 无混合内容。需要 HSTS 头。
- 保护 API 通信 — 所有传输 ePHI 的 API 调用必须使用加密通道。相互 TLS 用于服务间通信是强大的模式。
# Nginx 配置强制执行 TLS 1.2+ 和 HSTS
server {
listen 443 ssl http2;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff always;
add_header X-Frame-Options DENY always;
}
违规通知规则检查清单
违规是任何未经许可使用或披露，危害 PHI 的安全或隐私的行为。以下是违规发生之前你需要到位的内容——因为如果你在事件期间构建它，你已经落后了。
- 定义你的事件响应计划 — 发现违规时谁做什么？文档化角色、升级路径和通信模板。
- 建立 60 天通知窗口 — 受影响的个人必须在发现违规后的 60 天内收到通知。不是从它发生时起 60 天——从你知道它时起 60 天。
- 通知 HHS — 如果 500 多个个人受影响，请与个人通知同时通知 HHS。对于影响少于 500 个个人的违规，你可以每年报告一次（但不要延迟调查）。
- 通知媒体 — 影响单个州或司法管辖区 500 多个个人的违规需要媒体通知。
- 文档化风险评估 — 对于每一起潜在违规，进行四因素风险评估：涉及的 PHI 的性质和范围、访问它的未授权人员、PHI 是否被实际获取或查看、风险缓解程度。
- 了解加密安全港 — 如果被泄露的数据使用 NIST 标准加密加密且密钥未被泄露，它可能不构成需要通知的违规。这是到处使用加密的最强论点之一。
- 进行桌面演练 — 至少每年运行一次违规模拟。计时你的团队的响应。识别差距。
大多数团队遗漏的网站特定 HIPAA 问题
这是我希望有人五年前为我写过的部分。网站有后端工程师不总是考虑的 HIPAA 曝光点。
第三方追踪和分析
2022 年 12 月，HHS 发布指导，澄清医疗保健网站上的追踪技术可能造成 HIPAA 违规。这还没有改变——它变得更加严格。如果你的医疗保健网站使用 Google Analytics、Meta Pixel 或类似工具，而这些工具可以捕获 PHI（包括与健康相关页面访问结合的 IP 地址），你可能在未经 BAA 的情况下向第三方传输 PHI。
怎么办：
- 审核网站上运行的每个第三方脚本
- 从收集或显示健康信息的页面中删除追踪像素
- 尽可能使用服务器端分析
- 如果你必须使用客户端分析，请确保将其配置为排除 PHI
- 考虑隐私友好的替代方案，如 Plausible 或 Fathom，它们不收集 PII
客户端 JavaScript 和供应链风险
每个 npm 包、每个 CDN 托管脚本、每个聊天小部件都是 ePHI 曝光的潜在向量。被泄露的第三方脚本可以将表单数据——包括 PHI——渗漏到攻击者的服务器。
- 实施内容安全政策 (CSP) 头
- 对 CDN 托管资产使用子资源完整性 (SRI)
- 定期审核客户端依赖项
- 监控你的软件物料清单 (SBOM)
表单处理
联系表单、预约请求表单、症状检查器——如果它们收集健康信息，它们就在处理 PHI。
- 在传输中加密表单提交 (HTTPS)
- 不以纯文本存储表单数据
- 不以未加密方式通过电子邮件发送表单内容
- 实施 CAPTCHA 以防止自动 PHI 提取
- 设置适当的数据保留政策——不要永远保留表单提交
如果你使用无头 CMS 架构，请确保你的表单处理管道从开始到结束是 HIPAA 合规的。在 Social Animal，我们构建无头 CMS 解决方案，这些安全要求从一开始就烤入其中，而不是事后附加。
HIPAA 合规性对比：云提供商
你的基础设施选择很重要。以下是主要云提供商在 2026 年 HIPAA 工作负载方面的排名：
| 功能 | AWS | Google Cloud | Azure | Vercel | Netlify |
|---|---|---|---|---|---|
| 提供 BAA | 是 | 是 | 是 | 是（企业） | 否 |
| 文档化 HIPAA 合格服务 | 150+ | 100+ | 130+ | 有限 | N/A |
| 默认静态加密 | 是（大多数服务） | 是 | 是 | 部分 | N/A |
| HITRUST CSF 认证 | 是 | 是 | 是 | 否 | 否 |
| 专门的合规文档 | 广泛 | 广泛 | 广泛 | 最小 | N/A |
| FedRAMP 授权 | 是（GovCloud） | 是 | 是（Gov） | 否 | 否 |
**关于静态托管平台的关键说明：**如果你正在部署处理 ePHI 的 Next.js 或 Astro 网站，要小心选择托管。Vercel 在企业计划中会签署 BAA，但你需要验证哪些特定服务被覆盖。Netlify 目前不提供 BAA，使其不适合 HIPAA 工作负载。
对于使用 Next.js 或 Astro 等框架构建的团队，你早期做出的架构决策——数据在何处处理、哪些 API 处理 PHI、服务器端渲染如何与客户端状态交互——都有 HIPAA 含义。
文档和审计就绪状态
HIPAA 要求你保留文档六年。这包括政策、程序、风险评估、培训记录、BAA 和事件报告。以下是如何在不失去理智的情况下保持审计就绪状态的方式：
- 自动化证据收集 — 使用 Vanta、Drata 或 Secureframe 等工具来连续收集合规证据。手动电子表格无法扩展。
- 版本控制你的政策 — 将合规文档存储在 Git 中。每次更改都使用作者、时间戳和上下文进行跟踪。
- 自动化安全扫描 — 在你的 CI/CD 管道中运行基础设施即代码扫描器（Checkov、tfsec）以在错误配置到达生产之前捕获它们。
- 计划季度访问审查 — 谁有权访问什么？这仍然合适吗？文档化审查。
- 维护生动的风险寄存器 — 你的风险评估不是你每年更新的 PDF。这是一份随着你的基础设施演变而改变的生动文档。
# 示例：用于 HIPAA 安全扫描的 GitHub Actions 步骤
- name: Run Checkov security scan
uses: bridgecrewio/checkov-action@v12
with:
directory: ./terraform
framework: terraform
check: CKV_AWS_17,CKV_AWS_19,CKV_AWS_145 # RDS 加密、S3 加密等
soft_fail: false # 在违规时使管道失败
官方政府 HIPAA 认证不存在。HHS 和 OCR 不颁发认证。如果有人告诉你他们是 "HIPAA 认证的"，问他们实际上是什么意思。第三方框架如 HITRUST CSF 和 SOC 2 Type II 可以向客户展示合规性成熟度，但它们不能取代 OCR 监督或提供安全港。
处罚等级：风险所在
让我们具体说明后果：
| 等级 | 知识水平 | 每次违规处罚 | 年度最大值 |
|---|---|---|---|
| 第 1 级 | 不知道（也不能） | $137 – $68,928 | $2,067,813 |
| 第 2 级 | 合理原因，非故意忽视 | $1,379 – $68,928 | $2,067,813 |
| 第 3 级 | 故意忽视，30 天内纠正 | $13,785 – $68,928 | $2,067,813 |
| 第 4 级 | 故意忽视，未纠正 | $68,928 | $2,067,813 |
处罚金额根据截至 2026 年的通胀进行调整。犯罪处罚可包括高达 10 年监禁，针对以出售 PHI 意图进行的犯罪。
这些不是理论上的。OCR 在执法方面一直很活跃。根据 IBM 数据泄露成本报告，2025 年医疗保健数据泄露的平均成本为 1,093 万美元。合规比替代方案更便宜。
常见问题
如果我们不直接存储健康数据，我的 SaaS 产品是否需要 HIPAA 合规？ 如果你的软件代表涵盖实体创建、接收、维护或传输 PHI，你就是业务伙伴且必须合规。即使只是通过 PHI 而不存储它也会触发合规要求。关键问题是 PHI 是否在任何时点接触你的系统。
是否有我可以获得的官方 HIPAA 认证？ 否。HHS 和 OCR 不发布或认可任何 HIPAA 认证。第三方框架如 HITRUST CSF、SOC 2 Type II 或 ISO 27001 可以向客户和合作伙伴展示你的安全态势，但它们不构成 HIPAA 认证。对声称 "HIPAA 认证" 的任何供应商持怀疑态度。
2026 年必需和可寻址规范之间有什么区别？ 2026 年安全规则最终规则明确要求 MFA 和加密，消除了它们之前的 "可寻址" 状态。对于仍然可寻址的规范，你必须实施规范、实施等效替代方案并文档化为什么，或文档化为什么不合理且适当。"可寻址" 从未意味着 "可选" ——2026 年更新只是对对大部分事项的两项控制做出了不可否认的说明。
我是否需要与我的云托管提供商签署 BAA？ 是的。如果你的云提供商代表你处理、存储或传输 ePHI，你需要 BAA。AWS、Google Cloud 和 Azure 都提供 BAA。确保你仅使用云提供商明确列出为 HIPAA 合格的服务——并非云平台内的所有服务都被覆盖。
我能在医疗保健网站上使用 Google Analytics 吗？ 风险很大。HHS 2022 年的指导（并自此加强）明确指出追踪技术可以将 IP 地址与健康相关页面访问相结合，可能构成向没有 BAA 的第三方传输 PHI。Google 不为 Google Analytics 签署 BAA。服务器端分析或隐私友好的替代方案对医疗保健网站来说更安全。
我需要多频繁进行 HIPAA 风险分析？ 2026 年规则强调连续风险评估而不是定期练习。至少每年进行一次正式风险分析，并在对你的系统、环境或操作有重大更改时进行。许多组织正在转向使用合规平台进行自动化、连续风险监控。
什么被视为 HIPAA 下的违规？ 违规是任何未经许可使用或披露 PHI 危害其安全或隐私的行为。但是，有三个例外：以善意行为的工作人员无意获取、在组织内授权人员之间无意披露，以及你有真诚相信未授权接收方无法保留信息的情况。被泄露的加密数据如果符合 NIST 标准加密且密钥未被泄露，可能获得安全港资格。
发现潜在违规后的前 24 小时我应该做什么？ 激活你的事件响应计划。遏制违规——如果需要隔离受影响的系统。开始记录所有内容：发生了什么、何时发现的、涉及谁、影响了什么数据。开始四因素风险评估。通知你的法律顾问和你的 HIPAA 隐私和安全官。不要等待完全调查后再采取遏制行动。60 天通知时钟从发现时开始，所以每一小时都很重要。
如果你正在构建医疗保健软件，并且需要从第一天开始正确获得架构，我们与工程团队合作设计 HIPAA 合规的网络应用程序。查看我们的开发能力或联系我们讨论你的项目。