PCI DSS 概述：背景、历史、适用范围
做支付安全这么多年，我经常被问到一个问题：「PCI DSS 到底是什么？我们公司刚起步，也要做合规吗？」坦白讲，这个问题没有标准答案——但如果你接触、存储或传输过信用卡号，那答案基本就是「必须」。今天我们就从头梳理一下这套标准的来龙去脉。
我个人习惯把 PCI DSS 看作「支付行业的交规」。没有它，整个卡支付生态会乱成一锅粥。为什么会这样？因为信用卡数据一旦泄露，损失的不只是钱，还有用户对商户的信任——我见过一家中型电商因为一次数据泄露，三个月内用户流失超过 60%。嗯，这确实很残酷。
背景：为什么需要 PCI DSS？
在 2000 年以前，Visa、MasterCard 等卡品牌各自有自己的安全要求：Visa 有 CISP，MasterCard 有 SDP，American Express 有 DSP……一个商户如果要同时接受多品牌卡，就要应付四五套不同的审核表。不仅麻烦，而且标准不一，漏洞反而更多。
我记得有一次陪朋友公司做审计，光准备不同品牌的表格就花了整整两周。当时我就想：如果有人能把这些标准统一起来就好了。后来确实这么干了——2004 年，五大卡品牌联合推出了 PCI DSS，也就是支付卡行业数据安全标准。
历史：版本演进与关键里程碑
从 2004 年 v1.0 到现在最新的 v4.0，PCI DSS 经历了多次重大更新。下面这张表列了主要版本和变化点：
| 版本 | 发布时间 | 关键变化 |
|---|---|---|
| v1.0 | 2004-12 | 首次统一五大品牌安全标准，12 大要求框架确立 |
| v1.1 | 2006-09 | 细化无线网络安全、日志审计要求 |
| v2.0 | 2010-10 | 增加虚拟化、云计算指导，简化 SAQ |
| v3.0 | 2013-11 | 强调安全作为持续过程，引入安全评估框架 |
| v3.2.1 | 2018-05 | 加强 e-commerce、第三方安全要求 |
| v4.0 | 2022-03 | 模块化结构，支持自定义控制，灵活性与安全性平衡 |
这里要特别提一下 v4.0。它不再要求所有实体在同一个时间点必须全部达标，而是允许「分阶段」「分模块」地实现。你想想看，这对中小商户其实是个利好。但注意——分阶段不等于放松，只是路径更灵活。我建议你在规划合规时间表时，直接拿 v4.0 的要求来设计，不要回头去改旧版本了。
适用范围：哪些实体在「射程」内？
先给一个最简单判断标准：只要你的系统涉及「存储、处理、传输」持卡人数据（CHD），你就必须合规。具体包括以下三类：
- 商户（Merchant）：接受信用卡支付的任何商家，包括电商、实体店、订阅服务。
- 服务提供商（Service Provider）：帮商户处理、存储、传输卡片数据的第三方，比如支付网关、托管平台、分析工具。注意！如果你只提供网络/IP 层连接，不接触卡片数据，通常不算服务提供商。
- 金融机构（Financial Institution）：发卡行、收单行，以及处理交易的银行。
如果你不确定自己是否属于适用范围，可以对照下面这张图——它代表了 PCI DSS 合规体系的整体结构。你站在哪个位置，一目了然。
记住这个核心逻辑：合规不是终点，而是持续的过程。Tokenization 能帮你大幅缩小受审视的范围，但前提是你必须先清楚自己的「射程」——也就是你的 CDE（持卡人数据环境）在哪里。第一章就是帮你画好这个「射程框」。
说到 CDE，我曾经帮一个客户做梳理，发现他们的 CRM 系统里竟然存了 3 年前的信用卡主账号（PAN），而且毫无加密。业务部门根本不知道那是什么。你看，很多人以为「我们不碰卡号」，但实际上日志、备份、甚至客服的聊天记录都可能藏着敏感数据。所以第一步永远是——清点你的资产。
适用范围：具体场景判断
给你三个快速判断场景：
- 纯线下刷卡：走支付终端（POS），数据由收单方处理，你（商户）不存储卡号。通常只需要填写 SAQ A 或 SAQ A-EP 表。
- 电商网站：收集卡号、CVV 等数据，可能经过支付网关。如果你采用 iframe 或跳转支付页面，自己后台不存卡号，仍然属于 SAQ A。但如果你在服务器端拿到了原始 PAN，那你就要按 SAQ D 来准备——这是最严格的。
- 订阅服务 + 存卡号：这是最常见需要 Tokenization 的场景。你存储了卡号以便定期扣费，那么你的整个后台都必须符合 PCI DSS 要求，除非你用了第三方 服务——比如将卡号换成 保存。
好了，第一步——理解背景、历史和适用范围——我们算是走完了。接下来你会陆续接触到具体的 12 大要求以及 Tokenization 的实战部署。别急，先从画好自己的「数据地图」开始。