pci-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PCI Audit — Payment Card Industry Data Security Standard

PCI审计——支付卡行业数据安全标准

PCI DSS v4.0 (effective March 2025) is the security standard for any environment that stores, processes, or transmits payment card data. Twelve high-level requirements; hundreds of sub-requirements. Most organizations pass or fail on a single decision: scope.

This skill emphasizes scope determination first, then the engineering-relevant requirements. Final compliance attestation (SAQ self-assessment or QSA audit producing an Attestation of Compliance) is a process this skill prepares for — it is not the attestation itself.

Cross-references:

crypto-audit

for Req 3 / 4 cryptographic detail;

iam-audit

for Req 7-8;

siem-detection

for Req 10 logging;

dependency-audit

and

owasp-audit

for Req 6 (secure SDLC);

incident-triage

for Req 12.10 (incident response).

PCI DSS v4.0（2025年3月生效）是所有存储、处理或传输支付卡数据的环境需遵循的安全标准。包含12项高层要求，数百项子要求。大多数组织的合规成败取决于一个决策：范围。

本技能首先强调范围确定，随后聚焦与工程相关的要求。最终合规证明（SAQ自我评估或QSA审计生成的合规证明AoC）是本技能为之做准备的流程——而非证明本身。

交叉参考：

crypto-audit

用于Req 3/4的加密细节；

iam-audit

用于Req 7-8；

siem-detection

用于Req 10日志记录；

dependency-audit

和

owasp-audit

用于Req 6（安全SDLC）；

incident-triage

用于Req 12.10（事件响应）。

The scope question (do this first)

范围问题（优先处理）

"Scope" in PCI DSS means: the systems that store, process, or transmit cardholder data (CHD), plus systems that can affect the security of those systems (connected-to and security-impacting systems). Everything in scope is subject to all 12 requirements. Everything out of scope is not.

Most PCI failures are scope failures. A system pulled into scope by accident creates years of compliance debt; a system kept out of scope via good architecture saves substantial cost.

PCI DSS中的“范围”指：存储、处理或传输持卡人数据（CHD）的系统，以及可能影响这些系统安全性的系统（连接系统和安全影响系统）。所有在范围内的系统必须遵循全部12项要求，范围外的则无需遵循。

大多数PCI合规失败源于范围错误。意外被纳入范围的系统会造成多年的合规债务；通过良好架构排除在范围外的系统则能大幅节省成本。

Determine scope

确定范围

For every system in the environment, classify:

Type	Definition	In scope?
CDE (Cardholder Data Environment)	Stores, processes, or transmits PAN, expiration, service code, name when paired with PAN, or sensitive authentication data	Yes — full PCI DSS
Connected-to	Has direct connectivity to the CDE without compensating segmentation	Yes
Security-impacting	Provides security services to the CDE (auth, logging, monitoring, time sync, DNS)	Yes
Segmented	No direct connectivity; segmentation validated annually	No
Cardholder data flow only as masked / tokenized	The system handles tokens or masked PANs that cannot be reversed without out-of-band access	Usually No, but verify the token type — surrogate tokens reversible by the merchant are still in scope

Audit step: trace every payment flow end-to-end. Where does the PAN enter the environment, where does it go, where does it stop. Every system the PAN touches is in scope; every system that touches that system without segmentation is also in scope.

针对环境中的每个系统，进行分类：

类型	定义	是否在范围内？
CDE（持卡人数据环境）	存储、处理或传输PAN、有效期、服务代码、与PAN关联的姓名，或敏感认证数据	是——需完全遵循PCI DSS
连接系统	无需补偿性分段即可直接连接到CDE	是
安全影响系统	为CDE提供安全服务（认证、日志记录、监控、时间同步、DNS）	是
分段系统	无直接连接；分段需每年验证	否
仅处理掩码化/令牌化的持卡人数据流	系统处理令牌或无法通过带外访问还原的掩码PAN	通常否，但需验证令牌类型——商家可还原的替代令牌仍属于范围

审计步骤： 端到端追踪每一条支付流程。PAN在何处进入环境、流向何处、在何处停止。PAN接触的所有系统均在范围内；未通过分段隔离且接触这些系统的所有系统也在范围内。

Reduce scope (the leveraged engineering work)

缩小范围（高ROI的工程工作）

The highest-ROI PCI work is usually scope reduction:

Use a hosted payment page — let Stripe / Adyen / Braintree / Worldpay host the input form. The PAN never reaches your servers. The browser communicates directly with the processor. Your scope shrinks to "iframe integration."
Use tokenization — payment processor converts PAN into a token your systems store instead. The token is meaningless without processor-side access. Your systems handle tokens, not PANs.
Use P2PE (Point-to-Point Encryption) — for terminal-present commerce, encrypt at the swipe so plaintext never traverses your network.
Network segmentation — for retained CDE, ensure firewall / VLAN / namespace separation between CDE and the rest. Default-deny at the CDE perimeter.

A merchant doing 1M transactions/year via Stripe Checkout with no PAN on their servers is radically less in scope than the same merchant taking PANs into their own form and proxying to Stripe. Same merchant; very different audit.

PCI合规工作中投资回报率最高的通常是缩小范围：

使用托管支付页面——让Stripe/Adyen/Braintree/Worldpay托管输入表单。PAN永远不会到达你的服务器。浏览器直接与处理器通信。你的范围将缩小到“iframe集成”。
使用tokenization（令牌化）——支付处理器将PAN转换为你的系统存储的令牌。若无处理器端访问权限，令牌毫无意义。你的系统处理令牌而非PAN。
使用P2PE（端到端加密）——对于终端场景的交易，在刷卡时加密，明文永远不会通过你的网络传输。
网络分段——对于保留的CDE，确保CDE与其他系统之间通过防火墙/VLAN/命名空间隔离。CDE边界默认拒绝所有访问。

每年处理100万笔交易且服务器上无PAN的商家，其合规范围远小于将PAN接入自有表单再代理到Stripe的同规模商家。同一商家，审计难度截然不同。

Merchant levels and assessment types (compliance posture, not engineering)

商家等级与评估类型（合规态势，非工程相关）

Briefly, because it sets the audit cadence and rigor:

Level	Volume (Visa)	Validation requirement
1	> 6M transactions/year, or breached merchant of any volume	Annual on-site QSA assessment → AoC
2	1M-6M transactions/year	Annual SAQ (self) or QSA assessment (Visa requires QSA from 2024)
3	20K-1M e-commerce transactions/year	Annual SAQ
4	All other	Annual SAQ

SAQ types (Self-Assessment Questionnaire) match the merchant's CDE shape — SAQ A (fully outsourced e-commerce), SAQ A-EP (e-commerce that does some redirection), SAQ B (terminal only, dial / IP without electronic storage), SAQ C-VT (web-based virtual terminal), SAQ D (everything else, the longest). The right SAQ is the one whose conditions all match your environment.

简要说明，因为这决定了审计频率和严格程度：

等级	交易量（Visa）	验证要求
1级	年交易量>600万，或任何规模的遭 breach商家	年度现场QSA评估 → AoC
2级	年交易量100万-600万	年度SAQ（自我评估）或QSA评估（Visa要求2024年起需QSA评估）
3级	年电商交易量2万-100万	年度SAQ
4级	其他所有情况	年度SAQ

SAQ类型（自我评估问卷）与商家的CDE形态匹配——SAQ A（完全外包电商）、SAQ A-EP（部分重定向的电商）、SAQ B（仅终端，拨号/IP且无电子存储）、SAQ C-VT（基于网页的虚拟终端）、SAQ D（其他所有情况，篇幅最长）。合适的SAQ是完全符合你的环境条件的问卷。

Engineering-relevant requirements (the subset this skill audits)

与工程相关的要求（本技能审计的子集）

Req 3 — Protect stored cardholder data

Req 3 — 保护存储的持卡人数据

The default position: do not store PAN. If you must, encrypt at rest and minimize the data retained.

PAN at rest must be unreadable: strong cryptography (AES-256), key management per Req 3.6 (see
```
crypto-audit
```
), key rotation, separation of duties on key custody
Sensitive authentication data (CVV / CVV2, full magnetic stripe, PIN / PIN block) must not be stored after authorization — period, regardless of encryption
Mask PAN on display by default — typically first 6 + last 4
Render PAN unreadable in any other form (backups, logs, debug output)

Audit grep patterns:

Database schemas: columns named

pan

card_number

cc_number

cardnum

account_number

Code paths writing card data:

pan

cardNumber

, regex

^4[0-9]{12,15}$

(Visa),

^5[1-5][0-9]{14}$

(Mastercard),

^3[47][0-9]{13}$

(Amex),

^6(?:011|5[0-9]{2})[0-9]{12}$

(Discover)

Logs:

console\.log.*cardNumber

logger\..*\.pan

log\..*card

Error reporting: confirm Sentry / Datadog / Bugsnag scrubbing rules redact card patterns (Luhn-valid 13-19 digit sequences)
Backups: confirm backup retention does not include unencrypted CHD

If a Luhn-valid PAN appears anywhere in source, lock files, or logs — that is a finding regardless of intent.

默认原则：不要存储PAN。若必须存储，需加密静态数据并最小化保留的数据量。

静态PAN必须不可读：采用强加密（AES-256），密钥管理遵循Req 3.6（参见
```
crypto-audit
```
），密钥轮换，密钥保管职责分离
敏感认证数据（CVV/CVV2、完整磁条、PIN/PIN块）授权后绝对不能存储——无论是否加密，均禁止存储
默认情况下显示掩码化的PAN——通常显示前6位+后4位
确保PAN在任何其他形式（备份、日志、调试输出）中不可读

审计 grep 模式：

数据库 schema：命名为
```
pan
```
、
```
card_number
```
、
```
cc_number
```
、
```
cardnum
```
、
```
account_number
```
的列
写入卡数据的代码路径：
```
pan
```
、
```
cardNumber
```
，正则表达式
```
^4[0-9]{12,15}$
```
（Visa）、
```
^5[1-5][0-9]{14}$
```
（Mastercard）、
```
^3[47][0-9]{13}$
```
（Amex）、
```
^6(?:011|5[0-9]{2})[0-9]{12}$
```
（Discover）

日志：

console\.log.*cardNumber

、

logger\..*\.pan

、

log\..*card

错误报告：确认Sentry/Datadog/Bugsnag的 scrubbing 规则已屏蔽卡数据模式（符合Luhn校验的13-19位数字序列）
备份：确认备份保留的内容不包含未加密的CHD

如果符合Luhn校验的PAN出现在源代码、锁文件或日志中的任何位置——无论意图如何，均视为违规。

Req 4 — Protect transmission across open networks

Req 4 — 保护开放网络中的传输

TLS 1.2 or higher, modern cipher suites only (see
```
crypto-audit
```
for the configuration detail)
No PAN transmitted via end-user messaging tech (email, SMS, chat) — and reject any flow that does
Internal-only networks transmitting PAN should still encrypt (defense in depth — Req 4.2.1.1 in v4.0)

仅使用TLS 1.2或更高版本，采用现代加密套件（配置细节参见
```
crypto-audit
```
）
禁止通过终端用户消息技术（电子邮件、SMS、聊天）传输PAN——拒绝任何此类流程
传输PAN的内部网络也应加密（纵深防御——v4.0中的Req 4.2.1.1）

Req 6 — Develop and maintain secure systems and software

Req 6 — 开发并维护安全的系统与软件

This is where the security audit family meets PCI. Most of this requirement is satisfied by running the existing skills:

6.2 Custom software developed securely — see
```
owasp-audit
```
,
```
api-audit
```
6.3 Vulnerabilities identified and addressed — see
```
vuln-research
```
,
```
dependency-audit
```
,
```
finding-triage
```
6.4 Public-facing web applications protected from attacks — WAF or annual code review + post-release manual review
6.5 Changes to all system components managed securely — change management, separation of duties between dev and prod, sanitization of pre-production data before lower-environment use

Audit grep patterns:

Lower-environment configs containing real PANs (the common failure: staging seeded from a prod DB dump that included card data)
Code paths that bypass the secure SDLC (direct prod hotfix patterns,
```
--no-verify
```
on commits to prod-impacting branches)

这是安全审计体系与PCI的交叉点。本要求的大部分内容可通过运行现有技能满足：

6.2 安全开发自定义软件——参见
```
owasp-audit
```
、
```
api-audit
```

6.3 识别并修复漏洞——参见

vuln-research

、

dependency-audit

、

finding-triage

6.4 保护面向公众的Web应用免受攻击——使用WAF或年度代码审查+发布后手动审查
6.5 安全管理所有系统组件的变更——变更管理，开发与生产职责分离，预生产环境使用前清理预生产数据

审计 grep 模式：

包含真实PAN的低环境配置（常见错误： staging环境从包含卡数据的生产数据库转储中获取数据）
绕过安全SDLC的代码路径（直接生产热修复模式，向影响生产的分支提交时使用
```
--no-verify
```
）

Req 7 — Restrict access to cardholder data by business need to know

Req 7 — 根据业务需求限制对持卡人数据的访问

Role-based access — only personnel needing CHD for their job have access
Default-deny — access is granted explicitly, never inherited
Privileged user IDs documented and reviewed

See

iam-audit

for the full identity-and-access deep dive.

基于角色的访问——仅需要CHD完成工作的人员才可访问
默认拒绝——访问需明确授予，而非继承获得
记录并审查特权用户ID

有关身份与访问的深入分析，请参见

iam-audit

。

Req 8 — Identify users and authenticate access

Req 8 — 识别用户并验证访问权限

Unique IDs (no shared accounts) for every user — including service accounts
Strong authentication — passwords meeting current PCI complexity requirements, MFA for non-console administrative access AND for all remote network access AND (new in v4.0) for all access into the CDE
MFA must be phishing-resistant for the most sensitive access paths (recommended in v4.0)
Account lockout, session timeout, password rotation per current PCI parameters (v4.0 relaxed some legacy requirements — verify current text)

See

iam-audit

for implementation patterns and identity-provider integration.

为每个用户分配唯一ID（无共享账户）——包括服务账户
强认证——密码符合当前PCI复杂度要求，非控制台管理访问、所有远程网络访问以及（v4.0新增）所有CDE访问均需MFA
对于最敏感的访问路径，MFA必须具备反钓鱼能力（v4.0推荐）
账户锁定、会话超时、密码轮换需符合当前PCI参数（v4.0放宽了部分旧有要求——请核实当前文本）

有关实现模式与身份提供商集成，请参见

iam-audit

。

Req 10 — Log and monitor all access to network resources and cardholder data

Req 10 — 记录并监控所有对网络资源和持卡人数据的访问

Every access to CHD logged — who, when, what, from where
Logs centralized, time-synced (Req 10.6 — NTP), retained at least 12 months (3 months immediately available)
Logs reviewed daily — manual or automated. Anomalies trigger investigation
Log integrity protected — separate system, write-only, immutable storage

See

siem-detection

for the engineering implementation; see

soc-operations

for the review cadence.

记录所有对CHD的访问——谁、何时、访问了什么、从何处访问
日志集中存储、时间同步（Req 10.6——NTP），至少保留12个月（最近3个月需可立即调取）
每日审查日志——手动或自动化。异常情况需触发调查
保护日志完整性——使用独立系统、写入权限、不可变存储

有关工程实现，请参见

siem-detection

；有关审查频率，请参见

soc-operations

。

Req 11 — Test security of systems and networks regularly

Req 11 — 定期测试系统与网络的安全性

Vulnerability scans — internal and external, quarterly. External scans must be by an ASV (Approved Scanning Vendor)
Penetration tests — annual at minimum, after significant changes. Internal AND external. Network and application layer. Tested by qualified internal resource or third party
Segmentation testing (for environments relying on segmentation to reduce scope) — annual penetration testing specifically to validate segmentation
File integrity monitoring on critical files / configs

See

dependency-audit

(vulnerability scan),

web-pentest

(annual app pentest),

red-team-engagement

(annual offensive engagement for higher levels).

漏洞扫描——内部与外部扫描，每季度一次。外部扫描必须由ASV（获批扫描供应商）执行
渗透测试——每年至少一次，重大变更后需额外测试。内部与外部测试均需覆盖网络和应用层。由合格的内部人员或第三方执行测试
分段测试（针对依赖分段缩小范围的环境）——每年进行专门的渗透测试以验证分段有效性
关键文件/配置的文件完整性监控

参见

dependency-audit

（漏洞扫描）、

web-pentest

（年度应用渗透测试）、

red-team-engagement

（针对高等级商家的年度攻防演练）。

Req 12 — Maintain an information security policy

Req 12 — 维护信息安全政策

The program-level layer. Engineering inputs:

12.10 Incident response plan — see
```
incident-triage
```
. Tested at least annually
12.5 Third-party / service-provider management — DPA-like attestations, annual review of provider compliance (your processor will send you an AoC; you must retain it)
12.6 Security awareness training — for personnel handling CHD

这是计划层面的要求。工程相关输入：

12.10 事件响应计划——参见
```
incident-triage
```
。每年至少测试一次
12.5 第三方/服务提供商管理——类似DPA的证明，每年审查提供商合规性（你的处理器会向你发送AoC；你必须留存该证明）
12.6 安全意识培训——针对处理CHD的人员

Putting it together — audit checklist

整合——审计清单

markdown

undefined

markdown

undefined

PCI DSS v4.0 Audit Findings

PCI DSS v4.0审计结果

Merchant: [name]

商家：[名称]

Merchant level: [1/2/3/4]

商家等级：[1/2/3/4]

SAQ type: [A / A-EP / B / C-VT / D / not applicable - Level 1 QSA]

SAQ类型：[A / A-EP / B / C-VT / D / 不适用 - 1级QSA]

Date: [date]

日期：[日期]

Auditor: [name + qualification]

审计员：[姓名 + 资质]

Scope determination

范围确定

Per-requirement findings

按要求分类的审计结果

Req	Compliant?	Findings	Severity
3 — Stored CHD
4 — Transmission
6 — Secure SDLC
7 — Access restriction
8 — Authentication
10 — Logging
11 — Testing
12 — Program

要求	是否合规？	问题	严重程度
3 — 存储的CHD
4 — 传输
6 — 安全SDLC
7 — 访问限制
8 — 认证
10 — 日志记录
11 — 测试
12 — 合规计划

Per-finding detail

问题详情

[Title, req reference, severity, location, vulnerable config, remediation, verification]

[标题、要求参考、严重程度、位置、易受攻击的配置、修复方案、验证方式]

Recommended scope reductions (if applicable)

Compensating controls (if used)

补偿控制（如使用）

[Each compensating control: control description, what it compensates for, evidence of effectiveness, review cadence]


Disposition rule (Fixed / Deferred / Accepted Risk) per `owasp-audit`. PCI accepted-risk is heavily disfavored — most "accepted risks" should be Compensating Controls with documented evidence of effectiveness.

[每个补偿控制：控制描述、补偿对象、有效性证据、审查频率]


处理规则（修复/延期/接受风险）参见`owasp-audit`。PCI不鼓励接受风险——大多数“接受风险”应改为具备有效性证明的补偿控制。

Common audit findings (real-world starting hypotheses)

常见审计问题（现实场景初始假设）

PAN in logs — error / debug / access logs containing card data, captured by Sentry / Datadog / Bugsnag, retained beyond authorization
Sensitive authentication data persistence — CVV stored "for re-billing convenience" (forbidden), or full track data captured by accident
Lower environments seeded from production — staging database contains real PANs from a prod dump that was not sanitized
Tokenization scope misunderstanding — surrogate tokens stored in your DB that are reversible by your processor account are still in scope; only one-way tokens reduce scope
Iframe vs proxy — "hosted payment page" implemented as a proxy where your server briefly handles the PAN before forwarding (still in scope) vs a true iframe where your server never sees it (out of scope)
Segmentation by firewall rule, not by architecture — firewall rule "permits" only specific traffic but the systems share a VLAN; effective segmentation requires architectural separation
MFA gaps — v4.0 broadened MFA requirements; older environments that met v3.2.1 may have gaps

日志中的PAN——错误/调试/访问日志包含卡数据，被Sentry/Datadog/Bugsnag捕获，保留时间超过授权期
敏感认证数据持久化——为“方便重复计费”存储CVV（禁止），或意外捕获完整磁条数据
从生产环境同步低环境数据—— staging数据库包含来自未清理的生产数据库转储的真实PAN
令牌化范围误解——存储在你的数据库中且可通过你的处理器账户还原的替代令牌仍属于范围；仅单向令牌可缩小范围
iframe vs 代理——“托管支付页面”以代理方式实现，你的服务器在转发前短暂处理PAN（仍在范围内），而非真正的iframe（你的服务器从未接触PAN，不在范围内）
仅通过防火墙规则分段，而非架构分段——防火墙规则“允许”特定流量，但系统共享VLAN；有效的分段需要架构层面的隔离
MFA缺口——v4.0扩大了MFA要求；符合v3.2.1的旧环境可能存在缺口

Boundaries

边界

This skill is the engineering-side audit and preparation. Final compliance attestation (signed SAQ for self-assessing merchants, AoC produced by a QSA for higher-tier merchants) is a separate process
For QSA-led Level 1 assessments, this skill produces inputs to the QSA; it does not replace the QSA's independent assessment
Refuse to help build flows that violate PCI DSS — storing CVV, transmitting PAN via email, bypassing tokenization to capture raw cards
Where the audit surfaces an active compromise (PAN already exposed, suspected breach), pivot to
```
incident-triage
```
— PCI breach response has specific timing and notification requirements (acquirer notification typically within 24 hours)
Brand-specific rules (Visa, Mastercard, Amex, Discover, JCB) layer on top of PCI DSS — for merchants with brand-specific obligations (e.g., Visa's Cardholder Information Security Program), consult the card brand's program documentation

本技能聚焦工程侧的审计与准备工作。最终合规证明（自我评估商家签署的SAQ，高等级商家由QSA生成的AoC）是独立流程
对于QSA主导的1级评估，本技能为QSA提供输入；不能替代QSA的独立评估
拒绝协助构建违反PCI DSS的流程——存储CVV、通过电子邮件传输PAN、绕过令牌化捕获原始卡数据
若审计发现主动泄露（PAN已暴露、疑似 breach），切换至
```
incident-triage
```
——PCI breach响应有特定的时间和通知要求（通常需24小时内通知收单行）
品牌特定规则（Visa、Mastercard、Amex、Discover、JCB）是PCI DSS的补充——对于有品牌特定义务的商家（如Visa的持卡人信息安全计划），请参考卡品牌的计划文档

References

参考资料

PCI DSS v4.0 —

pcisecuritystandards.org/document_library

PCI DSS v4.0 Quick Reference Guide — practitioner-focused summary
SAQ Instructions and Guidelines — for self-assessing merchants
PCI SSC FAQ database — official interpretive guidance
QIR / QSA / PFI / ASV registries — for approved assessor / vendor selection
Visa Cardholder Information Security Program (CISP) — Visa-specific layered requirements
Mastercard Site Data Protection (SDP) Program — Mastercard layer
Open Web Application Security Project (OWASP) — Req 6 substantive content
NIST SP 800-53 — control catalog that maps cleanly to many PCI requirements
"PCI Compliance" — Branden Williams, Anton Chuvakin — practitioner book, updated through v4.0