Who is accountable for PCI SAQ compliance when organisations rely on third-party payment providers?

Why This Matters for Security Teams

PCI SAQ accountability does not move with the payment flow. Even when a third-party payment provider hosts the checkout, tokenizes card data, or processes transactions on behalf of the business, the organisation completing the SAQ still has to prove that its environment fits the selected SAQ’s eligibility criteria and that its control scope is accurate. That distinction is easy to miss when teams assume outsourcing equals exemption.

This is a governance problem as much as a technical one. Payment providers can reduce the cardholder data footprint, but they do not automatically eliminate web scripts, redirect paths, admin access, API integrations, or residual system dependencies that can keep the merchant in scope. PCI DSS expects the entity attesting compliance to understand those boundaries, validate them, and retain evidence. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how often delegated access and third-party exposure create hidden accountability gaps, and the same pattern appears in payment environments.

In practice, many security teams discover SAQ mis-scoping only after a QSA review, a failed assessment, or a provider incident exposes shared responsibility gaps.

How It Works in Practice

The accountable party is usually the merchant or service provider completing the SAQ, but the practical burden is shared across procurement, security, engineering, and legal. The organisation must confirm which SAQ type applies, document why it qualifies, and maintain proof that the environment matches that scope. If a provider handles payment pages or tokenization, the internal team still needs to verify where cardholder data could appear, which systems can influence the payment journey, and which integrations create indirect exposure.

That means the answer is not simply “the vendor is responsible.” The provider may be responsible for its own controls and contractual commitments, but the attesting organisation remains responsible for its own environment, its own evidence, and its own interpretation of PCI DSS applicability. This aligns with the control logic in the NIST Cybersecurity Framework 2.0 and the documented control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, even though PCI compliance itself is a separate regime.

• Map the payment flow end to end, including redirects, embeds, APIs, and admin consoles.
• Confirm whether cardholder data ever transits, processes, or can be accessed from the organisation’s environment.
• Review the provider’s AOC, contract terms, and shared-responsibility boundaries.
• Retain evidence that the selected SAQ matches the actual implementation, not the intended design.
• Reassess scope whenever scripts, plugins, hosting models, or integrations change.

NHIMG research shows how often third-party exposure expands hidden risk, including the finding that 92% of organisations expose NHIs to third parties in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. These controls tend to break down when the payment provider is treated as a scoping shortcut rather than a dependency that still requires validation.

Common Variations and Edge Cases

Tighter payment scope often reduces operational flexibility, requiring organisations to balance simpler attestations against integration complexity and business convenience. That tradeoff becomes sharper when the provider uses hosted fields, embedded SDKs, payment links, or multi-party orchestration, because each model changes where data flows and who can affect the environment.

Current guidance suggests there is no universal standard for every outsourced payment pattern, so the safest approach is to treat scope as a living assessment rather than a one-time vendor decision. A merchant using a fully hosted payment page may have a smaller SAQ footprint than a site that injects third-party scripts into a checkout flow, but either model can still create obligations if the organisation can influence the page or handle adjacent systems. This is where the OWASP Non-Human Identity Top 10 becomes relevant in a broader sense: third-party integrations, API keys, and service credentials often determine whether the environment is truly isolated or still operationally exposed.

For organisations with payment partners, the most common edge case is assuming the provider’s certification automatically transfers accountability. It does not. The attesting entity must still evidence eligibility, define control ownership, and revisit the SAQ whenever payment architecture, scripts, or data-handling responsibilities change.

Related resources from NHI Mgmt Group

• How should organisations secure payment pages that rely on third-party JavaScript?
• Who is accountable when banks rely on third-party compliance and fraud tooling?
• Who is accountable when a third-party NHI causes PCI scope exposure?
• Who is accountable when a third-party SaaS app causes a compliance failure?