三审合规法检查清单：等保2.0/PCI DSS/HIPAA 合规审计的 30 个关键控制点
企业开展合规审计时，经常面临一个现实问题：等保 2.0、PCI DSS 和 HIPAA 的条款体系不同，但在日志采集、身份追溯、权限控制和异常响应等方面存在大量共同要求。如果分别准备三套检查清单，不仅增加审计工作量，也容易遗漏跨系统的控制缺口。
三审合规法提供了一种统一的检查思路：从设备、身份、行为三个层级梳理控制要求，把不同标准中的相似审计动作归并为可验证的控制点。
本文整理了 30 个关键控制点，覆盖日志审计、账号治理、异常检测和整改闭环。它是一份供企业 IT、信息安全及合规团队使用的自评清单，而非产品功能清单。具体条款适用性及最终合规结论，应以适用标准的正式文本和测评要求为准。
一、如何理解三审合规法与关键控制点？
▌三审合规法
三审合规法以"设备可审、身份可溯、行为可判"为三个递进层级，组织日志审计及相关安全控制点，帮助企业从资产记录、操作主体到异常处置建立完整的审计链条。
▌关键控制点
关键控制点是合规审计中需要逐项核验的具体要求。每项都应对应可验证的证据，如配置、日志、审批记录或审计报告，而不能仅以制度文件或口头说明代替。
二、三层审计框架分别检查什么？
设备层解决"有没有记录"，身份层解决"记录能否对应到具体主体"，行为层则检查"异常能否被识别并得到处理"。三层相互叠加，不能用某一层的完整性替代其他层的控制。
| 层级 | 回答的问题 | 主要审计对象 | 典型证据来源 |
|---|---|---|---|
| 设备层 | 日志全不全、真不真？ | 主机、网络、数据库、云平台 | 日志、留存策略、时间配置 |
| 身份层 | 谁操作、权限是否合理？ | 用户、管理员、服务账号、外包人员 | 账号清单、授权记录、认证日志 |
| 行为层 | 行为是否异常、是否响应？ | 高危操作、异常访问、数据活动 | 告警、调查记录、工单、复盘报告 |
三、设备层：如何检查日志采集与留存是否合规？
设备层是日志审计的基础。审计人员需要从资产清单出发，逐项核对日志是否启用、是否完整、是否可信，并确认发生安全事件后能否还原过程。
| 控制点 | 对应标准 | 审计方法 | 常见缺口 | 工具覆盖提示 |
|---|---|---|---|---|
| 控制点1：日志采集覆盖面 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 将关键资产清单与实际日志源逐项比对，抽查日志是否持续产生。 | 新增系统、边缘设备或业务应用未纳入采集。 | 日志审计/SIEM平台可集中采集与核对日志，但资产识别和接入责任仍需明确。 |
| 控制点2：日志留存时长 | 等保2.0 8.1.4.3；PCI DSS Req.10.5 | 检查留存策略、归档记录及历史日志能否调取。等保相关要求通常至少留存6个月；PCI DSS Req.10.5.1要求审计日志历史至少保留12个月，其中最近3个月应能立即用于分析。 | 存储容量不足、归档不可读或历史记录提前删除。 | 日志平台、归档存储和备份机制共同承担留存任务。 |
| 控制点3：日志完整性与防篡改 | 等保2.0 8.1.4.3；PCI DSS Req.10.3 | 检查访问权限、删除权限、完整性校验及日志变更记录。 | 管理员可以直接删除日志，且没有独立留存副本。 | 防篡改存储、权限隔离及日志审计平台可协同提供保护。 |
| 控制点4：时间同步 | PCI DSS Req.10.6；等保2.0 8.1.4.3 | 核查关键系统的时间源、同步配置及偏差监测记录。 | 服务器时间不一致，跨系统事件无法准确排序。 | NTP等时间同步服务与日志平台时间校验共同发挥作用。 |
| 控制点5：网络设备日志 | 等保2.0 8.1.4.3；PCI DSS Req.10 | 抽查防火墙、交换机、VPN等设备的登录、策略变更和访问拒绝日志。 | 只记录流量，不记录管理操作或策略变更。 | 网络设备原生日志、集中日志采集及SIEM分析。 |
| 控制点6：主机操作系统日志 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 检查Windows、Linux等系统的登录、权限变更、服务启停及审计配置。 | 关键审计策略未启用，或日志轮转导致证据丢失。 | 主机审计代理、系统原生日志及日志管理平台。 |
| 控制点7：数据库审计日志 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 抽查数据库登录、敏感数据访问、权限变更及高危SQL操作记录。 | 只记录数据库故障，无法追溯数据查询和修改主体。 | 数据库原生审计、数据库活动监控及SIEM。PCI DSS要求按实际环境确保相关访问可被记录，不意味着所有场景都必须重复采集同一事件。 |
| 控制点8：应用业务系统日志 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 检查业务登录、数据查询、审批、导出和失败操作是否留痕。 | 应用只记录技术错误，没有业务操作主体和对象信息。 | 应用审计模块、业务日志接口及日志分析平台。 |
| 控制点9：云平台与虚拟化日志 | 等保2.0 8.1.4.3；PCI DSS Req.10 | 核对云控制台登录、权限调整、实例创建、网络策略变更等记录。 | 仅采集虚拟机内部日志，遗漏云控制面操作。 | 云原生日志服务、云安全工具及SIEM集成。 |
| 控制点10：变更与配置日志 | 等保2.0 8.1.4.3；PCI DSS Req.10 | 抽查系统配置、审计策略、安全规则变更记录，并与变更单核对。 | 配置发生变化，却没有对应审批或操作记录。 | 配置管理、变更管理、文件完整性监控与日志审计平台。 |
四、身份层：如何核验账号、权限与操作主体？
设备层证明事件发生过，身份层则要进一步证明事件由谁执行、是否获得授权。对于共享账号、外包访问和离职账号，应重点核验实际使用人与授权记录是否能够对应。
| 控制点 | 对应标准 | 审计方法 | 常见缺口 | 工具覆盖提示 |
|---|---|---|---|---|
| 控制点11：身份鉴别唯一性 | 等保2.0 8.1.4.1；PCI DSS Req.8；HIPAA §164.312(a)(2)(i) | 抽查用户账号与操作日志，确认能否关联到唯一身份。 | 多人共用管理员账号，无法区分实际操作者。 | IAM、目录服务及认证系统；日志平台负责关联身份与事件。 |
| 控制点12：账号生命周期 | 等保2.0 8.1.4.1；PCI DSS Req.8；HIPAA §164.308 | 抽查入职、转岗、离职记录与账号创建、变更、停用时间。 | 账号创建缺少审批，离职账号长期未清理。 | IAM/IGA、AD管理工具及人力资源流程集成。 |
| 控制点13：权限最小化 | 等保2.0 8.1.4.2；PCI DSS Req.7；HIPAA §164.312(a) | 对照岗位职责、授权审批及实际权限，检查超范围访问。 | 用户长期保留历史岗位权限，权限复核流于形式。 | IAM/IGA、访问控制系统及定期权限审查流程。 |
| 控制点14：特权账号管理 | 等保2.0 8.1.4.1、8.1.4.2、8.1.4.3；PCI DSS Req.7、8、10 | 核对管理员账号清单、授权审批、密码轮换、会话记录及操作审计。 | 特权账号共享、密码长期不变，操作无法归责。 | PAM特权访问管理平台、密码保险柜和会话审计工具。 |
| 控制点15：多因素认证 | 等保2.0 8.1.4.1；PCI DSS Req.8 | 检查适用系统的MFA策略、覆盖范围及认证失败记录。 | 只对部分入口启用MFA，管理入口或远程访问存在例外。 | 独立MFA/身份认证模块。日志平台可以记录认证事件，但不能代替认证机制。 |
| 控制点16：异常登录检测 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 抽查异地、异常时段、连续失败及异常设备登录事件。 | 日志已记录失败登录，却无人分析或处置。 | SIEM、UEBA与身份风险分析工具。 |
| 控制点17：目录集成与身份关联 | 等保2.0 8.1.4.1、8.1.4.2；PCI DSS Req.8 | 抽查AD、业务系统与云身份之间的账号映射及同步记录。 | 同一员工在不同系统使用不同账号，审计记录无法串联。 | 目录服务、IAM/IGA、AD管理工具及日志身份关联能力。 |
| 控制点18：账号锁定与失败处理 | 等保2.0 8.1.4.1；PCI DSS Req.8、10 | 检查失败登录阈值、锁定策略、解锁审批和相关日志。 | 失败次数没有限制，或异常解锁缺少记录。 | 身份认证系统、目录策略及SIEM告警。 |
| 控制点19：第三方外包访问 | 等保2.0 8.1.4.1、8.1.4.2；PCI DSS Req.7、8；HIPAA §164.308 | 核查外包人员名单、合同授权、访问期限、审批和会话记录。 | 项目结束后账号仍有效，供应商使用共享凭据。 | IAM、PAM、远程访问控制及第三方风险管理流程。 |
| 控制点20：离职权限清理 | 等保2.0 8.1.4.2；PCI DSS Req.8；HIPAA §164.308 | 将离职名单与各系统有效账号、令牌、密钥及远程访问权限交叉核验。 | 只禁用域账号，遗漏本地账号、云账号和应用独立账号。 | IAM/IGA、AD管理工具及自动化离职流程。 |
五、行为层：如何发现异常并形成审计闭环？
行为层不是简单地积累更多日志，而是判断事件是否偏离正常业务，并验证组织是否采取了适当措施。告警数量、规则数量都不能替代实际检测效果和处置证据。
| 控制点 | 对应标准 | 审计方法 | 常见缺口 | 工具覆盖提示 |
|---|---|---|---|---|
| 控制点21：行为基线 | PCI DSS Req.10.4；HIPAA §164.312(b) | 检查是否建立正常登录、访问频率和操作模式基线，并定期复核。 | 只有静态规则，没有结合业务变化调整基线。 | SIEM、UEBA及业务风险分析。 |
| 控制点22：横向移动检测 | 等保2.0 8.1.4.3；PCI DSS Req.10、11 | 检查异常远程登录、凭据滥用、跨主机访问等事件是否可关联。 | 单机日志正常，但跨主机行为异常未被识别。 | SIEM、EDR、网络检测与身份分析工具。 |
| 控制点23：数据外泄检测 | 等保2.0 8.1.4.8、8.1.4.11；PCI DSS Req.10；HIPAA §164.312(b)、(e) | 抽查异常批量下载、敏感数据导出及非授权传输事件。 | 只记录文件访问，缺少数据流向和传输行为监测。 | DLP、数据库审计、网络流量分析及SIEM。日志告警不能替代数据防泄漏控制。 |
| 控制点24：批量高危操作监控 | 等保2.0 8.1.4.3；PCI DSS Req.10 | 检查批量删除、权限提升、日志停用和敏感数据修改是否触发告警。 | 高危操作与普通操作采用相同监控策略。 | SIEM、PAM、数据库审计及文件完整性监控。 |
| 控制点25：时间异常识别 | PCI DSS Req.10.6；等保2.0 8.1.4.3 | 检查非工作时段操作、时间戳异常及时间同步故障告警。 | 仅统一时间，不监控异常时段的高风险行为。 | SIEM规则、行为分析及时间同步监控。 |
| 控制点26：告警分级与降噪 | 等保2.0 8.1.4.3；PCI DSS Req.10.4 | 抽查告警分级规则、误报复核、升级机制及处置时限。 | 告警过多导致关键事件被淹没，或高危事件无人跟进。 | SIEM、UEBA与告警管理机制。 |
| 控制点27：跨域关联分析 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 选取典型事件，验证能否串联身份认证、主机、网络和应用日志。 | 各系统独立留存日志，调查仍依赖人工逐台查询。 | SIEM关联分析、统一身份映射及数据集成。 |
| 控制点28：响应闭环 | 等保2.0 8.1.4.3；PCI DSS Req.10.4、12；HIPAA §164.308 | 抽查告警、工单、调查结论、处置记录和复盘材料是否关联。 | 告警已生成，但没有责任人、处理结果或关闭依据。 | SIEM、SOAR、工单系统及事件响应制度。 |
| 控制点29：合规报表生成 | 等保2.0 8.1.4.3；PCI DSS Req.10；HIPAA §164.312(b) | 检查报表是否覆盖适用控制点，核对样本数据、统计口径及生成时间。 | 报表模板看似完整，但底层日志缺失或统计范围不全。 | 日志审计/SIEM平台可提供报表与证据汇总，但仍需人工核验。 |
| 控制点30：持续复审机制 | 等保2.0 8.1.4.3；PCI DSS Req.12；HIPAA §164.308 | 检查是否定期复核资产范围、审计策略、权限、告警效果及整改进度。 | 仅在测评前集中补材料，日常控制未持续运行。 | GRC、工单和配置管理工具可辅助跟踪；制度执行与管理责任不能由软件替代。 |
六、等保、PCI DSS 与 HIPAA 的控制点如何交叉映射？
三套标准的关注重点有所不同，但并非彼此割裂。以下矩阵用于确定自评入口，不代表某一标准只适用于指定层级。
| 标准 | 主要关注层级 | 本清单控制点 |
|---|---|---|
| 等保 2.0 三级 | 设备层、身份层，并覆盖行为层 | 1–30，重点核查 1–20 |
| PCI DSS v4.0 | 设备层、行为层，并覆盖身份层 | 1–30，重点核查 1–10、21–28 |
| HIPAA 安全规则 | 身份层、行为层，并覆盖设备层 | 1–30，重点核查 11–30 |
这份清单将多个标准共同要求的审计动作去重后归纳为 30 项。实际审计时，仍应保留每项控制点与具体标准条款之间的映射关系，避免去重后遗漏某一标准独有的要求。
两条需要特别关注的原文要求
等保 2.0 三级 GB/T 22239‑2019 第 8.1.4.3 条关注审计记录的内容，包括事件日期和时间、用户、事件类型、事件是否成功，以及其他与审计相关的信息。
这意味着"可追溯"必须落实到记录字段和实际日志，而不能只提供一份审计制度。具体适用条款及原文应以正式标准文本为准。
PCI DSS v4.0 Requirement 10.1 要求定义并记录对系统组件及持卡人数据的访问日志记录与监控机制。
PCI DSS 日志审计需要结合 Req. 10 的具体子要求，核验记录覆盖、保护、审查、时间同步及留存等事项。官方 PCI SSC 对 Req. 10 的说明强调，审计轨迹应支持还原相关访问和操作。
HIPAA §164.312(b) 则要求采用硬件、软件和/或程序机制，记录并检查包含或使用电子受保护健康信息（ePHI）的信息系统活动。该要求并未指定必须采购某一种产品。
七、30 个控制点分别需要哪些工具共同满足？
需要明确：没有任何单一产品能够独立覆盖全部 30 个控制点。合规要求是组织需要达到的控制目标，工具只是实现和验证这些目标的手段之一。
设备层 1–10 主要依靠日志审计/SIEM、原生审计功能、存储与时间同步机制。以卓豪 ManageEngine 卓豪EventLog Analyzer为例，它可作为日志采集、集中留存、关联分析和合规报表方面的工具选项之一，但实际覆盖范围取决于日志源、配置、许可和部署情况。
身份层 11–13、17–20 通常需要 IAM/IGA、目录服务或 AD 管理工具，处理账号生命周期、目录关联和权限管理。ADManager Plus 可作为 AD 账号管理场景的工具示例。控制点 14 涉及特权账号、凭据保险柜和会话审计，通常需要 PAM 平台，例如 PAM360；控制点 15 的多因素认证则需要相应的认证模块。
行为层 21–28 主要由 SIEM、UEBA、EDR、DLP 及事件响应流程共同支撑。ELA 等日志分析平台可承担部分行为分析、关联告警和证据汇总工作；数据外泄防护、终端检测和自动化响应仍可能需要其他技术域。控制点 29 可借助合规报表工具，控制点 30 则必须依靠持续治理、责任分工和复审机制。
因此，进行日志审计平台选型时，应先盘点现有技术和流程的覆盖情况，再确定缺口。不要把"能生成报表"直接等同于"已满足控制要求"，也不要因为某个平台覆盖部分控制点，就推断其可以包办整套合规。
八、如何使用这份合规审计检查清单开展自评？
建议按照以下三步执行：
- 逐项定级： 对 30 个控制点分别标记"已满足""部分满足"或"存在缺口"，并记录证据位置。
- 汇总差距： 按设备、身份、行为三层统计缺口，识别影响范围大、风险较高的控制问题。
- 形成整改计划： 为缺口指定责任人、整改期限、验证方式和复查记录，整改完成后重新取证。
自评的价值不在于得到一个简单分数，而在于明确哪些控制已经有效运行、哪些只有制度没有证据、哪些仍需补齐技术或流程。自评不能替代正式测评、审计或认证程序，最终结论由相应测评机构或审计方依据适用要求作出。
常见问题（FAQs）
- 三审合规法30控制点自评，一定要全部打勾才算合规吗？
不需要全部打勾。自评目的是识别缺口，结合风险做风险处置、补偿控制；部分控制点可通过流程制度补偿技术缺口，最终以正式测评机构判定为准。
- 已经部署SIEM/日志平台，是不是就完成设备层全部控制点？
不是。工具只是承载手段，资产梳理、日志接入完整性、防篡改、NTP时间同步、归档可读，大量是管理流程工作，平台上线不等于控制落地。
- 国内企业做等保测评，是否需要完全对标PCI‑DSS、HIPAA全部条款？
不需要。本清单是抽取共同审计动作做自评；国内企业以GB/T22239‑2019等保要求为主，PCI‑DSS适用于处理银行卡数据、HIPAA适用于涉及美国受保护健康信息业务。
