一、PCI DSS 是谁在要求你

先把主体关系弄清楚，这决定了它的约束力和执行方式：

• 发布方——支付卡行业安全标准委员会（PCI SSC），由主要卡组织共同组建；
• 要求你的是——收单行与卡组织的合同，不是政府监管；
• 不遵守的后果——罚款、提高手续费，甚至取消受理资格；
• 罚款区间——约每月 5,000 到 100,000 美元，由收单行按合同执行。

【不是法律】这一点很重要，它带来两个实际影响：

• 要求更具体、更工程化。法律通常说【应当采取必要措施】，而 PCI DSS 会写【密码长度下限 12 位】——这类要求可以直接拿去配置系统，不需要解释。
• 执行者是商业伙伴而不是监管机关。这意味着【协商空间】存在于合同层面（比如整改期限、评估方式），但也意味着【不整改】的后果会很快落到业务上——一旦被暂停受理，电商的收入当天归零。

二、版本现状：2026 年只有 v4.0.1 有效

版本这件事在 PCI DSS 里格外重要，因为版本切换直接决定【要做什么】：

两个细节要注意：

• v4.0.1 是一次【限量修订】：没有增删任何要求，只是澄清与勘误。所以不要指望换版本能少做几项——这类修订的目的是让表述更清楚，避免歧义，而不是放宽或收紧。
• 2025-03-31 那道过渡期已经过去一年多。v4.0 里那些标注【未来生效日期】的 51 项要求，现在一律是强制项。在 2026 年做合规盘点时，如果还在用【这部分是未来的要求】当理由，那就是把过渡期记错了。

三、最有操作量的几项

所有要求里，下面这五项是企业最常喊疼的地方——因为它们都要求组织拿出【持续的、有流程的】证据，而不是一次性配置：

6.4.3 和 11.6.1 值得单独解释，因为它们对应着一类特别阴险的攻击：

这类攻击的名字叫 Magecart（或叫表单劫持、e-skimming）。它的做法是：攻击者不入侵你的服务器，而是通过第三方脚本、被篡改的插件、或供应链环节，往你的支付页面上塞一段 JavaScript。这段脚本做的事很简单：在用户把卡片号填进表单、点提交的那一瞬间，先把数据复制一份发到攻击者控制的地址。

为什么这种攻击难防：① 从用户视角看，页面完全正常，地址栏是 HTTPS，证书没问题（5-8 讲过的局限在这里体现得很清楚：加密保护的是传输管道，而不是页面上的代码）；② 从服务器视角看，你的代码没有被改，你要检查的是【页面上加载了哪些第三方脚本】，这份清单你往往并不完整。

所以 6.4.3 要求的就是【先有清单】：页面上每个脚本都要有出处、有授权、有变更流程；11.6.1 要求【有变化要告警】：脚本内容或 HTTP 头在未经授权的变更之后，要能被检测出来。这两条合起来，等于把【支付页面上跑着哪些代码】变成一件受管的事。

四、商户分级：先知道自己属于哪一级

合规工作的第一步不是【做什么】，而是【我属于哪一级】——因为级别直接决定评估方式和成本：

这张表里有两个容易踩的点：

• 【任何渠道】意味着线上线下要合并计算。一家既有门店又有网店的企业，两边的交易量要合在一起再定级——不能只算电商那部分，从而把自己划到更低的一级。
• 【SAQ A 更简单】不等于【省事】。只要支付页面在你自己的域名下，每季度都要做外部漏洞扫描（ASV），还要确认脚本控制。换句话说，级别低只是评估方式简单（用问卷而不是现场），并不是没有持续义务。

五、动手 Demo：给一笔交易量定级

def level(vol, ecom):
    if vol > 6000000:
        return "L1", "QSA 现场评估（ROC）"
    if vol > 1000000:
        return "L2", "SAQ + 季度 ASV 扫描"
    if ecom and vol >= 20000:
        return "L3", "SAQ A / A-EP + 季度 ASV 扫描"
    return "L4", "SAQ A + 季度 ASV 扫描"

cases = [(12000000, True), (3000000, False), (500000, True),
         (80000, True), (15000, True), (900000, False)]

实跑输出：

五、给一笔交易量，判定它属于哪一级
  年交易笔数      是否电商    判定级别    主要工作
  12,000,000      是          L1          QSA 现场评估（ROC）
  3,000,000       否          L2          SAQ + 季度 ASV 扫描
  500,000         是          L3          SAQ A / A-EP + 季度 ASV 扫描
  80,000          是          L3          SAQ A / A-EP + 季度 ASV 扫描
  15,000          是          L4          SAQ A + 季度 ASV 扫描
  900,000         否          L4          SAQ A + 季度 ASV 扫描
  → 同一家公司，线上线下渠道的交易量要合并计算后再定级。

读这个输出：

• 注意第 2 行和第 6 行的对比：3,000,000 笔是非电商，落到 L2；900,000 笔也是非电商，却落到 L4。原因是非电商只有在 100 万到 600 万这个区间才是 L2，低于 100 万就落进 L4（其余情况）。这个断点很容易记错——非电商并不是【量越大级别越高】这么简单。
• 第 4 行（80,000 笔电商）落在 L3，第 5 行（15,000 笔电商）落在 L4。分界点是 20,000 笔。对小电商来说，这个分界点决定的是【要不要按 SAQ A-EP 做准备】——工作量差别不小，所以定级这一步值得认真算一遍。

六、⚠️ 2026 现状

• 【罚款之外更贵的是【不能刷卡】】。 罚款按合同走，但真正的业务风险是被暂停受理：一旦收单行停止服务，电商的交易收入当天归零，恢复还要重走一次评估。所以在预算会上谈 PCI DSS 合规时，把【停机一天的收入损失】和【合规投入】放在一起对比，比单讲罚款更有说服力。
• 【浏览器与支付生态在往前推，年度评估不够了】。 脚本清单、子资源完整性校验（SRI）、内容安全策略（CSP）都成了常规动作。这三项的共同点是【技术手段】，它们和 PCI DSS 的台账要求配合起来才有意义：清单告诉你该管什么，SRI 与 CSP 负责让没被授权的脚本根本跑不起来。
• 【支付页面脚本这项要求会持续加码】。 它的根因是供应链：你的支付页面通常加载了多个第三方脚本（分析、营销、客服、风控），每一个都是一次外部依赖。做清单的时候要连带回答三个问题：这个脚本是谁提供的、它会不会接触卡片数据、它什么时候更新——这三个问题的答案，决定了它是不是必须留在支付页面上。
• 【这条思路和【第三方/供应链】整体趋势一致】。 4-12 讲的是插件与第三方组件的风险，6-13 讲的是第三方服务带来的暴露面——PCI DSS 的 6.4.3 与 11.6.1 只是把这个普遍问题，在支付这个最高价值的场景里，变成了必须做的动作。

30 秒实验

今天做两个动作，各 15 秒：

1. 打开一个你常用的电商或订餐 App，进入支付页面，看它加载了多少个第三方脚本。 手机上看不到的话，用浏览器的开发者工具看网络请求。数出来的数量通常会让人意外——这就是 6.4.3 要求【脚本清单】的原因：不数一遍，你根本不知道页面上跑着谁的东西。
2. 看它地址栏与页面内容是否一致：地址栏锁标正常，不代表页面代码没问题。如果页面里有大量来自不同域名的脚本，那么这个页面的实际信任范围远超你的想象——任何一家脚本提供方被攻破，都会影响到这个支付页面。

这一节要带走的一句是：PCI DSS 的价值不在于它列了多少条要做的动作，而在于它把【支付场景下的安全】变成了有清单、有评估、有合同后果的事——它不依赖你的自觉。

常见误区

1. 错误：PCI DSS 是法律规定，不做就是违法。——纠正：PCI DSS 是行业标准，不是法律法规；它的强制力来自收单行与卡组织的合同。这个区别有实际意义：① 执行主体不同——罚款与处罚由收单行按合同执行，不是由监管机关作出；② 适用范围不同——它管的是【涉及持卡人数据的部分】，而不是整个组织的所有系统（这也是很多要求的适用范围写作【持卡人数据环境】的原因）；③ 协商空间不同——整改期限、评估方式、补偿措施通常可以在合同层面沟通。但要注意：【不是法律】不等于【可以为所欲为】——个人信息保护法、网络安全法在这件事上仍有强制要求，而且泄露持卡人数据还涉及对持卡人的民事责任。准确的说法是：PCI DSS 是【合同 + 行业标准】这一层的要求，与其他法律要求叠加存在，而不是替代。

2. 错误：把支付页面托管给第三方收银台，自己就不用管 PCI DSS 了。——纠正：要看【支付页面在谁的域名下、卡片数据经过谁的系统】。 SAQ A 之所以最轻，前提是全部支付处理都外包、自己的系统不接触卡片数据。 但现实中有一条界线经常被跨过：如果支付页面上仍然加载了你自己的脚本（统计、营销、客服插件），那么页面就仍然是你的控制范围——这正是 6.4.3 与 11.6.1 出现的原因，它们对 SAQ A 的商户同样适用。 判断方法很直接：问一句【用户输入卡片号的那一刻，数据经过了哪些域】——答案里出现的任何一方，都是这条链上必须被评估的一环。

3. 错误：年度评估做完了，今年就没事了。——纠正：PCI DSS 里相当多的要求本质上是【持续动作】，不是【年度状态】。最典型的三个：① 季度的外部漏洞扫描（ASV）——不是每年做一次就行；② 12.3.1 的定向风险分析——允许灵活频次，但必须书面论证【为什么这个频次足够】，一般没有人会论证【一年一次足够】；③ 日志留存与监控（6-10 会展开）本身就是持续运行的要求。换句话说，PCI DSS 的合规状态更像【体检 + 日常保养】，而不是【年检合格证】。 变化（新增系统、换支付服务商、上线新营销脚本）会重新拉高要求，改完之后要重新评估，而不是等下一个评估周期。

4. 错误：既然有罚款，那说明只要肯付钱就行。——纠正：罚款只是最轻的一层后果，真正的风险在业务连续性上。按顺序看：罚款（每月 5,000 ~ 100,000 美元）→ 手续费上调 → 被暂停受理（收入归零）→ 卡组织层面的黑名单（可能影响到其他业务）。其中【暂停受理】是最难接受的一档：它直接切断收入，而且恢复需要重新走评估流程，不是交完罚款就能回来的。 另一个常被忽略的代价是品牌与客户信任：支付数据泄露的客户流失，往往比一次合规投入更贵。 所以正确的算法是：合规投入 vs（停机损失 + 客户流失 + 罚款）——而不是【合规投入 vs 罚款】。

• ☐ 下一节（6-7 自然灾害对策也是安全的一环）

相关笔记

• 突发事件的早期应对 —— 上一篇：出事后最初 60 分钟怎么走
• 自然灾害对策也是安全的一环 —— 下一篇：另一种【事件】，它不来自攻击者
• 跨越多个网站的攻击 —— 支付页面上注入脚本的技术原理
• 当心那些使用方便的工具中存在的漏洞 —— 第三方组件的风险，支付页面脚本是其中一例
• 🛡️ 网络与信息安全 · 索引 —— 全课路线图