Do you need PCI DSS? Merchant levels, service providers and who decides your validation route

Does PCI DSS apply to you?

The short answer for almost any business that takes card payments is yes. PCI DSS reaches every entity that stores, processes or transmits cardholder data or sensitive authentication data, and every entity whose people, systems or processes could affect the security of that data. A managed IT provider with administrator access to a retailer's network or a developer hosting a checkout page falls inside it without keeping a single card number.

It is not a law. The obligation arrives through contracts: your merchant agreement with the acquiring bank, the card brands' compliance programmes that bind the acquirer, and, for service providers, the clauses your clients write into their own supplier contracts. So the practical question is: who is asking us for proof, in what format, and by when?

Merchant or service provider, and what your level means

Merchants

A merchant accepts payment cards bearing the logo of one or more card brands as payment for its own goods or services. Hotels, online shops and hospitals billing patients are all merchants, answerable to their acquirer.

Service providers

A service provider is a business, other than a card brand, that is directly involved in handling account data on behalf of another entity, or that provides services able to affect the security of that data. Gateways, hosting providers, BPOs and payment facilitators are typical. A business that is both merchant and provider has two validations to consider.

Levels

Each card brand sorts merchants and service providers into levels, mostly by the annual volume of that brand's transactions. The highest level carries the heaviest validation, normally an annual on-site assessment by a Qualified Security Assessor. Lower levels usually validate by self-assessment questionnaire. As one example, Mastercard's own site places a merchant at its first level above six million combined Mastercard and Maestro transactions a year; other brands draw their lines differently, and the brands revise their programmes, so read the current page of each brand you accept.

Who decides your validation route

The PCI Security Standards Council writes and maintains the standard, qualifies the assessors and publishes the questionnaires. It does not decide who must comply, it does not set levels and it does not enforce. That authority sits with the card brands, each of which runs its own compliance programme, and with your acquirer, which applies those programmes to you and receives your evidence.

In practice there are two routes. A Report on Compliance is written by a QSA after testing every applicable requirement, and it comes with an Attestation of Compliance the QSA and your executive sign. A self-assessment questionnaire is completed by you and also ends in an Attestation of Compliance. Which questionnaire fits is a separate question with its own rules; our guide Which SAQ applies to you: eligibility explained covers eligibility, and PCI DSS validation step by step: ROC, SAQ and AOC walks through each route in order.

Service providers have one more decider: their clients. A client may insist on a ROC-backed AOC even where the brand rules would allow a questionnaire, because it needs that evidence for its own assessment.

Outsourcing to a compliant processor: what it changes and what it does not

A hosted payment page, a redirect, a validated point-to-point encryption terminal or tokenisation can take most of your systems out of the cardholder data environment and move you to a much shorter questionnaire. The design choices behind that are the subject of PCI DSS scoping and segmentation: shrinking the CDE.

What outsourcing does not do is make PCI DSS someone else's problem. You remain responsible for validating whatever is left in your scope, which on a website usually includes the page that loads or redirects to the payment form and the scripts on it. You also manage the provider: a written agreement stating which requirements it covers, and a yearly check of its compliance status. A processor's AOC covers the processor's services, not your use of them. How to read one is explained in How to verify a PCI DSS AOC and check a provider's compliance.

Decision table: your situation, the likely route and why

The routes below are the usual outcome, not a ruling. Your acquirer, the brands and, for providers, your clients have the final word, and every row assumes you confirm it with them.

Questions to ask your acquirer, and when to wait

Ask these before you commit

• Which level have you placed us at, for which card brands, and on what basis?
• Do you expect a ROC, or which self-assessment questionnaire, and do you require a QSA or an internal security assessor to sign it?
• When is our evidence due, and in what form: the AOC alone, or the full questionnaire and scan reports?
• Do we need quarterly scans by an approved scanning vendor, and do you want to see them?

Service providers should ask the same of the clients who contract with them, plus one more: which requirements do you expect us to cover, and which remain yours?

When it makes sense to wait

Waiting is never a way to avoid the obligation, but it can be the right order of work. Hold back on booking an assessment when a payment platform change is due within months, and wait if you do not yet know where card data flows; a validation built on a guessed scope fails. And wait before signing any questionnaire whose statements you cannot yet support with evidence, since your executive's signature on the AOC is a declaration to the acquirer. Tell the acquirer your plan and date rather than going silent. How long each stage then takes is covered in PCI DSS timeline: how long compliance takes, stage by stage.

Do you need PCI DSS: questions buyers ask