pci-dss-scope-reference

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.

This skill is distinct from a scope checker that verifies the boundary holds in code. This skill explains what the boundary IS and the test surface it creates.

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 to confirm the scope boundary is preserved and hand off specific tests to pci-dss-control-test-author.

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

A pci-dss-control-test-author runs these adversarially. This skill provides the catalog.

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).

References

• 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.
• Companion catalogs: 3ds-test-flow-reference, payment-flow-states-reference.
• Adversarial validator: pci-dss-control-test-author (in the qa-compliance plugin).
• Consumed by: stripe-test-cards-and-webhooks, adyen-test-mode, paypal-sandbox, braintree-test-cards.