Skip to content

Add tokenization scope evidence gates #2237

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Errordog2 wants to merge 1 commit into
base: main
Choose a base branch
from
+49 −2
Open

Add tokenization scope evidence gates #2237

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 49 additions & 2 deletions skills/compliance/pci-dss-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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:
Expand Down Expand Up @@ -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 |
Expand Down Expand Up @@ -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.

---

Expand All @@ -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
Expand Down