PCI DSS 合规等级：含义与如何达标

PCI DSS 合规等级一览

商户等级 1–4 概览

支付卡行业数据安全标准（PCI DSS）根据年度卡交易量和整体风险暴露程度，将组织划分为四个商户等级，以确定适当的验证要求。了解自身的合规等级对于履行义务并维持恰当的安全措施至关重要，以确保仍具备处理银行卡支付的能力。

等级 1 商户处理的交易量最高，通常每年超过 600 万笔交易，并面临最严格的验证要求。等级 2 商户管理的交易量很高，但低于等级 1，通常每年在 100 万至 600 万笔卡交易之间，并通过带有额外监督的自我评估进行验证。等级 3 商户通常是中型市场的电子商务企业，一般处理 2 万至 100 万笔卡交易，并通过自我评估进行验证。等级 4 商户是交易量最低的小型企业，年电子商务交易量少于 2 万笔或年总交易量最多 100 万笔，并以自我评估方式进行验证，合规义务最为简化。

需要注意的是，代表其他组织（服务提供商）处理或存储信用卡数据的组织，会采用一套独立的“两层”验证体系来满足验证要求。该要求与商户（merchant）验证不同，并取决于年度信用卡交易量。一级（Level 1）服务提供商每年处理超过 300,000 笔交易，或为第三方存储持卡人数据。二级（Level 2）服务提供商每年处理少于 300,000 笔交易。

你的等级为何重要

你的合规等级将直接决定你的组织必须如何验证合规性，以及维持合规所需投入的工作量。商户（merchant）等级定义了：一个组织是否应通过合格安全评估员（Qualified Security Assessor）完成合规报告（Report on Compliance, ROC），或提交自我评估问卷（Self-Assessment Questionnaire, SAQ）；同时也规定了组织必须保存的合规证据的深度与类型。

较高的商户（merchant）等级需要更多的文档化证据，并对安全控制措施进行定期测试。例如，一级（Level 1）商户需要由合格安全评估员（Qualified Security Assessor, QSA）签署的正式合规声明（Attestation of Compliance, AOC）。尽管合规是一项持续义务，但商户等级还会影响评估需要多频繁进行，例如由获准扫描厂商（Approved Scanning Vendor）进行的季度网络扫描。信用卡品牌和收单银行（acquiring banks）可能会根据合规等级施加额外要求。必须准确识别并维持你的合规等级，以满足监管期望、避免处罚，并高效展示在保护持卡人数据方面所需的尽职调查。

卡片品牌如何确定您的 PCI DSS 合规等级

交易量阈值

卡片品牌主要使用年度刷卡交易量来确定一个组织的合规等级。这些阈值有助于确定组织必须遵循何种验证与报告结构，才能维持 PCI DSS 合规：

• 等级 1： 每年在所有渠道（线下门店和线上）处理超过 600 万笔交易的商户
• 等级 2： 每年处理 100 万至 600 万笔交易的商户
• 等级 3： 每年处理 20,000 至 100 万笔电子商务交易的商户
• 等级 4： 每年处理少于 20,000 笔电子商务交易的商户，或所有渠道合计交易量不超过 100 万笔的商户

1 级商户通常需要由合格安全评估员（Qualified Security Assessor，QSA）进行年度现场评估；而较低等级则需要使用问卷（SAQ）进行自我评估，并满足诸如每季度进行网络扫描等额外要求。

漏洞（数据泄露）与事件升级

年度交易量是确定合规等级的首要因素，但并非唯一因素。若卡组织认为存在对支付生态系统的高风险，它们保留将任何商户手动升级至 1 级的权利。如果商户遭受了导致持卡人数据受损的数据泄露或安全事件，卡组织可以在不考虑交易量的情况下将该商户升级至 1 级。此外，如果卡组织识别出系统性漏洞，例如安全控制不足、缺乏合规证据，或基于交易模式、行业类型或欺诈历史形成的高风险画像，它们可以强制要求商户满足 1 级的验证要求。

收单银行的作用

尽管卡组织制定了全球安全标准，但在分配 PCI DSS 级别方面，收单银行拥有最终权威。收单银行负责确保组织的正确商户等级，并通过审查实际交易数据以及任何卡组织特定标准来确认合规级别。收单方会收集并审核合规验证文件，例如 Attestation of Compliance、SAQ 或 Reports on Compliance，并且可以在最低卡组织标准之外施加额外要求。Visa、Mastercard、Discover 和 American Express 等不同卡组织对 PCI 合规级别的门槛略有不同。使用多种品牌处理业务的商户必须遵循所有卡组织的合规级别，而收单银行会对这些要求进行协调并执行。

四个商户等级：要求与证据

1 级：最高保证

符合条件的是： 每年在所有渠道合计处理超过 600 万笔银行卡交易的商户（包括刷卡在场、电子商务、邮寄或电话订单），并涵盖所有交易类型，如购买、退款、贷记以及授权。此外，任何发生过涉及数据泄露/数据被破坏的数据泄露事件的商户，或无论交易量多少，只要卡组织基于风险评估、先前的合规违规情况，或呈现出重大风险的商业模式，将其指定为 1 级的商户也同样适用。

验证要求： PCI DSS Level 1 合规代表最高的风险暴露，因此需要最严格的验证：

Level 2：默认情况下为高交易量且不使用 QSA

符合条件的对象： Level 2 商户（例如中到大型的电商零售商、区域性零售连锁店，以及多地点的酒店和餐厅）风险较高，但除非收单银行另有指示，通常允许其进行自我验证。

验证要求：

注：收单银行或卡组织可能会根据风险状况、已发生的安全漏洞/入侵历史、复杂的基础设施或合规态势较差等因素，要求二级商户提供完整的 ROC，并由 QSA 主导开展评估。

等级 3：面向中型市场的电子商务重点

符合条件者： 每年处理 20,000 至 100 万笔电子商务交易的商户，尤其是那些拥有显著线上业务覆盖、并存在 Card-Not-Present（CNP）场景的商户。

验证要求： 三级商户通常包括发展中的电子商务业务、集成支付功能的 SaaS 公司、数字化市场平台以及基于订阅的业务。他们必须提供以下验证：

等级 4：小型商户基线

符合条件者： 年度内处理的电子商务交易少于 20,000 笔，或所有渠道合计交易总数最多为 100 万笔的商户，可符合等级 4 的合规要求。

验证要求： 等级 4 的商户通常包括小型企业、本地零售店、单店酒店和餐厅，以及小型在线零售商。他们必须完成以下验证：

常见误解： Level 4 商户有义务满足所有适用的 PCI DSS 要求，例如通过防火墙和加密技术来维护安全网络、保护持卡人数据（cardholder data）、进行漏洞管理（vulnerability management）， 访问控制、持续监控以及网络测试。等级只影响验证方法，而不影响安全义务。

服务提供商的 PCI DSS 等级

两级服务提供商模型

服务提供商在支付处理生态系统中发挥着重要作用，因为他们代表商户存储、处理或传输持卡人数据（cardholder data），并可能影响持卡人数据的安全性。虽然商户会被划分为四个合规等级，但服务提供商由于在多个客户之间承担共同责任（shared responsibility）角色，会遵循两级分类模型，并且需要满足严格的验证要求。

Level 1 服务提供商： 任何代表商户处理、存储或传输每年超过 300,000 笔卡交易的组织，或任何由支付卡品牌特别指定的组织（不论交易量）。他们必须接受由用于 ROC 的合格安全评估员（Qualified Security Assessor，QSA）进行的现场审计（on-site audit），提交 AOC，进行季度 ASV 扫描，并执行强制性的年度渗透测试。该类别的服务提供商通常包括支付网关（payment gateways）、托管服务提供商（managed service providers）以及云与主机托管提供商（cloud and hosting providers）。

2级服务提供商： 任何每年处理、存储或传输的总交易量少于300,000笔的组织，且未被卡组织指定为2级服务提供商。2级服务提供商必须通过年度《服务提供商 SAQ D》完成验证要求，以覆盖所有PCI DSS要求，提交AOC，提供季度ASV扫描报告，并执行年度渗透测试。

谁来验证服务提供商

服务提供商的合规性可以通过多种机制进行验证，具体取决于合同义务和风险考虑：

• 自我验证 vs. QSA： 1级提供商必须由外部QSA进行验证，而2级提供商则可以使用《SAQ D》进行自我验证。然而，根据所提供服务的敏感性，其客户、商户或卡组织仍可能要求提供由QSA签署的ROC。在某些情况下，由于共享责任的性质，商户的QSA会在商户自身的PCI评估过程中审查服务提供商的控制措施
• 卡组织合规注册名录： 像Visa和Mastercard这样的知名卡组织会维护合规服务提供商的官方名单。鼓励商户并且通常要求商户只使用这些服务提供商
• 商户责任： 商户必须维护其服务提供商名单，与其签订书面协议，并负责至少每年一次核实其服务提供商的合规状态。如未使用合规的服务提供商，不会转移 PCI 义务；商户仍需负责保护持卡人数据

为你的环境选择合适的 SAQ

SAQ 选择矩阵

自我评估问卷（Self-Assessment Questionnaires）是由 PCI Security Standards Council（PCI SSC）定义的验证工具，用于帮助商户和服务提供商自行评估其是否符合 PCI DSS。正确的 SAQ 取决于商户如何接收、处理、传输和存储持卡人数据。

避免范围蔓延（scope creep）的技巧

选择错误的 SAQ 类型可能会增加合规负担，造成安全漏洞，并导致审计被拒。

梳理支付流程： 记录持卡人数据进入贵组织的每个位置、其如何被处理与存储，以及它从环境中退出的位置。识别参与数据采集与处理的所有系统与服务，包括备份系统、日志或归档。

了解持卡人数据的接触点： 如果贵组织基础设施的任何部分接触持卡人数据，可能会将 SAQ 类型从较轻的 SAQ 提升为 SAQ D。只要有任何系统存储、处理或传输持卡人数据，就会影响持卡人数据的安全性。同时也要考虑能够访问持卡人数据环境的系统，以及与 CDE 位于同一网络段的系统。

使用分段： 合理的网络和系统分段可以缩小 PCI DSS 的范围，从而降低满足合规要求所需的工作量。使用防火墙和 VLAN 将支付终端或 POS 系统与企业网络的其他部分隔离。始终记录变更，并定期验证其有效性，以支持持续合规。

咨询 QSA： 如果商户同时提供线下门店和电子商务服务，可能需要完成多个 SAQ，或仅完成一个 SAQ D。让能够帮助避免过度或不足合规工作的 QSA 参与始终是个好主意。

从范围到证据：不同级别审计员期待什么

范围界定与文档编制

评估 PCI DSS 合规性的审计员会首先关注范围验证和基础性文档，因为所有相关证据都取决于对持卡人数据环境（Cardholder Data Environment, CDE）的精确定义。

准确的 CDE 范围界定： 审计员要求清晰识别所有存储、处理或传输持卡人数据的系统、网络和位置。必须对 CDE 的明确边界进行文档化。需要说明哪些系统在范围内（例如销售点终端、支付网关和数据库），哪些系统不在范围内，并提供排除证据，例如网络分段和防火墙规则。CDE 范围界定至少每年应进行一次复核，并且在 CDE 或相关基础设施发生任何重大变更后也要复核。

数据流图： DFD 必须展示从入口点到内部流转、存储以及出口点的端到端持卡人数据流动。DFD 必须同时包含高层级与详细的数据流，并附简要说明；要标注已加密与未加密的路径，并将其映射到带有 IP 地址和主机名的真实设备。

网络分段文档： 如果将某些服务器和设备声明为超出范围（out of scope），则必须在文档中包含技术证据，以证明 CDE 未受到影响。例如：用于限制 CDE 与非 CDE 网络之间网络流量的防火墙配置、用于在逻辑上分隔网络的 VLAN 配置，以及年度渗透测试结果。

系统清单： 对于任何可能影响 CDE 的项目，都必须记录一份完整且最新的 IT 资产清单，例如服务器、工作站、网络设备和终端，并包含已安装的操作系统、应用程序、版本以及补丁级别。应实施变更管理机制，以便将日志作为系统更新、补丁和硬件退役的证据。

时间同步： 所有系统必须使用网络时间协议（Network Time Protocol，NTP）保持准确且同步的时间，因为时间同步对日志关联和计算机取证分析至关重要。文档中应包含 NTP 服务器配置、时间源以及同步频率设置，并附上支持日志，以证明时间同步已成功完成。

按级别划分的关键证据

不同的报告级别需要不同类型和不同深度的证据，但核心证据（artifacts）保持一致；仅验证方法会根据商户级别而变化。以下是在所有级别中审计人员普遍期望的常见证据：

• 信息安全政策： 完整、可核查的 安全政策 覆盖所有适用的 PCI DSS 要求，包括可接受使用政策、数据保留政策、加密密钥管理机制、远程访问政策、变更管理政策、物理安全以及事件响应程序
• 访问控制文档： 用户 访问策略 以及显示谁可以访问哪些系统和数据的报告、基于角色的访问控制（RBAC）的实施情况，以及角色和权限是否遵循最小特权原则。对 CDE 中所有访问路径强制实施多因素认证（MFA），采用带会话录制的特权访问管理机制，并对对 CDE 的管理访问保留完整的审计追踪记录
• 文件完整性监控（FIM）日志： 证明对关键系统文件和配置进行监控以发现未经授权的更改的证据，包括 FIM 告警和报告、基线配置定义，以及对合法更改的调查记录
• 用户访问审查： 对用户账户和管理账户进行定期审查，包括由部门负责人签字确认的报告、对过度权限的整改证据，以及对已终止用户的访问权限移除记录
• 漏洞扫描结果： 由内部扫描工具和外部 Approved Scanning Vendors（ASV）按季度出具的报告，表明未发现高风险漏洞；或在发现漏洞后已进行修补，且重新扫描结果显示漏洞已得到解决
• 渗透测试报告： 对内部或外部渗透测试结果的正式报告，包括网络层测试、应用层测试以及分段（segmentation）验证。发现应当清晰识别带有严重性评级的漏洞，并在重新测试后完成补救措施（remediation）的验证
• 事件响应流程： 用于处理安全事件的文档化计划，包括如何对事件进行分类、升级路径、响应团队的角色与职责、沟通协议、取证证据收集程序以及业务连续性措施
• 变更管理记录： 对系统和应用程序所做变更的完整审计追踪，包括变更请求表单、风险评估表单、批准记录、上线后的验证，以及执行紧急程序的理由（justifications）

Netwrix 审计和合规能力帮助组织为所有 PCI DSS 要求生成证据，从准确界定范围以及 数据发现 到访问控制和多因素身份验证， privileged access management 以及广泛的日志记录和持续监控。自动化的数据发现能力可查找并分类 Primary Account Numbers (PAN) 以及其他敏感的持卡人数据。数据最小化有助于识别已过时或保存过度的持卡人数据，从而支持安全删除流程。定期的用户访问审查活动会通过贯彻最小特权原则来限制对 CDE 的访问，并自动化访问证明（access attestation）。Netwrix 解决方案能够捕获全面的 审计追踪 ，涵盖用户活动、系统变更和访问事件，并具备将这些日志和合规报告导出以满足 PCI DSS 要求的能力。

等级如何变化：上升或下降的触发条件

级别变更的触发因素

PCI DSS 的合规等级并非一成不变；它会根据业务活动、风险事件，或由卡组织或收单银行做出的决定而上升或下降。商户和服务提供商的合规等级主要由每年的交易量决定。如果在节日期间的营销活动显著提高了交易量，并跨过 600 万笔交易的门槛，收单银行将通知商户，他们现在必须满足 PCI DSS Level 1 合规要求并进行相应报告。

同样，如果商户的交易量显著下降，他们可能有资格降低合规等级，从而减少审计的复杂性和成本。兼并与收购（M&A）可能会将多个商户的交易量合并，而通过收购继承的新的支付渠道或品牌也会影响总交易笔数。

任何安全事件或数据泄露都可能促使卡组织或收单银行采取更严格的合规行动：合规等级会被提高，并且在将合规等级恢复到正常之前，可能需要开展取证调查以及配套的补救工作。如果商户开始使用新的第三方服务提供商，或更改外包的支付处理方式，也会影响其合规等级。例如，从外包支付页面切换到部分托管模式可能会提高合规义务；而从自营的支付管理服务切换到外包支付处理，则可能简化合规义务。卡组织保留基于高欺诈率、反复不合规或高风险商业模式来重新分类任何商户或服务提供商的权利。

治理最佳实践

合规并不是一次性事件；它是一个持续的过程。为避免突发失败，组织必须将 PCI compliance level 所要求的控制措施和政策整合到其业务治理模型中。

避免意外： 通过按季度或按月跟踪交易量，商户可以在事情发生之前预测何时可能达到下一个级别。在发生安全漏洞事件时，请保留用于重新分类的交易证据，例如新增渠道的数据信息流图、事件日志以及补救记录。

验证规划： 从 Level 2 升级到 Level 1 需要聘请 Qualified Security Assessor (QSA)，并会产生为保护 CDE 的技术成本。为确保合理的预算以及诸如人员和设备在内的资源得到正确分配，这些变化需要周密且高效的规划。

主动沟通： 与收单银行（acquiring bank）保持透明的合作关系，这有助于在合规级别出现意外变更时，就安全控制措施的实施时间表进行协商。启动新的电子商务平台、进行令牌化（tokenization）变更或更换支付网关之前，务必提前通知收单方（acquirer）。

按级别划分的常见陷阱及如何避免

1级的常见陷阱

薄弱的 Privileged Access Management： 1级持卡人环境及其相关基础设施需要严格的访问控制，以减少攻击面。全面的 access management 是保障持卡人数据安全的关键因素。常见问题包括使用共享的管理员账号、未为管理或服务账号以及远程访问实施 MFA、过度的常驻权限、缺少用户访问复核活动、不遵循最小权限原则的基于角色的访问控制（RBAC），以及缺少对管理员活动的监控。

日志不完整： 日志在数据泄露事件的取证调查以及验证安全控制效率方面发挥着至关重要的作用。常见问题包括缺少身份验证轨迹，例如身份验证失败的重要事件、权限提升或数据访问等。日志已收集，但未在集中式平台中进行汇总，以供自动分析和存储。日志虽然存在，但无法根据与特定账号绑定的唯一 ID 来区分事件轨迹。

分段（隔离）有效性： 常见问题包括：在缺少“不能访问 CDE”的证据情况下，将网络标记为超出范围；没有提供年度渗透测试报告；以及配置错误的防火墙规则可能导致允许网络访问。

变更管理证据： 常见问题包括：未经过适当批准就实施紧急变更的记录；实施后未评估 PCI 影响；在未做好妥善备份的情况下升级或替换硬件和软件；以及在合法的变更管理事件发生后没有安全态势评估报告。

2 到 4 级的常见陷阱

SAQ 选择错误： 商户往往会在未意识到自身环境实际上需要更详细且相关的技术评估时，选择最容易或最短的 Self-Assessment Questionnaire (SAQ)。选择不正确的 SAQ 类型会导致合规评估不完整，尤其是在对支付流程的理解存在偏差并且文档中对支付流程的描述不准确的情况下。进行 SAQ 选择之前，请务必梳理完整的支付卡数据流，记录 PAN 传输、处理和存储的位置，并核实第三方处理器的集成方式。若有疑问，请务必查阅 SAQ 选择指南或聘请 QSA 协助完成 SAQ 选择流程。

错过季度 ASV 扫描： 漏洞扫描必须由 Approved Scanning Vendor (ASV) 每 90 天执行一次。商户往往以为这是年度任务，或未能在维持合规状态所要求的期限内完成对扫描中识别出的漏洞的整改。请务必在每个季度的第一个月安排扫描，以便有充足时间对已识别的漏洞进行整改，并在整改工作完成后重新扫描，在同一季度结束前获得通过报告。请在到期日前 2 到 3 周设置日历提醒，跟踪整改截止期限（高风险漏洞为 30 天），保留扫描结果与整改情况的文档化证据，并且季度扫描仅使用 PCI SSC 批准的扫描服务商。

日志和导出中出现 PAN： 主账号号码（Primary Account Number，PAN）信息可能泄露到不应存储它的地方，例如应用程序日志、客户服务聊天记录、电话录音、CRM 导出文件，或会计部门使用的 CSV 导出文件。使用自动化 data discovery tools 在至少每年一次的频率下扫描基础设施中是否存在未加密的 PAN。确保软件解决方案对卡号进行遮蔽，只显示前 4 位或后 4 位。检查导出功能和报表工具，以便截断（截取）PAN；培训开发人员采用安全编码实践，避免在调试日志中存储敏感信息，并定期审查日志以识别任何未加密的敏感信息。

Netwrix 如何在各个层级加速 PCI DSS

要求 3：保护已存储的持卡人数据

Netwrix Data Security Posture Management 解决方案可帮助组织在混合环境中执行自动化的数据发现与分类，以查找主账号（Primary Account Numbers，PAN）以及其他敏感的持卡人数据。数据分类采用复合术语处理和统计分析，而不是简单的关键词匹配。自动化脱敏（redaction）功能可在没有业务需求需要展示时对卡号数字进行遮蔽。数据最小化和保留期限跟踪表明：仅存储必要的持卡人数据，不会保留不必要的数据。自动化工作流允许组织将敏感数据隔离在不安全的位置，并帮助从全局访问组中移除权限。

要求 7 和 8：访问控制与身份验证

Netwrix Identity Governance 解决方案可让组织全面了解本地部署和云平台中用户、服务账号以及管理员账号的权限。特权证明（Privilege attestation）报表用于对用户特权进行认证，从而执行最小特权原则，并确保对持卡人环境的访问严格基于角色且有据可查。Identity governance 解决方案会自动化用户身份的全生命周期，确保每个人都有唯一 ID，所有活动都以该唯一 ID 进行跟踪，并且在发生可疑活动或离职（termination）时可立即撤销访问权限。 Privileged account monitoring 功能使组织能够监控并记录 CDE 中的特权会话，以发现任何未经授权的更改或数据外传（exfiltration）尝试。

要求 10：日志记录与监控

Netwrix Auditor 可在包含文件系统、Active Directory 和云服务在内的混合基础设施中提供统一的审计（auditing）与活动监控能力。变更跟踪（Change tracking）解决方案集成文件完整性监控（File integrity monitoring，FIM）功能，用于检测对关键系统文件和安全配置的未经授权变更，并在日志数据被修改时生成告警。Netwrix 解决方案提供可导出的、可用于审计的日志和报告，作为 Attestation of Compliance 和 Report on Compliance 提交中的证据，从而显著减少审计准备时间。

要求 6 和 11：确保系统安全与测试

Netwrix Change Tracker 会持续跟踪系统配置，检测偏离安全基线（security baselines）的错误配置（misconfigurations），并确保服务器、终端（endpoints）和网络设备始终保持安全。通过对比配置变更前后的数值，变更跟踪（Change tracking）能够清楚展示发生了什么变化、何时变化以及由谁完成，从而形成针对 CDE 的全面、基于证据的报告。 这些基于证据的报告支持安全的系统维护、对配置一致性的验证，以及为满足 PCI 扫描与测试要求而进行的持续测试。

PCI DSS Level 1 深度剖析（面向企业和服务提供商）

Level 1 的更高要求

Level 1 的商户和服务提供商面临更高强度的审查，因为他们对支付生态系统的风险最高。在 Level 1 情况下，组织不仅需要满足 PCI 合规的 12 项核心要求，还应超出这些要求；他们必须实施增强型管控、记录在案的纪律要求以及持续监控，以便妥善满足验证要求。

抽样策略注意事项： 当企业拥有数百或数千个基础设施组件时，QSA 无法逐一评估每一个组件。PCI DSS 不要求使用某一种特定的抽样公式，但 Level 1 审计本质上需要对最关键的系统进行有代表性的抽样，例如 CDE、分段/隔离（segmentation）控制、访问控制以及日志记录。通过将配置相同的系统进行分组来标准化抽样。抽样必须包括处理持卡人数据（cardholder data）的所有业务流程以及所有地理位置。保留抽样方法的文档，包括：总体（population）定义、选择标准、统计依据（statistical justification），以及样本与具体 PCI 要求之间的可追溯性（traceability），并提供证据以向 QSA 证明完整性。如抽样发现存在失败（failure），则应扩大测试范围或评估整个系统类别。Level 1 实体应避免假设单个“代表性系统”即可覆盖整个类别。

扩大渗透测试范围： Level 1 实体必须每年将内网、边界（perimeter）网络、VPN、云基础设施、API 和端点纳入测试范围，并且在网络发生任何重大变更时也要重新纳入，例如新增硬件、软件升级或迁移到新的云平台。至少需要再次进行定向（targeted）的渗透测试。组织必须通过防火墙规则、VLAN 隔离等证据来证明网络分段（segmentation）。认证（authentication）与授权（authorization）流程必须从内部用户和外部攻击者两个视角进行评估。完成整改后，需要进行定向的复测，以确认漏洞已得到修复。

证据存储库的最佳实践： Level 1 审计可能需要成千上万份证据。组织应从电子表格转向合适的 Governance, Risk and Compliance (GRC) 工具，以借助集中式数据存储库自动化整个流程。使用自动化工具为每一项要求生成基线材料（baseline artifacts），例如：策略（policies）、配置文件（configuration files）、日志（logs）以及流程（procedures）。按照 12 项 PCI DSS 要求及其子要求组织证据。保留所有配置和策略的带日期版本、基于角色的访问权限细节、季度扫描报告、日志分析、文件完整性监控告警、防火墙规则以及加密实现（encryption implementations）。

持续合规： 与较旧的“特定时间点”合规不同，PCI DSS 强调持续安全。对于 1 级组织，持续监控必须内置到每一个业务流程中。除按季度进行外部 ASV 漏洞扫描以及内部漏洞扫描外，还必须每日审查日志，或至少每周两次审查，并实施 SIEM 工具以进行汇总分析。应部署用于文件完整性监控的实时告警生成机制。对于 CDE 中的每一次变更，都必须建立包含文档化批准的正式变更管理流程。按月触发用户访问审查活动、审查防火墙和路由器规则，并验证服务提供商的合规情况。

保持有条理的文档： 组织不能等到审计季节；必须在全年范围内为全部 12 项 PCI DSS 要求定期创建和更新文档，并实施适当的版本控制以及摘要形式的变更日志。QSA 的首要任务往往是确定审计范围。如果他们发现某个系统或要求没有被记录，那么审计很可能会被推迟或直接失败。

与 QSA 合作

1 级验证需要外部的 Qualified Security Assessor（QSA）。然而，QSA 不应被视为审计人员，而应视为降低风险的合作伙伴。要实现成功的配合，需要提前准备，并进行高效协作，以最大化该流程的产出。

提前准备证据： 组织必须使用 ROC 模板开展内部评估，以识别差距。创建一份清单，将每项要求与相应的证据对应起来。准备一份完整且最新的资产清单，并附上数据流图；同时，范围界定文档必须包含详细的网络分段信息，以证明所选范围的合理性。

建立清晰的沟通渠道： 指定一名作为 QSA 协调的单一联络人。针对每个要求领域，识别负责详细说明的主题专家。设置首选沟通渠道，例如电子邮件、视频会议以及文档门户。开展审计前的走查（walkthrough）会议，定义在证据请求出现争议或延误时的升级路径，并确定证据请求的周转时间，例如 48 或 72 小时。

及时处理发现的问题： 如果 QSA 在审计过程中发现了差距（gap），请尽量在他们仍在现场时立即进行整改。这样往往可以使最终 ROC 获得通过结果，而不是被标记为不符合（non-compliance）。整改流程应当是正式的，包括确认已收到并理解相关发现，对为何发生不符合的原因进行根本原因分析，并记录为整改该问题而采取的行动，同时提供诸如截图、配置细节以及新策略等证据。

下一步：验证您的 PCI DSS 合规等级

行动计划

了解您的商户或服务等级对于 PCI DSS 合规至关重要。评估正确的等级之后，后续的合规路径重点在于验证、证据以及持续监控。

准备好在任何级别上简化 PCI DSS 合规了吗？请访问 Netwrix PCI DSS solution page ，查看已映射的报告样本，并了解我们的数据安全与审计能力如何加速您的验证流程。