Your Payment Processor Didn't Take You Out of PCI DSS 4.0 Scope

In board decks and vendor questionnaires, PCI compliance tends to show up as a single line: "PCI DSS compliant, SAQ A, since [year]." The certificate is real. The Self-Assessment Questionnaire was genuinely completed and genuinely attested. What that line does not tell the board, the acquirer relationship manager, or the enterprise customer running due diligence is how much of the actual technology stack the attestation covers.

That gap is not new. What is new, as of PCI DSS version 4.0 and its 4.0.1 clarification, is that the gap has started to intersect directly with code that engineering teams write, ship, and forget about — JavaScript loaded on a checkout page, the authentication flow into an admin console, and the frequency at which someone is supposed to re-examine decisions that were made once, years ago, and never revisited. A company can be fully within the letter of its SAQ and still be carrying meaningful, untested risk in exactly the systems its engineers assumed were somebody else's problem.

This article works through what PCI DSS 4.0 and 4.0.1 actually require, verified against the PCI Security Standards Council's own publications rather than secondary summaries, and then translates that standard into what an engineering and QA organization actually needs to build, test, and monitor — with particular attention to the assumption that using a payment processor or a tokenization service removes a company from scope. That assumption is sometimes correct, often partially correct, and occasionally wrong in ways that only surface during a due-diligence review, a QSA's follow-up questions, or — worse — a script-based skimming incident on a checkout page nobody had looked at closely since launch.

What PCI DSS 4.0 Actually Changed, and When It Actually Started to Bite

PCI DSS 4.0 was published by the PCI Security Standards Council (PCI SSC) on March 31, 2022, replacing version 3.2.1, which was formally retired on March 31, 2024.¹ On June 11, 2024, the Council published PCI DSS v4.0.1 — described in its own release notes as "a limited revision" that corrected formatting and typographical errors and clarified the intent of existing requirements and guidance, explicitly stating there were "no additional or deleted requirements in this revision."² Version 4.0 was retired at the end of 2024, and 4.0.1 has been the sole active version of the standard since January 1, 2025.² If your organization's most recent PCI documentation still cites "PCI DSS v4.0" as the assessed version, that alone is worth a conversation with your QSA or acquirer about which version the assessment actually used.

The detail that matters most for a roadmap, and the one most often summarized loosely in secondary sources, is the future-dated requirement mechanism. Of the 64 requirements that were new in version 4.0, 51 were designated "future-dated": organizations could treat them as best practice from the moment v4.0 was published, but they did not become mandatory until March 31, 2025.³ The Council's own framing was explicit about the intent — "provid[ing] organizations with two years to understand the impact of the new requirements" before enforcement began.³ Version 4.0.1 did not move that date. It remained March 31, 2025.²

That date is now more than a year in the past. This is the fact that most changes the shape of this article compared to how it would have read in 2023: this is not a countdown anymore. Every requirement discussed below that was "future-dated" is, at the time of writing, a requirement your organization is expected to already be meeting if it is in scope for it. An assessor who finds an unimplemented future-dated requirement today is not documenting a plan for next year. They are documenting a gap.

Illustrative timeline of PCI DSS v4.x milestones (verified dates from PCI SSC publications):

2022 ───────── 2023 ───────── 2024 ───────── 2025 ───────── 2026
 │                              │      │         │
 v4.0                     v3.2.1   v4.0.1     future-dated
 published                retired  published  requirements
                                    (Jun 11)   become mandatory
                                     v4.0        (Mar 31)
                                    retired
                                    (Dec 31)

This is real, sourced data, not an illustrative scenario — it is the published transition schedule from the PCI SSC itself. The point of showing it as a timeline rather than a table alone is to make one thing visible at a glance: the "grace period" framing that dominated PCI DSS 4.0 commentary between 2022 and early 2025 is no longer an accurate description of where the industry stands. Any organization still operating on a 2023-era gap analysis is working from a document that describes a compliance posture that expired over a year ago.

The Assumption That Breaks First: "Our Processor Handles Compliance"

The most common scoping error in engineering organizations is not a technical one. It is a category error about what "compliant" describes. A payment processor being PCI DSS compliant describes the processor's environment. It does not automatically describe the merchant's environment, and the amount of the merchant's environment that gets pulled back into scope depends entirely on the integration pattern — a detail that is usually decided by an engineer configuring a checkout flow, not by whoever eventually signs the Attestation of Compliance.

Tokenization is a useful lens for this because it is both genuinely effective at scope reduction and genuinely incomplete as a scope-elimination strategy. When implemented correctly, tokenization replaces the primary account number (PAN) with a surrogate value that cannot be reversed outside a certified vault, and once a business stops handling raw PANs, a meaningful share of its infrastructure can exit the cardholder data environment (CDE) and fall outside PCI DSS requirements for that specific data flow.⁴ That is a real and valuable reduction. It is also not the same as full removal from PCI DSS obligations, and the categories that persist are exactly the ones product and engineering teams tend to assume "the processor covers":

• General security hygiene on any system that touches the payment flow before tokenization occurs — the checkout page itself, the server that redirects to or embeds the processor's fields, load balancers, CDN configuration, logging pipelines that might capture request bodies in transit.
• Written third-party service provider agreements. PCI DSS Requirement 12.8.2 requires maintaining a written agreement with service providers that includes an acknowledgment that the provider is responsible for the security of the cardholder data it possesses or otherwise stores, processes, or transmits — and the complementary requirement 12.9 requires service providers to acknowledge this in writing to their customers.⁵ That agreement has to actually exist, be current, and be produced during an assessment. "We use Stripe" is not itself the control; the written agreement and the ongoing due-diligence process around it is the control.
• Employee access controls and physical security for any system or location in the payment flow, including card-present terminals, back-office systems with card-entry capability, and support tooling with view access to any card data or tokens.
• Incident response and security policy requirements under PCI DSS Requirement 12, which apply to any entity accepting card payments regardless of how much of the technical processing is outsourced.⁴
• Script security and change/tamper detection on the checkout page itself, if the integration renders the processor's payment fields inside the merchant's own page (an iframe or embedded form) rather than sending the customer to a fully separate, processor-hosted page. This is the requirement category that changed the most in v4.0 and is covered in detail in the next section.

Hypothetical scenario 1 — the SaaS company that assumed "hosted checkout" meant "zero scope."

Initial situation: A 40-person SaaS company sells an annual subscription product. Checkout is handled entirely through a payment processor's hosted page: the customer clicks "Subscribe," is redirected via a standard HTTP redirect to a URL on the processor's domain, completes payment there, and is redirected back. The engineering team never sees a card number in any form. Two years ago, the founding engineer filled out SAQ A and the company has renewed the same attestation annually without much scrutiny.

Hidden assumption: The team believes that because no card data ever touches their servers, no PCI DSS requirement meaningfully applies to their code, and the annual SAQ A renewal is a rubber-stamp exercise that can be delegated to whoever is available.

What actually applies: For a genuine full-page redirect integration (not an embedded iframe), this assumption is largely correct for the requirements tied to payment-page script security, because the payment page itself is never rendered within the merchant's own page.⁶ But SAQ A still includes real, non-rubber-stamp obligations: maintaining the written service-provider agreement under 12.8.2, confirming annually that scope has not changed under Requirement 12.5.2 (also future-dated to March 31, 2025),³ and — if any part of the flow changes to load a payment form inline rather than redirecting — a substantially different and larger set of obligations activates immediately, often without anyone treating it as a compliance-relevant decision.

The consequence, played forward: Eighteen months later, a product manager asks engineering to reduce checkout friction by embedding the payment fields directly on the pricing page instead of redirecting away from it — a completely reasonable conversion-rate optimization. The change ships as a routine UI improvement. Nobody flags it as a PCI-relevant change because nobody on the team associates "moved a form" with "changed compliance obligations." The company is now running an embedded/iframe integration while still self-certifying against the old, lighter SAQ A checklist.

The decision point: Whether the person approving a checkout UX change has any mechanism to know that the change alters PCI scope, and whether SAQ selection is revisited when it does.

The better approach: Treat the checkout integration pattern (redirect vs. iframe vs. direct API/tokenization) as an architectural decision with a named owner, documented in the same place as other security-relevant architecture decisions, with a rule that any change to how payment fields are rendered triggers a scope re-review before it ships — not after the next annual attestation cycle happens to notice it.

How Scope Determination Actually Works

"Scope" in PCI DSS is not a checkbox on a form. It is the answer to a specific question: which systems, people, and processes could affect the security of the cardholder data environment. The PCI SSC's own scoping guidance describes the CDE as the people, processes, and technology that store, process, or transmit cardholder data, plus any systems that are connected to or could impact the security of that environment — a category the Council calls "connected-to" or "security-impacting" systems, which is deliberately broader than "systems that touch card data directly."⁷

This is the mechanism by which scope creep happens without a deliberate decision. A support tool that can view (but not store) tokenized card data, a logging platform that captures full HTTP request bodies "just in case," a CI/CD pipeline with a service account that has read access to the production database containing payment records — none of these systems "process cardholder data" in the narrow sense, but each of them is connected to, or could impact the security of, the environment that does. Segmentation is the primary technical control organizations use to keep this category from expanding indefinitely: adequately segmented networks can exclude out-of-scope systems from the CDE boundary, but the segmentation itself has to be actively validated, not just diagrammed once and assumed to hold.

The practical instrument most engineering teams encounter is the Self-Assessment Questionnaire (SAQ), and which SAQ applies is determined by payment brand and acquirer criteria based on how transactions are actually processed — not by which questionnaire a company would prefer to fill out.

Table 1 — SAQ types and what they actually assume about your environment

The category most engineering leaders underestimate is SAQ A-EP, and the FAQ the Council published in February 2025 (FAQ #1588) exists specifically because so many merchants were confusing "we don't store card data" with "we're eligible for the lightest questionnaire."⁶ The Council's clarification draws a specific technical line: merchants using a genuine redirect or a fully outsourced payment link generally remain SAQ A-eligible without additional script-attack obligations, but merchants embedding a third-party payment form via iframe must additionally confirm that their site is not susceptible to script-based attacks that could affect the payment process — either by implementing controls under Requirements 6.4.3 and 11.6.1 directly, or by obtaining written confirmation from the payment processor that its embedded solution includes built-in script protections when implemented according to the vendor's instructions.⁶ Payment card networks and acquirers also apply transaction-volume thresholds on top of these technical criteria, so SAQ eligibility is ultimately a determination made in coordination with your acquirer, not a self-selected label.⁶

Illustrative chart — relative engineering burden by integration architecture

The figures below are an illustrative, hypothetical estimate constructed for this article to make a qualitative point visible — they are not PCI SSC data, an industry benchmark, or a measured average, and should not be cited as one. They represent a rough ordering, not a precise ratio.

Redirect            ██
Embedded iframe      █████
Client-side tokenize █████░
Direct API/PAN pass  █████████
                     0    2    4    6    8    10
                     Illustrative effort (not measured data)

The shape of this chart is the actual argument of this section: engineering effort does not track linearly with "do we ever see a card number." It tracks with how much control the merchant's own code exercises over the rendering, behavior, and integrity of the payment experience — and that control can increase through an ordinary product decision (embedding a form instead of redirecting to one) without anyone treating it as a compliance decision at the time.

Three Requirement Areas Where Engineering and QA, Not Compliance, Own the Work

Three categories of PCI DSS 4.0 requirement move ownership away from a compliance or legal function and toward the people who write, deploy, and monitor code. Each is verified against PCI SSC or PCI SSC-cited sources below, and each was future-dated to March 31, 2025 — meaning each is, as of this writing, a live, mandatory obligation rather than a future planning item.

Payment page script authorization, integrity, and inventory (Requirement 6.4.3)

Requirement 6.4.3 states that all payment page scripts loaded and executed in the consumer's browser must be managed so that: a method confirms each script is authorized; a method assures the integrity of each script; and an inventory of all scripts is maintained with a written justification for why each one is necessary.⁸ This requirement was future-dated and became mandatory March 31, 2025, and it applies to e-commerce merchants whose payment page is rendered under conditions where the merchant's own code affects it — including SAQ A-EP-eligible implementations using JavaScript to construct or influence the payment form.⁸

This requirement exists because of a well-documented attack pattern generally referred to as e-skimming or web-based skimming: a script — sometimes injected through a compromised first-party dependency, sometimes through a compromised third-party tag loaded via a tag manager — silently captures card data as a customer types it, without needing to breach any database. The PCI SSC's own information supplement on payment page security notes that "scripts running in consumers' browsers are now a significant target for attackers seeking to steal payment card data," and states plainly that this guidance is supplemental — it does not add, extend, replace, or supersede the actual standard, but exists to help organizations understand how to meet 6.4.3 and 11.6.1 in practice.⁹

What this actually requires from an engineering team is closer to software supply chain governance than to a traditional compliance control. A practical implementation typically includes:

1. A maintained inventory of every script that executes on the payment page — first-party and third-party — with a documented business justification for each. This includes scripts loaded indirectly through a tag management system, which is precisely the mechanism that has made script inventories incomplete in most organizations: marketing, analytics, and A/B testing platforms are frequently added to a tag manager by a non-engineering team member, and the checkout page is rarely excluded from that tag manager's default rules.
2. A method to confirm authorization — commonly implemented through Content Security Policy (script-src directives naming allowed origins) combined with a change-management process requiring sign-off before a new script is allowed onto that page.
3. A method to assure integrity — commonly Subresource Integrity (SRI) hashes on scripts loaded from external origins, so that a script silently modified at its source (rather than modified in transit) is detectable.

A minimal illustrative example of the technical pattern (not prescriptive of any specific vendor implementation):

<!-- Content-Security-Policy header, restricting script origins on the payment page -->
Content-Security-Policy:
  script-src 'self' https://js.processor-example.com;
  report-uri https://security.example.com/csp-reports;

<!-- Subresource Integrity on an externally loaded script -->
<script
  src="https://js.processor-example.com/v2/checkout.js"
  integrity="sha384-<hash-of-known-good-script-version>"
  crossorigin="anonymous">
</script>

The report-uri (or its successor, report-to) directive matters for the next requirement, because a CSP violation report is one of the more efficient ways to satisfy it.

Change and tamper detection on the payment page (Requirement 11.6.1)

Requirement 11.6.1 requires a change- and tamper-detection mechanism to be deployed on the payment page, evaluating the page's received HTTP headers and payload for unauthorized modification and alerting personnel to any such modification — with an evaluation frequency of at least once every seven days, or at a frequency defined by the entity's own targeted risk analysis.⁸ This is also future-dated and mandatory as of March 31, 2025, and applies broadly to e-commerce merchants handling payment pages, not only to those using a specific SAQ type.⁸

Practically, this requirement is testable in a way that maps cleanly onto QA and security-monitoring practice rather than paperwork: it asks for continuous or near-continuous verification that the page a customer actually receives matches what the organization intended to ship, and that any HTTP header or script modification along the way — whether from a compromised CDN, a compromised third-party script, or a compromised build pipeline — triggers an alert to a human. Approaches organizations use to satisfy it include CSP violation reporting, synthetic monitoring that periodically loads the live checkout page from an external vantage point and diffs it against a known-good baseline, and dedicated tamper-detection services that embed a lightweight monitoring script on the page itself.⁸ None of these are prescribed by name in the standard; the standard specifies the objective (detect and alert on unauthorized modification, on a defined cadence) and leaves the mechanism to the organization.

Mermaid representation of the 6.4.3 / 11.6.1 control loop:

This is a QA-relevant control loop, not just a security one, because it is exactly the kind of continuously-running verification that belongs in a monitoring and alerting suite rather than in an annual audit binder. An engineering organization that already has synthetic monitoring or visual-regression testing infrastructure for its checkout flow is closer to compliant with 11.6.1 than one that has none — the gap is usually in wiring existing monitoring to an actual alert destination with a defined response process, and in the discipline of maintaining the script inventory that 6.4.3 requires as an input to knowing what "known-good" even means.

Expanded multi-factor authentication (Requirements 8.4.1–8.4.3, 8.5.1) and longer minimum passwords (8.3.6)

PCI DSS 4.0 both extended and clarified authentication requirements. Requirement 8.4.1 requires multi-factor authentication for all non-console access into the CDE for personnel with administrative access — this existed conceptually in earlier versions and was refined rather than newly introduced. Requirement 8.4.3 requires MFA for remote access originating from outside the entity's network that could access or impact the CDE, with clarification that properly segmented networks may narrow what counts as "could access" the CDE.¹⁰

The requirement that materially expands scope is 8.4.2: multi-factor authentication is implemented for all access into the CDE, not only administrative access — meaning ordinary personnel, not just admins, must authenticate with MFA before entering the cardholder data environment.¹⁰ This requirement, along with 8.5.1 (which requires MFA systems to be implemented in a way that prevents misuse, such as being resistant to replay attacks and requiring at least two different authentication factor types), was future-dated and became mandatory March 31, 2025.¹⁰ Separately, Requirement 8.3.6 raised the minimum password/passphrase length for accounts not otherwise protected by MFA, a change reflected consistently across the PCI DSS 4.0 authentication requirement set and widely documented by assessors and security vendors covering the standard's password requirements.

For an engineering organization, the practical translation of 8.4.2 is that any internal tool, admin panel, support dashboard, or debugging interface with access into the CDE — not just the production database console — needs MFA enforcement, and "the CDE" in this context is defined by however the organization has scoped and segmented its network. This is where scope determination (covered above) and authentication requirements intersect directly: an organization that has not clearly mapped which internal systems are "in" the CDE cannot correctly determine which internal tools need 8.4.2-level MFA enforcement, and is likely to either over-apply MFA in ways that create friction with no compliance benefit, or under-apply it in ways that leave a genuine gap.

Targeted Risk Analysis: The Requirement That Changes How Every Other Requirement Gets Justified

PCI DSS 4.0 introduced two related but distinct targeted risk analysis (TRA) obligations, and conflating them is one of the more common mistakes organizations make when building a v4.0 program.

Requirement 12.3.1 applies to a specific list of requirements throughout the standard that give organizations flexibility in how frequently a control must be performed, rather than dictating a fixed interval. For each of these, the organization must perform and document a targeted risk analysis justifying the frequency it has chosen, based on the likelihood and impact of the threat the control addresses. Independent analysis of the standard identifies roughly nine such frequency-flexible requirements, spanning areas including malware risk evaluation, log review cadence for lower-risk system components, physical device tamper inspections, password/passphrase rotation intervals for accounts not covered by other controls, and the change/tamper-detection evaluation frequency for 11.6.1 discussed above.¹¹ This requirement was also future-dated to March 31, 2025.¹¹

Requirement 12.3.2 is a separate, narrower obligation: any organization choosing to meet a requirement via the "customized approach" (discussed below) rather than the standard's prescribed method must perform a targeted risk analysis specific to that customized control, documented using a template the Council provides in Appendix E2 of the standard.¹¹

The practical difference matters because 12.3.1 is a baseline obligation that applies to essentially every merchant and service provider assessed against the full requirement set — it is not optional, and it is not tied to whether the organization is doing anything unusual — while 12.3.2 only applies to organizations that have deliberately opted into customized-approach controls, which is a smaller and more mature population.

A practical targeted risk analysis framework (built for this article, not a reproduction of the Council's Appendix E2 template):

The failure mode this framework is built to prevent is the one most organizations actually fall into: treating the TRA as a form filled out once by the compliance function, disconnected from the engineering team that actually understands the system being analyzed, and never revisited. A TRA written without engineering input tends to either wildly overestimate control frequency (leading to unnecessary operational cost) or underestimate it (leading to a documented justification that will not survive a QSA's questions).

The Customized Approach Is Not a Shortcut

PCI DSS 4.0 introduced an alternative to the traditional "defined approach" — the prescriptive, step-by-step method organizations have used for two decades — called the customized approach. Under this method, an organization designs its own control to meet a requirement's stated security objective, rather than implementing the specific method the standard describes, and must perform a targeted risk analysis under 12.3.2 for each customized control, using the Council's Appendix E2 template to document how the alternative control meets the objective.¹²

The Council's own guidance is candid that this approach is intended for "risk-mature organizations that demonstrate a robust risk-management approach to security" — entities with established risk-management programs, personnel qualified to perform complex security analyses, consistent asset monitoring, and a track record of continuous improvement — and explicitly notes that an organization that would need its assessor's help designing the alternative control is probably not a good candidate for this approach.¹²

This matters for a roadmap because the customized approach is frequently proposed, in practice, for the wrong reason: as a way to avoid implementing an inconvenient control, rather than as a way to meet the same security objective through an already-existing, differently-shaped control the organization has good reasons to trust. An engineering team frustrated by, say, the MFA requirements might propose "we already have strong session management, can't that count instead" — and the honest answer is that it might, under the customized approach, but only with a rigorous, documented risk analysis specific to that claim, reviewed by a QSA who has to independently validate it, at meaningfully higher assessment cost and effort than simply implementing the defined control.¹² For the large majority of SaaS and e-commerce companies below enterprise scale, the defined approach — however less flexible — is usually the lower-total-cost path, and the customized approach is worth considering only where the organization already has the risk-management maturity the Council describes as a prerequisite, not as a workaround for a control nobody wants to build.

Scenario: A Company Handling More of the Payment Flow Directly

The first scenario in this article involved a company that had genuinely minimized its scope through a full-page redirect. Scope and burden increase substantially — and in ways that are easy to underestimate — for companies whose product requires more direct involvement in the payment flow.

Hypothetical scenario 2 — the marketplace platform that needed control the hosted checkout couldn't give it.

Initial situation: A marketplace connecting service providers with customers needs to split each transaction between a platform fee and a payout to the provider, apply promotional discounts calculated server-side, and support saved payment methods across sessions in a single, branded checkout experience. A fully redirected hosted-checkout page can't support this cleanly — the split-payment logic and the branded, no-redirect experience the product team wants both push toward a more integrated approach. The engineering team adopts client-side tokenization: a processor-provided JavaScript SDK renders the card fields inside the platform's own page (an embedded iframe pattern), tokenizes the card client-side, and only tokens — never raw PANs — reach the platform's servers, which then call the processor's API to complete the split payment.

Hidden assumption: Because raw PANs never reach the company's servers, the engineering team assumes this is architecturally similar to the redirect case from Scenario 1 — "we still don't store card numbers" — and continues operating under a lighter self-assessment than the integration pattern actually supports.

The technical/organizational cause: Client-side tokenization via an embedded form is precisely the SAQ A-EP category the Council's FAQ #1588 clarification addresses: because the platform's own JavaScript is present on the page and can influence how the payment iframe behaves, Requirements 6.4.3 and 11.6.1 apply, along with a written confirmation obligation about script-attack protection — either implemented directly or confirmed in writing from the processor.⁶ No one on the team had mapped the SDK's embedding model to this specific requirement category; the assumption "no PAN reaches our servers" was treated as equivalent to "no PCI scope for our page," when the standard draws the line at script control and page rendering, not merely at where the PAN physically transits.

The consequence: During a routine security review triggered by a large enterprise customer's vendor risk questionnaire, the security team is asked directly whether the checkout page maintains a script inventory and change-detection mechanism per PCI DSS 6.4.3/11.6.1. No such inventory exists; the tag management platform used by marketing has added three additional analytics and personalization scripts to the checkout page over the preceding year, none reviewed for payment-page-specific risk, and there is no tamper-detection alerting on the page at all.

The decision point: Whether to treat this as a compliance-paperwork gap to be closed retroactively with documentation, or as a genuine engineering gap requiring an actual script governance process and monitoring build-out.

The better approach: The company builds a script inventory covering the checkout page specifically (distinct from a general site-wide tag audit), moves the tag manager's checkout-page ruleset to an explicit allowlist model rather than default-inclusion, implements CSP with SRI on the payment-relevant scripts, and stands up lightweight synthetic monitoring on the checkout page with alerting wired to the on-call rotation already used for other production incidents — reusing existing SRE tooling rather than buying a single-purpose compliance product, since the underlying capability (detect unexpected change, alert a human) already existed for other purposes.

Hypothetical scenario 3 — scope creep with no checkout page involved at all.

Initial situation: A B2B SaaS company processes payments through a standard hosted-redirect integration, genuinely SAQ A-eligible on the checkout flow itself. Separately, the customer support team adopts a new helpdesk platform that integrates with the company's backend to show support agents a customer's recent account activity, including recent transaction records, to speed up billing dispute resolution.

Hidden assumption: Because the checkout page was already reviewed and found compliant, the team assumes the company's overall PCI posture is settled, and the helpdesk integration — being a "support tool," not a "payment tool" — never goes through any PCI-specific review.

The technical/organizational cause: The transaction records displayed to support agents, exported via an API integration to the helpdesk platform, include the last four digits of the card and the processor's transaction ID — permitted display data under PCI DSS — but a misconfiguration in the integration causes the API response payload, including a masked-but-not-fully-redacted card field, to be logged in full by the helpdesk platform's own application logging, which is retained by that third-party vendor and accessible to that vendor's support staff. Nobody on the engineering team classified the helpdesk platform as a system that "could impact the security of the CDE" — the PCI SSC's own scoping language for what belongs in scope⁷ — because no one thought of a support tool as payment-adjacent.

The consequence: The company discovers this only when performing the annual scope confirmation exercise required under Requirement 12.5.2,³ during which someone finally walks the actual data flows rather than reviewing the checkout architecture diagram from the original SAQ. The helpdesk vendor is not a party to any PCI-relevant written agreement under 12.8.2, because no one classified it as a service provider that needed one.

The decision point: Whether annual scope confirmation is a real exercise that traces current data flows, or a form completed by re-reading the previous year's answers.

The better approach: Treat Requirement 12.5.2's annual scope confirmation as an actual data-flow audit — not a document review — specifically including any new tool, integration, or vendor onboarded in the preceding year that touches customer account or transaction data in any way, with a standing checklist item in the vendor-onboarding process asking whether a new tool will have access to any transaction-related data, before that tool goes live rather than during the next annual review cycle.

Hypothetical scenario 4 — the "remember my card" feature that quietly created a real cardholder data environment.

Initial situation: A subscription-based B2B SaaS product processes its primary billing through a standard tokenized integration and is otherwise SAQ A-EP-eligible, consistent with the embedded-checkout pattern described above. A customer success team, responding to repeated requests from larger accounts that manage multiple cost centers, asks engineering to add a "saved payment methods" feature so an account administrator can store several cards and assign different ones to different sub-teams without re-entering card details each time. Under deadline pressure, an engineer implements this by having the backend accept the raw card number from the browser during the "add a card" flow, encrypt it, and store the encrypted value directly in the application's primary database — reasoning that encryption at rest satisfies "protecting" the data, and that this is a small, contained feature relative to the rest of the product.

Hidden assumption: The team treats this as a data-protection decision — "we're encrypting it, so it's secure" — rather than a scoping decision. Nobody frames the choice as "we are about to become a merchant that stores cardholder data," because the feature request came from customer success, was scoped as a UX improvement, and never passed through whatever process (if any) previously touched PCI-relevant architecture decisions.

The technical or organizational cause: Encrypting a PAN before storing it is a reasonable control, but it does not remove the PAN, or the database it lives in, or the application servers that handle it in transit, or the backup systems that replicate that database, from the cardholder data environment. The company has gone, in a single feature, from an SAQ A-EP profile — where raw PANs never reach its servers at all — to an environment that stores cardholder data outright, which is a different and substantially larger SAQ category (commonly SAQ D for merchants that don't fit any lighter category), carrying the full weight of network segmentation validation, encryption key management practices, expanded logging and monitoring, and every MFA and penetration-testing obligation discussed earlier in this article, applied to infrastructure that was never built or tested with any of that in mind.

The consequence: The gap surfaces nine months later, not through an internal review, but because a prospective enterprise customer's procurement team asks for the company's current Attestation of Compliance and cross-references the SAQ type against the feature list on the company's own marketing site, which by then advertises "securely save and manage multiple payment methods per account" as a selling point. The mismatch between an SAQ A-EP attestation and a product that visibly stores card data becomes a due-diligence blocker in an active enterprise sales cycle, at a moment when the company can least afford a multi-month remediation project.

The decision point: Whether "store the encrypted card number ourselves" and "let the payment processor store a reusable payment method token on our behalf and hand us a token, not a PAN, at reuse time" are treated as interchangeable implementation details, or as fundamentally different scoping decisions that deserve review before either one ships.

The better approach: Most PCI DSS-compliant payment processors and PSPs offer a vaulting or stored-payment-method capability specifically so merchants do not need to store PANs themselves — the processor stores the card and returns a reusable, merchant-scoped token that can be charged again later without the merchant's systems ever holding, or needing to protect, the underlying card number. Using that capability instead of building in-house storage would have kept the feature's implementation inside the same SAQ A-EP boundary the rest of the checkout flow already operated in. The organizational fix that prevents a repeat of this specific failure is procedural rather than technical: any feature request that involves storing, retaining, or reusing payment information — regardless of which team originates the request — should have a mandatory checkpoint asking whether the processor's existing vaulting or tokenization capability already solves the problem before an engineer designs a custom storage mechanism to solve it independently.

This scenario is also the cleanest illustration of why tokenization is not a single fact about a company but a property of a specific data flow. The same organization can be correctly tokenized on its primary checkout path and simultaneously storing raw PANs on a secondary feature nobody flagged as payment-adjacent — and an SAQ answered honestly about the primary flow can still be materially wrong about the organization's actual, current scope.

Where Scope Creeps In Without Anyone Deciding It Should

The three scenarios above point at a pattern worth naming directly: PCI scope rarely expands through a single dramatic decision. It expands through ordinary product and engineering choices made by people who were never told those choices were compliance-relevant. The categories that most often cause this, based on how the requirements above actually apply, include:

• Tag management platforms applied site-wide by default, including on checkout and payment-adjacent pages, without a checkout-specific allowlist.
• Observability and logging tools configured to capture full request/response bodies for debugging convenience, without redaction rules specific to payment-adjacent endpoints.
• Support and CRM tooling with read access to transaction data, onboarded through a standard SaaS-procurement process that has no PCI-specific question in it.
• Staging and QA environments seeded with production-like data for realistic testing, including real or lightly-masked card data from before tokenization was fully enforced everywhere.
• CI/CD service accounts and secrets with broader database access than the specific job requires, creating a "connected-to" system in the PCI SSC's scoping sense⁷ that few engineers would intuitively describe as being "in PCI scope."
• Mobile app SDKs for analytics, crash reporting, or attribution that are added to a checkout screen without review of what data they can observe from the surrounding view hierarchy.
• Call center or chat transcript storage, when customers paste or read card numbers aloud during a support interaction and the recording or transcript is retained without redaction.

None of these require a dramatic architectural failure to become a real gap. They require the ordinary, distributed nature of how modern engineering organizations add tools and vendors — usually without a single point where someone asks "does this touch anything payment-adjacent."

Warning Signs Your PCI Program Is Paperwork, Not Engineering

Some patterns reliably predict that the gaps described above exist somewhere in an organization, even before anyone has looked for them directly. None of these individually proves a compliance failure, but each one is a reasonable trigger for the diagnostic checklist that follows.

The SAQ is completed by one person, alone, from memory. If the annual questionnaire is filled out by a single compliance-adjacent employee who did not need to ask engineering a single question to complete it, the questionnaire is very likely describing last year's architecture, not this year's. A genuine SAQ renewal should generate at least a handful of engineering conversations — about what changed in the checkout flow, what new vendors were added, and whether any monitoring lapsed.

Nobody can name the script inventory's file location. Requirement 6.4.3 asks for a maintained inventory with written justification for each script. If that inventory exists only as a mental model ("we don't really add random scripts to checkout"), it does not satisfy the requirement, and it is also almost certainly wrong — tag managers make it easy for a script to reach a page without any engineer deciding it should.

The tamper-detection mechanism has never fired. A monitoring system that has run for a year without ever generating an alert is either watching a system that genuinely never changes (rare, for anything with third-party scripts) or is not actually wired to anything that would catch a real change. Teams should occasionally verify the alerting path with a deliberate, controlled test change, the same way a well-run incident response program periodically tests its paging chain rather than assuming it works because no real incident has triggered it recently.

MFA enforcement is described in policy but not enforced in configuration. A written policy stating that MFA is required for CDE access is not the same as an identity provider configuration that actually blocks non-MFA sessions from reaching the relevant systems. The gap between the two is common enough that it is worth an engineer, not just a policy author, confirming the enforcement mechanism directly.

The most recent penetration test report predates the most recent significant architecture change. If the last penetration test or segmentation validation happened before a major infrastructure migration, a new microservice touching payment-adjacent data, or a cloud provider change, the test's findings describe an environment that no longer exists. PCI DSS requirements tie penetration testing and segmentation validation to significant changes precisely because architecture drift outpaces annual cycles.

Vendor risk questionnaires from enterprise customers surface questions the internal team can't answer. When a prospective enterprise customer's security team asks a specific, well-informed question about payment page script governance or CDE access controls, and the answer requires several days of internal research to produce, that delay is itself a signal — the organization does not have the answer readily available because the underlying control, not just the answer, does not fully exist yet.

Diagnostic Checklist: Is Your Engineering Organization Actually Out of Scope?

This checklist is built for engineering and QA leaders to work through with their compliance counterpart — not a replacement for a QSA's assessment, but a way to surface likely gaps before that conversation happens.

1. Integration pattern. Is the payment flow a genuine full-page redirect to a processor-hosted page, or does any part of your own page render, construct, or influence the payment form (iframe, embedded fields, client-side tokenization SDK)? If the latter, Requirements 6.4.3 and 11.6.1 likely apply regardless of whether raw PANs ever reach your servers.
2. Script inventory. Does a maintained, justified inventory of every script executing on the checkout/payment page exist, including scripts added through a tag manager by non-engineering teams?
3. Change detection. Is there an active mechanism — synthetic monitoring, CSP violation reporting, a dedicated tamper-detection tool — checking the live payment page against a known-good baseline at least every seven days, or at a frequency justified by a documented targeted risk analysis?
4. Written service-provider agreements. For every vendor that stores, processes, or transmits cardholder data on your behalf — including the primary processor and any secondary tool with transaction-data access — does a current written agreement exist acknowledging the vendor's responsibility for that data's security (Requirement 12.8.2)?
5. Annual scope confirmation. Was the most recent scope confirmation (Requirement 12.5.2) a genuine review of current data flows and vendor integrations, or a re-attestation of a prior year's architecture diagram?
6. MFA coverage. Is multi-factor authentication enforced for all personnel access into systems classified as within the CDE — not only administrative access — consistent with Requirement 8.4.2, and is the MFA implementation itself resistant to replay per 8.5.1?
7. Targeted risk analyses. For every requirement in your applicable SAQ or ROC that allows a flexible frequency (log review cadence, tamper-detection interval, and others under 12.3.1), does a documented, engineering-informed risk analysis justify the chosen frequency?
8. Non-payment tooling with transaction-data access. Has every support, CRM, analytics, or observability tool that can access transaction records — even masked ones — been evaluated as a potential "connected-to" or "security-impacting" system under PCI SSC scoping guidance,⁷ independent of whether it was procured through a security-reviewed process?
9. Staging/QA data hygiene. Does any non-production environment contain real or reversibly-masked cardholder data, and if so, is that environment itself in PCI scope (it should be)?
10. Ownership. Is there a named individual or team — not "compliance" as an abstract function — who owns the engineering-side controls above, with a defined review cadence, rather than a single person who reappears once a year to complete the SAQ?

Building the Engineering and QA Roadmap

Turning the requirements above into an operating program means assigning cadence and ownership to each recurring obligation, rather than treating the annual assessment as the only fixed point on the calendar. The table below sequences the major recurring engineering/QA-relevant PCI DSS 4.0.1 activities by verified or well-documented frequency — not by calendar date, since the actual date each activity falls due depends on when an organization's assessment cycle starts.

Table 2 — Recurring PCI DSS 4.0.1 engineering/QA obligations by frequency

This table is deliberately organized by frequency rather than by which SAQ an organization files, because the frequency-based obligations are the ones most likely to silently lapse — an annual assessment forces a checkpoint, but a "check every seven days" or "review every quarter" obligation has no equivalent forcing function unless it is built into existing operational tooling (alerting, sprint cadences, on-call rotations) rather than tracked separately by a compliance team with no visibility into engineering's actual release cycle.

Translating Controls Into QA Test Cases

Most of the requirements discussed above are written as security or governance controls, but they are also, functionally, testable assertions about system behavior — which means they belong in a test plan, not only in a policy document. The table below sketches concrete test cases an engineering or QA team could adapt for the requirement areas covered in this article. These are illustrative examples built for this article, not a reproduction of any PCI SSC testing procedure, and a real Report on Compliance or SAQ response still requires the specific validation steps the standard itself defines.

Several of these test cases are automatable and belong in existing CI/CD or synthetic-monitoring infrastructure rather than in a manual annual review — the script-injection and tamper-simulation cases in particular are well suited to a scheduled canary job that runs against a staging replica of the checkout page. Treating them this way also produces something an assessor values highly: a running history of test executions and results, rather than a one-time assertion made during audit season.

Startups, Scale-Ups, and Enterprises: Where the Burden Actually Falls

The scenarios above generalize into a rough maturity pattern, though any individual company's actual scope depends on its specific integration, not its headcount:

Early-stage companies using a genuine hosted redirect carry the lightest technical burden — SAQ A's requirements are real but narrow, and the main risk is treating the annual attestation as passive rather than tracking whether a product decision (embedding instead of redirecting) has silently moved the company into a heavier category.

Growth-stage companies building more integrated checkout experiences — client-side tokenization, embedded forms, split payments, saved payment methods — carry meaningfully more obligation under 6.4.3, 11.6.1, and the SAQ A-EP script-attack confirmation, and are the population most likely to have made this architectural shift for legitimate product reasons without anyone re-evaluating compliance scope at the same time.

Enterprises and any organization handling raw PANs directly, even transiently — payment facilitators, some marketplaces, in-house payment infrastructure — operate under the full requirement set (commonly SAQ D or a full Report on Compliance), where segmentation testing, comprehensive MFA rollout, encryption key management, and the complete targeted-risk-analysis program are not optional add-ons but baseline obligations, and where the customized approach becomes a genuinely relevant option given the risk-management maturity the Council expects of organizations using it.¹²

An illustrative cost-framing exercise (hypothetical figures, not a benchmark or PCI SSC data): Consider a mid-market e-commerce company deciding whether to build tamper-detection and script-governance capability in-house versus continuing to treat it as a once-a-year documentation exercise. Building a synthetic-monitoring canary job on top of existing SRE tooling, plus a script-inventory reconciliation check wired into the deploy pipeline, might represent a few engineer-weeks of one-time build effort and a small ongoing maintenance load — meaningfully less than the recurring cost of a QSA revisiting the same undocumented gap every year, and substantially less than the cost of investigating and disclosing a script-based skimming incident after the fact, which typically involves forensic investigation, card network notification obligations, and potential fines or increased transaction fees imposed by the acquirer — none of which this article will attach a specific dollar figure to, since no reliable, current, publicly sourced figure applies uniformly across merchant sizes and card brands. The directional point holds without a specific number: the in-house monitoring build is a bounded, one-time-plus-maintenance cost; the alternative is an open-ended liability that includes forensic, legal, and card-network components an engineering team does not control once triggered.

The practical implication for a roadmap is that "PCI DSS effort" is not a fixed cost that scales predictably with company size. It scales with a specific architectural decision — how much control your own code exercises over the payment page and how much of the raw payment data transits your own infrastructure — and that decision can change through routine product work well before a company's overall engineering maturity or headcount would suggest it's ready for the heavier obligations that follow.

Questions to Take Back to Your Team and Your Processor

For an internal engineering/QA review:

• Who currently owns the checkout page's script inventory, and when was it last actually reviewed rather than assumed current?
• If our checkout integration changed from a redirect to an embedded form tomorrow, would anyone outside engineering find out before the next annual assessment?
• Does our tag management platform apply a different, more restrictive ruleset to the checkout page than to the rest of the site?
• Which internal tools have access to transaction data, and were any of them evaluated for PCI relevance at the time they were adopted?
• For every requirement in our SAQ that specifies "periodically" rather than a fixed interval, do we have a documented, engineering-informed risk analysis behind the frequency we've chosen — or did we pick a number and move on?

For a payment processor or gateway vendor, as part of due diligence or renewal:

• For our specific integration pattern (redirect, iframe, tokenization SDK), what written confirmation can you provide regarding built-in script-attack protections, consistent with the Council's FAQ #1588 clarification?⁶
• What exactly does our current written service-provider agreement say about your responsibility for the security of transaction data, and when was it last updated to reflect the current PCI DSS version?
• If we change our integration pattern, what specifically changes about our compliance obligations under your platform, and is that documented anywhere we can reference before we ship the change?

Frequently Asked Questions

Does using Stripe, Adyen, Braintree, or a similar processor make us PCI compliant automatically? No. Using a PCI DSS-compliant processor reduces your scope, often substantially, but your organization still has its own obligations — a written service-provider agreement, annual scope confirmation, and, depending on your specific integration pattern, script security and change-detection requirements on your own checkout page. Compliance is determined by your complete environment and integration, not solely by your vendor's certification.

Is PCI DSS 4.0 still in a transition period as of today? No. The 51 future-dated requirements introduced in PCI DSS 4.0 became mandatory on March 31, 2025, and PCI DSS v4.0.1 — published June 11, 2024 as a clarification-only revision — has been the sole active version of the standard since v4.0's retirement on December 31, 2024.^{1 2 3} Any transition-period framing applied to these requirements today describes a status that ended over a year before this article was written.

Does a full-page redirect to a hosted payment page avoid the payment-page script requirements entirely? Generally yes, for a genuine redirect where the customer leaves your page and completes payment on the processor's own domain. The script authorization, integrity, and tamper-detection requirements (6.4.3 and 11.6.1) target scenarios where your own page renders or influences the payment experience, such as an embedded iframe or hosted fields — the PCI SSC's FAQ #1588 draws this distinction explicitly.⁶ Confirm your specific implementation with your acquirer or QSA, since edge cases (meta-refresh redirects, JavaScript-driven redirects) can behave differently from a simple HTTP redirect.

What is the difference between the "defined approach" and the "customized approach" in PCI DSS 4.0? The defined approach is the traditional, prescriptive method: implement the specific control the standard describes. The customized approach lets an organization design an alternative control that meets the same stated security objective, but requires a documented targeted risk analysis for each customized control (Requirement 12.3.2) and is intended for organizations with mature, established risk-management programs — not as a general substitute for controls an organization would prefer to skip.¹²

Do SAQ A merchants really need quarterly external vulnerability scans now? Yes, for the specific scenario the PCI SSC has clarified: e-commerce merchants completing SAQ A are expected to undertake external vulnerability scans at least once every three months by an Approved Scanning Vendor, a change from the more limited scanning expectations under prior versions.¹³ This is one of several v4.0 changes that increased what "lightweight" SAQ categories actually require in practice.

How often does PCI DSS require penetration testing and segmentation testing? Under the current standard, service providers relying on segmentation must validate its effectiveness through penetration testing at least every six months and after any change to segmentation controls; the broader population of entities relying on segmentation must validate it at least every twelve months and after significant changes; and general internal/external penetration testing is required at least annually and after significant infrastructure or application changes.

The Roadmap Question Worth Taking to Your Engineering Org

The organizations most exposed under PCI DSS 4.0.1 are not the ones handling the most cardholder data. They are the ones whose engineering decisions about how a payment page is built have outpaced whoever last looked at what SAQ category those decisions actually put them in. A redirect-to-embedded-form change, a new tag added by marketing, a support tool given read access to transaction history — none of these look like compliance decisions from inside the sprint where they happen. Each of them can be exactly that.

The useful question for an engineering leader is not "are we PCI compliant." It's narrower and more answerable: if our checkout integration pattern changed next quarter — for entirely legitimate product reasons — would anyone find out before the next audit cycle, or only during it? An organization that can answer that question with a specific name and a specific trigger has actually operationalized PCI DSS 4.0. An organization that can only answer it with "we'd catch it at renewal" has a certificate, not a control.

Getting from the first state to the second is largely a testing and monitoring problem — script inventories that are checked on every deploy rather than audited once a year, tamper-detection wired into existing on-call tooling rather than bought as a separate compliance product, and targeted risk analyses written by the engineers who actually run the systems being analyzed rather than by whoever fills out the SAQ. QAtronic works with engineering teams on exactly that layer: building the automated checks, monitoring, and test coverage that make a compliance requirement into something a CI pipeline or an on-call engineer can actually act on, rather than something rediscovered once a year during an assessment.