For a product manager, PCI DSS is mostly a scoping question: the more of your product that stores, processes or transmits card data, or can affect its security, the more you must prove. Early design choices on payment pages and data flows decide how big that bill is.
Which version applies now?
The PCI Security Standards Council published PCI DSS v4.0.1 in June 2024 as a limited revision of v4.0. It fixed errors and clarified intent, with no new or deleted requirements. PCI DSS v4.0 was retired on 31 December 2024, and the requirements that v4.0 had marked as future dated became effective on 31 March 2025. If a customer cites v4.0, they mean the same requirement set.
What does the product decide?
Constructed example: a subscription app wants to take card payments. Two designs exist.
Design A: the app renders its own card form and posts card numbers to its own servers, which forward them to the payment processor. Servers, logs, backups and support tools can all end up holding card data. Each is in scope.
Design B: the card form is served by the payment provider, and your servers only receive a token. Far less of your environment touches card numbers. You still have responsibilities, but the assessment is narrower.
The standard does not tell you to pick B. It tells you what you must secure once you pick. Product managers choose, so the choice is theirs to make with eyes open.
Why do payment page scripts matter?
PCI DSS v4.0.1 includes requirements on managing scripts on payment pages, and its revision added applicability notes to clarify how they apply. The risk is simple. A third party script loaded on a checkout page, such as analytics or a chat widget, can run in the customer's browser while they type a card number. Product managers who approve a new marketing tag are, in effect, changing payment security.
A practical rule: keep a list of scripts allowed on pages that handle payment, with an owner and a reason for each, and review the list when anyone proposes a change.
What else lands on product?
MFA. v4.0.1 added an applicability note that multi-factor authentication for non administrative access into the card data environment does not apply to accounts authenticated only with phishing resistant factors. That is a nuance for your admin and support tooling.
Service providers. If you offer services to other businesses that handle their card data, requirement 12 and its notes on customer and third party service provider relationships matter. Your customers will ask who is responsible for which requirement.
Software. The PCI SSC also publishes standards for secure software and secure software lifecycles. These are separate programs from PCI DSS, so confirm with your acquirer or assessor whether any apply.
Where does supply chain fit?
Checkout code is assembled from libraries. A current inventory of the dependencies in your payment pages and services lets you answer which components you run and whether a published flaw matters. Safeguard provides SBOM generation and dependency scanning with reachability analysis. It does not make you PCI compliant. Your assessor or acquirer does that.
What to do
- Draw the card data flow end to end and mark every system it touches.
- Evaluate a hosted payment field or redirect to reduce scope, and record the decision.
- Maintain an approved script list for payment pages with owners.
- Add a review step for any new third party tag or SDK on checkout.
- Confirm your merchant or service provider status with your acquirer.
- Ask your assessor for the PCI DSS v4.0.1 summary of changes and read the parts that concern your product.
Quick check
Is PCI DSS v4.0 still in force?
No. The PCI SSC retired v4.0 on 31 December 2024. v4.0.1 is the active version, and future dated requirements took effect on 31 March 2025.
Does using a hosted payment page remove PCI obligations?
No. It can reduce scope, but you still have responsibilities. Confirm the right self assessment type with your acquirer.
Sources
Last reviewed: 18 October 2026.
