We use a payment gateway, so PCI DSS does not apply to us

It applies. A payment gateway changes how much of PCI DSS applies to you and who does the work. It does not switch the standard off, and the Council says so in one sentence that appears in the scoping guidance of PCI DSS v4.0.1, in the applicability notes to Requirement 12.8.1, and again inside the SAQs themselves:

“The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.”

The true part of the belief, and it is a large part

Outsourcing every account data function to a PCI DSS validated and compliant third-party service provider is the biggest scope reduction available to a merchant. Done properly it takes you to SAQ A and fourteen requirements. Not done, you are answering 139, or the whole standard. Nothing else in PCI DSS moves the number that far. A gateway is not irrelevant to your position — it is the most consequential single decision you will make about it.

“Properly” is a defined term. To claim SAQ A, the SAQ Instructions and Guidelines v4.0.1 r1 (April 2025) require a merchant to confirm all of the following:

• it accepts only card-not-present transactions;
• all processing of account data is entirely outsourced to a PCI DSS compliant TPSP or payment processor;
• it “does not electronically store, process, or transmit any account data on merchant systems or premises”;
• it has confirmed the TPSPs are PCI DSS compliant for the services being used by the merchant;
• any account data retained is on paper, and not received electronically;
• for e-commerce, every element of the payment page “originate[s] only and directly from a PCI DSS compliant TPSP/payment processor”, and the merchant has confirmed its site is not susceptible to script attacks.

Five of those six are statements about your systems, not your gateway’s. Which questionnaire you are actually eligible for is a longer answer set out in the SAQ eligibility table.

What you still own after a full outsource

Requirement 12 does not disappear when payment processing does. It arrives because payment processing went away: “If the entity engages third-party service providers to store, process or transmit PAN on its behalf, requirements related to the management of service providers in Requirement 12 will be applicable.”

Two more survive outsourcing outright. Card data on paper — printed reports, order forms, receipts — pulls in the physical media controls of Requirement 9. And incident response is universal: “Requirements related to an incident response plan are applicable to all entities, to ensure that there are procedures to follow in the event of a suspected or actual breach of the confidentiality of cardholder data.”

Validation itself is also not the gateway’s call. “Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers).” Your acquirer decides whether you file and what you file. The attestation that closes an SAQ is signed by your own executive officer — not by the gateway, and not by an assessor.

Four ways the belief quietly stops being true

Your website builds the payment form

A URL redirect or an embedded iframe from the provider keeps you in SAQ A. A Direct Post — your page renders the form and the browser posts the data straight to the processor — does not, and neither does loading your own script into the payment page. That is SAQ A-EP, 139 requirements, and the guidance is blunt about the consequence: “For the purposes of SAQ A-EP, PCI DSS requirements that refer to the ‘cardholder data environment’ are applicable to the merchant website(s).” The site nobody thought was in scope becomes the thing being assessed. Requirements 6.4.3 and 11.6.1 sit on exactly this boundary and stopped being best practice on 31 March 2025.

Somebody types a card number in

Refunds, phone orders, a rescued abandoned basket. Keying a PAN into your provider’s back office from a staff workstation is a virtual payment terminal, and that channel carries its own eligibility criteria: an isolated computing device, in a single location, not connected to any other system in the merchant environment, and no electronic storage. A shared laptop on the office network fails that, and it is not SAQ A either, because SAQ A requires that no account data pass through your systems at all.

The PAN turns up where nobody put it

Application logs, error traces, a support ticket, a CRM note, a screenshot pasted into a chat channel, an email from a customer who typed the number in themselves. The SAQ A criterion is absolute rather than proportionate: no electronic storage, processing or transmission of account data on merchant systems or premises. One recurring log line does not reduce your eligibility, it ends it.

You are also somebody else’s provider

Marketplaces, SaaS platforms, resellers and orchestration layers use a gateway and sit inside their customers’ card flows. That makes you a service provider in someone else’s programme, carrying obligations no merchant questionnaire contains: 11.4.6 segmentation testing at least once every six months rather than twelve, and 11.4.7 support for customer penetration testing.

What “PCI DSS compliant gateway” is actually worth to you

Two facts sit oddly together and both are in the standard. Requirement 12.8 does not require your provider to be compliant at all — “Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer monitors their compliance status”. SAQ A eligibility does require it. So your gateway’s compliance is not a Requirement 12 question. It is the question of which questionnaire you are allowed to file.

For evidence, the badge on their homepage is worth nothing and the payment brand listing is worth less than it looks. Presence on a brand’s list of compliant service providers may be enough to monitor status under 12.8.4, but where the provider meets requirements on your behalf, that listing “is not sufficient evidence that the applicable PCI DSS requirements for that TPSP were included in the assessment”. Ask for the AOC, and check that its scope names the services you actually use. Then read the sentence that carries the whole risk, from the applicability notes to 12.8.4:

“If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also ‘not in place’ for the entity.”

Their gap lands on your assessment. That is why 12.8.5 exists, and why a provider’s responsibility matrix is worth more to you than its logo.

The Indian wrinkle

Most Indian gateways are payment aggregators, carrying Reserve Bank obligations that run in parallel with anything PCI DSS asks of them, and card-on-file tokenisation has already taken the storage decision out of merchants’ hands in a way Western scoping guides still treat as an architectural choice. Neither changes the analysis above; both change what you should be asking for in the contract. Covered separately in PCI DSS and the RBI payment aggregator framework and tokenisation and card-on-file in India.

Five things worth checking this week

• Open your checkout in a browser and list where every element of the payment page is served from. If one of them is served by you, you are not SAQ A.
• Ask your gateway for its current AOC and its responsibility matrix, and confirm the services you use are named in the assessed scope.
• Search your logs, database, ticket system and CRM for card number patterns. Do it before an assessor does.
• Ask your acquirer which SAQ they expect and by when. They decide this, not the gateway.
• Write down who handles refunds and phone orders, and on which machine.

If that exercise puts you outside SAQ A, the Requirement 11.4 obligations arrive with it — internal and external penetration testing per a defined methodology, at least once every 12 months and after any significant infrastructure or application upgrade or change, plus 11.4.5 testing of segmentation controls wherever you rely on segmentation to keep the scope small. The standard asks, at each of those sub-requirements, for a qualified internal resource or qualified external third party with organisational independence from the systems being tested. That is penetration testing scoped to Requirement 11.4, and it is a separate exercise from filling in the questionnaire.