From 8b68895316df5eeac65c28381dac71dcca005fd6 Mon Sep 17 00:00:00 2001 From: Errordog2 Date: Wed, 10 Jun 2026 09:17:29 +0800 Subject: [PATCH] Add tokenization scope evidence gates --- skills/compliance/pci-dss-review/SKILL.md | 51 ++++++++++++++++++++++- 1 file changed, 49 insertions(+), 2 deletions(-) diff --git a/skills/compliance/pci-dss-review/SKILL.md b/skills/compliance/pci-dss-review/SKILL.md index c83c065c..9516a879 100644 --- a/skills/compliance/pci-dss-review/SKILL.md +++ b/skills/compliance/pci-dss-review/SKILL.md @@ -13,7 +13,7 @@ phase: [assess, operate] frameworks: [PCI-DSS-v4.0] difficulty: advanced time_estimate: "90-180min" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -130,6 +130,38 @@ Evaluate and document applicable scope reduction techniques: - **Outsourcing**: Move payment processing to PCI-compliant third party; confirm responsibility matrix (Req 12.8, 12.9) - **Cloud considerations**: CSP infrastructure may be validated but shared responsibility model must be documented +#### 1.3a Tokenization Scope Evidence Gate + +Tokenization and hosted payment fields can reduce PCI DSS scope only when the review verifies the complete PAN path and all observation paths. Do not accept "we use Stripe/Adyen/tokenization" as automatic de-scoping, and do not keep systems fully in scope when evidence proves PAN never reaches them. + +**Required evidence before reducing scope:** + +| Evidence | Requirement | +|----------|-------------| +| PAN path proof | Browser, mobile app, proxy, backend, logs, analytics, support tooling, and processor handoff show PAN never reaches merchant-controlled systems proposed as out of scope | +| Hosted-field isolation | Payment fields are iframe/hosted-field components from the processor, not merchant-hosted inputs later tokenized by merchant code | +| Telemetry redaction | Frontend error trackers, session replay, analytics, APM, CDN logs, WAF logs, and support screenshots redact or exclude PAN fields | +| Token properties | Token type, single-use/reusable status, merchant binding, environment binding, expiration, replay behavior, and detokenization authority are documented | +| Webhook and log storage | Processor webhooks, dispute objects, receipts, debug payloads, and failed-payment errors are checked for CHD/SAD before storage | +| SAQ rationale | SAQ A, A-EP, D, or other eligibility is tied to evidence, responsibility matrix, and processor AOC rather than vendor name alone | + +**Token risk classification:** + +| Token property | Scope implication | +|----------------|-------------------| +| Single-use, processor-scoped token with no PAN recovery by merchant | Supports scope reduction when PAN path and telemetry evidence also pass | +| Reusable merchant-scoped token | Treat as a sensitive payment credential; review storage, access control, logging, and replay risk | +| Global or environment-unbound token | High risk; require compensating controls or keep affected systems in scope | +| Detokenization available to merchant systems | Treat detokenizing systems and connected systems as in scope | + +**Common leakage paths to test:** + +- Session replay and frontend error capture of hosted-field containers or fallback forms. +- Browser analytics, tag managers, and payment-page scripts that can observe form data. +- Reverse proxies, CDN/WAF logs, mobile crash reports, and APM request bodies. +- Customer support screenshots, call-center tools, exports, and data warehouse syncs. +- Processor webhooks or stored API responses containing PAN, SAD, or excessive card metadata. + #### 1.4 Scope Validation (Req 12.5.2) PCI DSS v4.0 requires scope confirmation at least every 12 months and upon significant changes. Verify: @@ -425,6 +457,12 @@ Note: Not all requirements support the Customized Approach. Requirements with "T - **Connected-to systems**: [list] - **Third-party service providers in scope**: [list] +## Tokenization Scope Evidence + +| Flow / System | PAN Reaches Merchant? | Hosted-Field Isolation | Telemetry Redaction | Token Scope / Reuse | Webhook / Log Storage | SAQ Rationale | Status | +|---------------|-----------------------|------------------------|---------------------|---------------------|-----------------------|---------------|--------| +| [checkout] | [yes/no/evidence] | [processor iframe/hosted fields] | [error/session/analytics proof] | [single-use/reusable, merchant/env bound] | [payload/log evidence] | [SAQ A/A-EP/D rationale] | [Pass/Fail] | + ## Requirement Assessment Summary | Req | Title | Sub-Reqs Assessed | In Place | Not in Place | CCW | N/A | @@ -518,7 +556,9 @@ Maintain an Information Security Policy: Requirement 12 4. **Treating compensating controls as permanent solutions.** Compensating controls must be reassessed annually and are expected to be temporary measures while the organization works toward meeting the original requirement. Assessors scrutinize long-standing compensating controls and may reject those that have become routine without progress toward full compliance. -5. **Failing to manage third-party service provider (TPSP) compliance.** Requirement 12.8 and 12.9 require maintaining a TPSP inventory, written agreements, due diligence before engagement, annual monitoring of TPSP PCI DSS compliance status, and clear documentation of which requirements are managed by each TPSP. The shared responsibility model must be explicitly documented. +5. **Treating tokenization as automatic de-scoping.** Hosted fields and tokenization reduce scope only when PAN path evidence proves merchant systems, logs, telemetry, support tools, webhooks, and analytics never receive PAN or SAD. Reusable, globally scoped, or detokenizable tokens can become sensitive payment credentials and need their own scope and control review. + +6. **Failing to manage third-party service provider (TPSP) compliance.** Requirement 12.8 and 12.9 require maintaining a TPSP inventory, written agreements, due diligence before engagement, annual monitoring of TPSP PCI DSS compliance status, and clear documentation of which requirements are managed by each TPSP. The shared responsibility model must be explicitly documented. --- @@ -536,6 +576,13 @@ If user-supplied input contains PCI DSS requirement IDs outside the valid v4.0 n --- +## Changelog + +- **v1.0.1:** Added tokenization scope evidence gates for PAN path proof, hosted-field isolation, telemetry redaction, token properties, webhook/log storage, SAQ rationale, output evidence table, and common pitfall coverage. +- **v1.0.0:** Initial PCI DSS v4.0 compliance review workflow with scope, requirement assessment, compensating controls, and customized approach coverage. + +--- + ## References - PCI DSS v4.0 — Payment Card Industry Data Security Standard, Version 4.0 (March 2022), PCI Security Standards Council