第3章 SAQ评估类型选择：SAQ A‑EP、SAQ D、定制化选择依据

3.1 合规要求拆解

PCI DSS 将自评问卷（SAQ）划分为多种类型，每种对应不同的商户处理环境。选择错误的 SAQ 类型会导致评估范围偏差、控制措施遗漏，在审计中被判定为“不合规”。SAQ A‑EP、SAQ D 与 定制化评估 是三类适用于电子商务/支付 SDK 集成场景的主要选项。下表拆解三类评估对应的 PCI DSS 要求范围：

3.2 风险识别

选择不当的 SAQ 类型会直接引发以下风险：

• 范围过窄风险： 本应使用 SAQ D 却选了 SAQ A‑EP，导致自我评估遗漏关键控制项（如密钥管理、日志审计）。
• 证据失效风险： SAQ 类型与集成方式不匹配，提交的证据（如网络拓扑、数据流图）被 QSA 或收单行驳回。
• 合规 gap 风险： 定制化评估如果没有与 DSS 要求逐条映射，会被视为“未完成评估”。
• 审计处罚风险： 错误选择导致 AOC（合规证明）无效，可能面临罚款、限制交易或品牌清退。

3.3 SAQ A‑EP：适用场景与证据链

场景特征：

• 仅通过自营电商网站接受卡支付；
• 支付处理全部外包给 PCI DSS 认证的第三方（如 Stripe、Adyen）；
• 商户网站包含支付页面元素（支付表单、iframe 或 SDK 组件）；
• 商户不直接存储、处理、传输持卡人数据。

支付 SDK 适配示例（SAQ A‑EP 允许的嵌入方式）：

<!-- 直接嵌入第三方支付 SDK 的卡号采集表单 —— 卡号不经商户服务器 -->
<div id="payment-element">
  <!-- 由 Stripe.js 或 Adyen Web 组件渲染 -->
</div>
<script src="https://js.stripe.com/v3/"></script>
<script>
  const stripe = Stripe('pk_test_xxxxxxxx');
  const elements = stripe.elements();
  const cardElement = elements.create('card');
  cardElement.mount('#payment-element');
</script>

合规证据链要求：

• 已签署的 TPA（第三方协议），证明支付处理外包；
• 第三方当前有效的 PCI DSS AOC 或合规证书；
• 网络拓扑图，标明商户与第三方之间的数据流，并注释“无卡号传输”；
• SAQ A‑EP 自我评估表，逐项勾选并附责任人签署；
• 渗透测试报告（至少每 12 个月一次），覆盖电商网站前端；
• 季度 ASV 扫描报告，证明网站无高风险漏洞。

3.4 SAQ D：适用场景与证据链

场景特征：

• 商户存储、处理或传输持卡人数据（即使通过 SDK 中转但经商户服务器）；
• 使用支付 SDK 的自定义路由模式，商户服务器参与验证或转发请求；
• 不符合 SAQ A‑EP、SAQ A 或 SAQ B‑IP 的其他所有商户。

支付 SDK 适配警示（触发 SAQ D 的集成方式）：

// 危险模式：商户服务器中转卡号 —— 必须使用 SAQ D
app.post('/api/payment', async (req, res) => {
  const cardNumber = req.body.cardNumber;          // ❌ 商户收到明文卡号
  const  = await thirdParty.tokenize(cardNumber);
  // 即使后续丢弃，该行为已使商户进入 SAQ D 范围
});

合规证据链要求：

• 完整的数据流图和卡数据存储清单；
• 持卡人数据发现扫描报告；
• 密钥管理策略与密钥访问日志；
• 系统组件清单（CMDB）与 CDE 边界定义；
• 年度渗透测试报告（覆盖 CDE 内部）；
• 安全日志（至少保留 12 个月），含防火墙、WAF、数据库审计日志；
• 员工安全培训记录与 PCI DSS 意识考核。

3.5 定制化选择依据

触发条件（满足任意一项即可启动）：

1. 商户环境包含标准 SAQ 未定义的组件或交互模式（如 IoT 支付终端混合电商）；
2. 商户已实施补偿性控制，需要以等效方式证明合规；
3. 支付 SDK 的集成方式导致部分 DSS 要求不适用，需逐条论证；
4. QSA 评估后认定标准 SAQ 无法合理覆盖实际风险。

流程约束：

• 必须由 QSA（合格安全评估师） 主导，不能由商户自行裁定；
• 必须产出《定制化评估范围声明书》，经收单行或品牌方确认；
• 最终报告需与 PCI DSS 要求逐条对照，标注“适用/不适用/补偿”，并提供理由。

3.6 SAQ类型选择决策流程

下图展示从商户环境评估到最终 SAQ 类型确定的完整决策逻辑。每个决策节点均需出具对应的合规证据。

3.7 材料清单与台账管理

SAQ 类型选择阶段须准备的基础材料：

台账记录（示例模板，每 SAQ 评估周期更新一次）：

| 台账ID | SAQ 类型 | 选定日期 | 决策依据摘要          | 负责人 | QSA 确认 | 关联证据包ID |
|--------|---------|----------|----------------------|--------|----------|-------------|
| SAQ-03 | A‑EP    | 2025-02-10 | 仅电商+Stripe嵌入+无数据接触 | 张敏   | 李明 QSA | PKG-2025-008 |
| SAQ-04 | D       | 2025-03-01 | 自定义SDK路由+商户服务器参与 | 王磊   | 自行评估  | PKG-2025-012 |
| SAQ-05 | 定制化  | 2025-04-15 | 混合模式+补偿控制      | 赵倩   | 刘洋 QSA | PKG-2025-019 |

3.8 审计检查与整改闭环

审计师验证要点：

1. SAQ 选择依据文件 —— 是否经过管理层审批？是否与数据流图一致？
2. 第三方合规状态 —— 使用的支付服务商是否在 PCI SSC 列表中？AOC 是否在有效期内？
3. 支付页面元素审计 —— 对于 SAQ A‑EP，检查页面源码确认卡号是否经商户服务器（通过浏览器 DevTools 或网络抓包）。
4. 交叉验证 —— 调取半年内的交易日志，确认商户系统未出现持卡人数据痕迹。

整改闭环流程：

• 触发条件： 审计发现 SAQ 类型与实际情况不符；或支付 SDK 集成方式发生变更。
• 第一步： 暂停当前 AOC，启动纠正性评估，重新执行环境调研与类型选择。
• 第二步： 更新台账，记录变更原因、新 SAQ 类型、影响范围。
• 第三步： 补充缺失的证据项（如重新签订 TPA、补做 ASV 扫描）。
• 第四步： QSA 或内部合规组复核通过后，重新签发 AOC。
• 第五步： 将本次整改纳入培训案例库，防止同类错误重复发生。