企业采购 SaaS 最耗时的一环是安全问卷。我们把自查清单直接放上官网：7 组 46 项，逐项标注检查什么、当前状态、以及不达标时的整改方向。本文讲清四种状态为什么不能用「达标/不达标」二分、这份清单能证明什么、不能证明什么。
为什么一个 SaaS 平台要把安全清单公开在官网上
企业客户采购 SaaS 时，安全问卷是最耗时的一环。典型流程是：供应商先填一份 200 行的 Excel，客户的安全团队逐条审，来回三轮，耗时两到六周。中间大量时间花在同一批问题上——你有没有 2FA、密码策略是什么、日志保留多久、数据存哪里。
这一环对大客户是刚需，对中小客户是噪音。但我们认为它的存在本身是对的：采购方有义务确认供应商是否可信，而供应商有义务提供可核验的答案。
所以我们把这份清单做成了官网公开页：7 组 46 项，逐项标注检查什么、当前状态、以及不达标时的整改方向。
公开这件事有代价——它把不足也一起暴露了（有些项标注的是“生产部署时执行”或“部分达标”）。但隐藏不足的清单没有价值：客户拿到一份全绿的问卷，第一反应不是放心，而是“这是不是抄的”。
七组是哪七组
清单按 7 个检查组组织，对应等保三级与 500 强采购关注的七个面：
| 组 | 关注什么 | 项数 |
|---|---|---|
| ① 访问控制与认证 | 谁能进系统、怎么证明是他本人 | 8 |
| ② 通信传输与边界 | 数据在路上安不安全 | 5 |
| ③ 数据保护与加密 | 数据落盘后安不安全 | 7 |
| ④ 审计与运营 | 出了事能不能查 | 7 |
| ⑤ 应用与内容安全 | 系统本身有没有被攻击面 | 8 |
| ⑥ 隐私与法律合规 | 个人信息处理合不合规 | 7 |
| ⑦ 等保与备案 | 法定资质与备案是否到位 | 4 |
共 46 项。
项数不多，但每项都是可判定的——这是这份清单和常见安全问卷最大的区别。常见问卷里塞着“贵司是否重视信息安全”这类无法判定的问题，除了让人写“是”没有别的用途。我们的每一项都对应一个具体的配置值、一个数据库字段、或者一个代码里存在的机制。
四种状态，而不是「达标 / 不达标」
清单里每个项有四种状态，这个分级是刻意的：
达标。 当前环境已满足。
生产部署时执行。 代码与能力已就位，但需要部署到生产环境或由运营侧完成。这类项的典型例子：HTTPS 强制跳转、数据库 TLS、Redis 口令、算法备案。在测试环境里它们本来就不该是开的，所以标“未达标”会误导；标“达标”又不诚实——正确答案是“能力已具备，执行在生产”。
部分达标。 当前配置没达到建议值，需要按整改指引调整。
未达标。 确实缺。
为什么这个分级重要：如果只有“达标/不达标”两态，一个在测试环境做的自检会得出大量“不达标”，客户会误判为“这个产品安全做得差”；而在生产环境做的自检又可能得出全绿，客户会怀疑真实性。四态是在说清楚“能力”与“部署状态”是两件事。
得分是怎么算的
达标得分 = 已达标项 / 全部 46 项。
这里有个诚实的设计：“生产部署时执行”和“部分达标”都不算达标。也就是说，得分的分母始终是 46，不会因为某一项“能力已具备”就把它排除掉。
这个口径会让我们在某些环境下得分不好看。但把“能力已就位但没部署”算进达标，是在偷换概念——客户关心的是“现在这套系统安全吗”，不是“你们设计上考虑过吗”。
逐组说明：各组到底查什么
以下是各组检查项的类别说明。具体每一项的配置值与判定细节属于安全边界，不在公开页逐条披露——原因很实际：把“我们的会话超时是 480 分钟”这类具体值公开，等于给攻击者提供了一份系统画像。
① 访问控制与认证（8 项）：多因素认证是否可用、密码策略强度、登录失败锁定、会话生命周期、记住登录的设备管理、异常登录识别、活跃会话可见与终止、密码更换周期。
② 通信传输与边界（5 项）：全站 HTTPS、HTTP 到 HTTPS 强制跳转、Cookie 安全属性、安全响应头（HSTS / CSP / X-Frame-Options 类）、数据库连接加密。
③ 数据保护与加密（7 项）：备份加密、密钥轮换机制、凭据字段加密、存储用量快照、数据驻留策略、出境访问管控、缓存服务鉴权。
④ 审计与运营（7 项）：操作日志留存、登录日志、日志保留期限、危险操作二次确认、异常告警、备份可恢复性、队列与任务可观测。
⑤ 应用与内容安全（8 项）：上传文件类型与内容校验、防毒/防投毒检测、SQL 注入与 XSS 防护、CSRF 令牌、越权访问控制（行级归属校验）、敏感词与合规扫描、AI 生成内容标识、SSRF 防护。
⑥ 隐私与法律合规（7 项）：隐私政策与用户协议、Cookie 同意、数据导出（可携带权）、账号注销与数据删除、个人信息处理清单、子处理者披露、跨境传输合规路径。
⑦ 等保与备案（4 项）：等保三级测评材料映射、ICP 备案、算法备案、安全事件响应流程。
这份清单能证明什么、不能证明什么
必须把边界说清楚，否则它就成了另一种营销话术。
能证明的：
- 平台主动检查了这 46 个点，而不是等客户问才想；
- 每一项的判定是可复核的——多数项的依据是配置值、数据库结构或代码里存在的机制，客户的安全团队可以逐条要来证据；
- 状态是如实标注的，包括未达标项和待部署项。
不能证明的：
- 不等于通过了等保三级测评。“按等保要求自查”和“拿到测评报告”是两件事，前者是我们做的，后者需要第三方测评机构出具——我们在等保与备案那一组里如实说明了这个区别。
- 不覆盖客户侧的责任。SaaS 是共担模型：我们负责平台层，客户负责自己的账号、密钥、内容与配置。清单不会替客户回答“你们用了强密码吗”。
- 不是一次性结论。配置会变、新威胁会出现，清单需要定期复核。公开页当前的得分是当前环境的快照。
为什么“自查”这件事本身有价值
有一种观点是：自查不算数，只有第三方审计才算。
这个观点在合规层面是对的（等保测评、ISO 27001 都是第三方），但在工程层面不成立。大多数安全事故不是发生在“没做审计”的公司，而是发生在“没人系统检查过基础项”的公司：忘了开 2FA、日志只留了 7 天、上传只校验了扩展名、越权查询没做行级过滤。
这 46 项里的大部分，都是这类“做了就有效、忘了就出事”的基础项。把它们做成可运行、可复核的检查，比写一份漂亮的制度文档有用得多。
平台的实现方式是：这些检查跑在代码里，不是一份人工维护的表格。数据库结构变了、配置值改了，状态会自动跟着变。这样清单不会随时间和实际状态脱节——这是自制安全问卷最常见的失效方式。
客户可以怎么用这份清单
三种用法，按采购阶段分：
选型阶段：直接打开官网的公开页，看看供应商愿不愿意公开、公开得多细、有没有如实标注不足。愿意公开未达标项的供应商，通常比全绿的更可信。
尽调阶段：把这份清单作为问卷的起点，只针对你的特殊要求补充问题。能省下大量重复问答。
上线后：把清单里的检查项转成你自己的验收项，在正式上线前逐条确认（尤其是“生产部署时执行”那一组——它们在测试环境里本来就是关的，上线时最容易忘）。