PCI DSS scope catalog - SAQ levels, PAN-storage rules, scope-reduction patterns

Pure-reference catalog of PCI DSS v4.0 scope reduction techniques + the testable scope boundaries. This is the catalog of WHY the boundary matters and what it makes testable; the SKILL.md steps are the workflow that verifies a given integration against it.

Scope reduction is the dominant strategy: keep card data off your systems entirely, so PCI compliance becomes minimal SAQ A instead of full SAQ D.

How to use this catalog

1. Identify your integration pattern - review the scope-reduction patterns below (hosted fields, redirect, tokenization, network segmentation) and match the one your payment integration uses.
2. Determine your SAQ level - use the SAQ table to confirm which Self-Assessment Questionnaire level applies given how cardholder data flows through your system.
3. Verify testable behaviours - cross-reference the Testable behaviours table and anti-patterns, then run the SKILL.md steps against the boundary.

SAQ levels (Self-Assessment Questionnaire)

Per pcisecuritystandards.org:

Choose A when feasible: PAN never touches your servers because the customer inputs it directly into a gateway-hosted iframe / element.

PAN storage rules

Per PCI DSS v4.0 §3.4: prohibited storage of:

• Full PAN cleartext anywhere
• Sensitive authentication data (full track, CVV/CVC, PIN/PIN block) post-authorisation
• More than first-6 + last-4 digits in any retained data (truncated)

Allowed:

• First-6 + last-4 digits (truncated PAN)
• Tokens issued by the gateway (e.g., Stripe pm_*)
• Encrypted PAN with strong key management (if you must store full PAN)

Tests for storage (PostgreSQL ~ regex operator):

-- Detect prohibited PAN patterns in any string column
SELECT * FROM <any_table>
WHERE  column ~ '^[0-9]{13,19}$'
    OR column ~ '^4[0-9]{15}$'
    OR column ~ '^5[1-5][0-9]{14}$'
LIMIT 10;
-- Expect: 0 rows

Scope-reduction patterns

1. Hosted fields / Elements

Per stripe.com/docs/payments/payment-element, docs.adyen.com/payment-methods/cards/web-drop-in, developer.paypal.com/braintree/docs/start/hosted-fields:

<!-- Stripe Element -->
<form>
  <div id="payment-element"></div>   <!-- iframe; PAN stays in Stripe's iframe -->
  <button>Pay</button>
</form>

PAN never reaches your JS or backend. The Element sends to Stripe directly; your server gets a token.

2. Redirect-to-gateway

Customer redirects to gateway-hosted page; pays; redirects back with a token / transaction ID.

PCI-friendly because PAN never on your domain. UX-tradeoff: slower, less branded.

3. Tokenization API

Backend-to-backend: customer submits PAN to gateway directly (via JS); gateway returns token; your code uses token.

Variants per gateway: Stripe setupIntent for saved cards; Adyen paymentMethods.storeDetails; PayPal Vault.

4. Network segmentation

If you must touch PAN, isolate it in a separate network with strict ingress / egress + monitoring. Reduces scope of the broader IT environment.

Testable behaviours

The SKILL.md steps run these adversarially; this catalog provides the rationale.

Anti-patterns

Limitations

• PCI DSS v4.0 is paywalled (cite by stable ID). Gateway docs paraphrase the relevant clauses.
• Scope is a moving target. Adding a new feature can pull PAN into your system; re-audit on architecture changes.
• PCI compliance ≠ PCI security. Compliance is a baseline; actual security needs more (threat modeling, pentest, etc.).
• Doesn't cover PA-DSS (Payment Application DSS for POS software).

Sources

• PCI DSS v4.0 (cite by stable ID): pcisecuritystandards.org/document_library/.
• Stripe Element (scope-reduction): docs.stripe.com/payments/payment-element.
• Adyen Drop-in: docs.adyen.com/payment-methods/cards/web-drop-in.
• Braintree Hosted Fields: developer.paypal.com/braintree/docs/start/hosted-fields.