4. 自我评估问卷(SAQ)与报告模板
SAQ，说白了就是一张自检清单。PCI DSS 要求商户和服务商每年都要填一次。我自己最早接触 SAQ 时，第一反应是「这不就是打个勾嘛」。结果第一年填完，被 QSA 退回三次，惨痛教训。
嗯，咱们一步步拆开看。SAQ 不是一张表，而是九张表。选错表，等于白填。
常见坑：很多团队以为「我们是小商户，填 SAQ A 就行」。但如果你用第三方支付网关但自己存了卡号，就得填 SAQ D。我见过因此被拒付的案例，整改花了两个月。
4.1 SAQ 的种类与适用场景
PCI 委员会把 SAQ 分成 A、A-EP、B、B-IP、C-VT、C、P2PE、D（商户）和 D（服务商）九种。判断标准很简单：你的支付流程用到了哪些组件？
| SAQ 类型 | 适用场景 | 问题数 |
|---|---|---|
| A | 完全外包给第三方支付，自己既不存也不传卡号 | 22 |
| A-EP | 用第三方支付机构（IFrame/JS），但支付页面在你网站上 | 191 |
| B | 仅使用拨号/独立终端，无电子存储 | 29 |
| B-IP | 仅使用带 IP 连接的独立终端 | 30 |
| C-VT | 仅使用虚拟终端（网页输入卡号） | 33 |
| C | 带支付应用的联网系统，但卡号不存储 | 160 |
| P2PE | 使用经认证的 P2PE 解决方案 | 33 |
| D（商户） | 任何不适用以上类型的商户 | 250 |
| D（服务商） | 服务商（非商户） | 250 |
我建议你每季度至少走一遍这个判断流程。尤其是当你更换支付网关、增加收银渠道或扩展业务时，SAQ 类型可能会变。
4.2 如何正确选择 SAQ 类型
给你一个我常用的三步法：
- 画数据流图——你想想看，卡号从客户输入到最终结算，经过了谁的系统？
- 找存储点——你的服务器、数据库、日志文件里有没有明文卡号或 PAN？
- 看支付组件——终端是独立拨号？带 IP？虚拟终端？还是嵌入的支付按钮？
我的习惯：每张 SAQ 的第一页都有「确定你的 SAQ 类型」流程图。别跳过，老老实实走一遍。我曾经帮一个客户用这个方法发现他们其实属于 SAQ D，而不是 SAQ C-VT。他们初始选择了后者，一旦被抽查，罚款+品牌封禁是跑不掉的。
为什么这么重要？SAQ 选错了，所有答案都无效。审计报告会直接打上「ineligible」红色标记。拿到这种标记，后续要重新填、重新审，浪费整整一个周期。
4.3 填写 SAQ 的常见雷区
我踩过的坑，你们别踩了：
- 「全部通过」陷阱——别为追求数字好看把「否」硬改成「是」。SAQ 允许如实填写「未实施补偿控制」，只要你附上书面计划。
- 「证据缺失」——每条「是」都要有对应证据。我见过一个 SAQ D，答了 210 个「是」，但能拿出证据的不到 100 个。审计员只认证据，不认嘴说。
- 「变更忘记同步」——你换了防火墙品牌、升级了收银软件，SAQ 里的技术细节必须跟着改。有一次我接手一个客户，他们 SAQ 里写的还是五年前的终端型号，明显不符。
避坑指南：我曾经花了一周时间帮客户补全一张 SAQ A-EP 的缺失项。问题出在他们认为「支付页面是第三方提供的，跟我没关系」。但 PCI DSS 要求 你 必须验证你的集成代码没有暴露卡号。那个客户的页面嵌了自定义 JS 去 post 表单，结果 post 的地址里带了完整的 PAN。还好发现得早，再晚一个月就是合规事故。
4.4 报告模板：RoC 与 AOC 的区别
SAQ 填完后，你会得到两个关键文件：
- RoC（Report on Compliance）——详细审计报告。QSA 会逐条描述你怎么满足每个控制项。SAQ 一般不自带 RoC，但 SAQ D 通常会有简化版 RoC 作为附件。
- AOC（Attestation of Compliance）——合规声明书。这是你发给收单行、卡组织看的「合规证明」。SAQ 末尾就自带 AOC 页，签字即可。
举个例子：你自己填 SAQ D，完成后打印 AOC 签个字，扫描发给银行。银行不关心你内部过程，他们只看 AOC。但如果出事，调用的却是 SAQ 原始答案和 RoC。所以 AOC 是「门面」，SAQ 答题是「地基」。
4.5 SAQ 与正式审计的关系
有些朋友问我：「填了 SAQ，是不是就不用被 QSA 查了？」
不一定。取决于你的交易量和商户等级。
- Level 4 商户（年交易 20 万笔以下）——通常 SAQ 足够，但卡组织可能随机抽查。
- Level 2/3 商户——除了 SAQ，部分需要附加渗透测试报告。
- Level 1 （年交易 600 万笔以上）——必须由 QSA 做现场审计，SAQ 只是预检工具。
我过去见过一家年交易 800 万笔的电商，居然只提交了 SAQ D 就以为万事大吉。半年后收到 Visa 的罚款通知——他们根本没意识到自己是 Level 1。所以别只看 SAQ 种类，更要想清楚你的商户等级。
关键提醒：SAQ 不是「填了就行」，而是「填对了、证据齐了、能经得起查验」。一张填错类型的 SAQ，在审计员眼里等于零。每次填完，我都会做一遍交叉检查——随机抽 10 条「是」的项，让安全负责人拿出证据。拿不出来或证据不足的，退回重填。
4.6 SAQ 填写与报告生成流程图
下面这张图能帮你理清 SAQ 的工作流——从选择类型到生成 AOC，再到后续维护。我习惯把这个图贴在项目看板上，每次改流程时更新一次。
这个流程里，最容易被跳过的是「内部交叉检查」那一步。我自己的团队规定：任何人填完 SAQ，必须由另一个不参与业务的人做一次盲审。过程中找不到证据的，一律标黄。标黄超过 5 条，整个 SAQ 退回重审。这个做法帮我们避免了好几次审计翻车。
4.7 一个实际案例：SAQ 选型错误
去年我接手一家餐饮连锁，年交易量约 50 万笔。他们一直用拨号终端，填 SAQ B。后来切换到云端 POS 系统，终端变成带 Wi-Fi 的智能 POS。他们没有改 SAQ 类型，依然填 B。
嗯，你想想看，智能 POS 内部其实是一个 Android 系统，会短暂存储卡号痕迹、能联网、能装第三方应用。按 PCI DSS 要求，这应该归到 SAQ C 甚至 D。他们被 QSA 抽查到，直接判定不合格。
整改过程不复杂，但浪费了三个月的合规窗口期。所以我的建议是：每次更换硬件或软件，第一时间重新判断 SAQ 类型，而不是等年底再更新。
小技巧：在所有支付相关系统的采购需求里加一条约束：「该方案适用的 SAQ 类型必须书面写在技术方案中」。这样不管谁换设备，SAQ 判断都绕不开。
4.8 报告模板的使用细节
SAQ 配套的报告模板（RoC 模板）可以从 PCI 委员会官网下载。但我建议你用最新版本——PCI DSS 4.0 对应的 SAQ 模板已经在 2024 年初更新了。版本号通常写在封面右下角，比如「v4.0.1」。
模板的结构一般这么分：
- 第一部分：商户/服务商信息 + 确认书
- 第二部分：SAQ 问题与答案（逐条）
- 第三部分：补偿控制措施说明（如果有「否」的项）
- 第四部分：AOC 签名页
- 附件：渗透测试报告、扫描报告、策略文档副本
我见过有些团队只填了问题和答案，完全忽略了补偿控制和附件。这种“半成品”SAQ 在银行那边根本过不了——他们会退回要求补全。
4.9 保持合规的节奏
最后聊一个容易被忽视的点：SAQ 的有效期是一年，但你的环境可能几个月就变了。所以我建议你按以下节奏维护：
- 每季度：走一遍 SAQ 选型流程图，检查基础设施是否发生变更。
- 每半年：随机抽 30 条 SAQ 问题，复查证据是否存在、过期。
- 每年：完整填写并提交新的 SAQ + AOC。
这样下来，即使年底突然被抽查，你也不会手忙脚乱。我就用这个节奏帮客户建立了合规台账，效果很好。
请注意：SAQ 不是「一次性冲刺」，而是「持续的马拉松」。一旦提交 AOC，你等于向银行承诺「我的系统全年都符合 PCI DSS」。如果年中出了问题，银行可以追溯你的责任。最好的保护就是持续监控，别等通知来了才着急。