系统与环境测评

系统层最重要的问题不是“选哪个”，而是：一个系统可能同时命中几套制度，它们分别验证什么。

四套常见体系

项目	主要触发	对象/范围	主要输出或证据	与其他制度关系
等级保护	按适用制度判断	等级保护对象	定级/备案材料、测评报告、整改证据等	中国网络安全基础制度
商用密码应用安全性评估	法规规定的网络与信息系统	系统中的密码应用	密评报告、整改复测等	不替代等保
关基安全测评	被依法认定为关基	关基及关键业务、资产和依赖	专项测评和整改证据	在基础制度上叠加重点保护
PCI DSS	进入PCI DSS适用范围	CDE及能够影响CDE安全的系统、人员和流程	ROC/SAQ、AOC等适用验证文件	支付卡行业生态要求

具体周期和验证方式以适用法规、监管要求和当期标准版本为准，不用“一年一次”概括所有体系。

我的系统到底要做几个

一个生产系统
 ├─ 属于等级保护对象？ → 等保
 ├─ 命中商用密码应用安全性评估要求？ → 密评
 ├─ 被依法认定为关基？ → 关基重点保护/测评
 └─ 进入PCI DSS范围？ → PCI DSS验证

四个判断分别进行，不能因为做过其中一个就跳过其他适用性判断。

一个核心支付系统如果同时命中四项，可能出现 等保 + 密评 + 关基测评 + PCI DSS。但等保对象边界、关基边界、密评对象和PCI CDE并不天然重合。

怎么减少重复检查

企业不应为四套体系分别建设四套安全能力。更合理的是建立统一控制和证据库：

身份权限 / 网络边界 / 日志监测 / 漏洞 / 密码 / 应急
                       ↓
                 统一控制证据
            ↙       ↓       ↘
          等保      关基      密评      PCI

减少的是重复取证，不是合并法律义务。

验收重点

• 范围是否与真实生产架构一致；
• 云、第三方、远程运维和共享平台是否正确纳入或说明；
• 问题是否进入统一整改闭环；
• 整改是否改变真实配置，而不只是修改制度；
• 重大架构和业务变化是否触发重新判断；
• 报告、AOC/SAQ等证据是否仍对应当前范围。

PCI DSS特别说明

PCI SSC明确，PCI DSS合规验证认可官方表单，例如ROC、AOC、SAQ和ASV相关证明，而不是自行颁发的“PCI DSS证书”。采购或审计时应看正式验证文件及范围，而不是只看certificate。

核验入口与证据

系统类证明优先看完整报告和真实边界，而不是一张“通过”截图。等保、密评、关基分别核对适用测评机构/人员能力、报告对象、依据标准、时间和整改复测；PCI DSS则核对ROC/SAQ/AOC等适用文件及范围。

对于外部供应商提供的系统合规证明，还应确认共享平台、云服务和第三方依赖是否真的包含在报告范围中。

通用验真步骤见安全合规证明怎么验真。

返回总览。