The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for any organization that stores, processes or transmits payment card data, or whose systems can affect the security of that data. It is maintained by the PCI Security Standards Council, an industry body formed by the major card brands, and enforced through contracts: card brands require it of acquiring banks, and acquirers require it of the merchants and service providers they work with. It is not a government law, but for a business that takes cards it is rarely optional. People often shorten it to “PCI”, but the Council publishes several standards; PCI DSS is the data security one.
At a glance
- PCI DSS covers any business that handles card data, from a single shop to a large service provider; what changes with size is how compliance is validated.
- Compliance is generally validated each year, by a self-assessment questionnaire or an assessor’s report, depending on your level and how you accept cards.
- Scope is the main cost driver: every system that stores, processes or transmits card data, or connects to one, is in scope unless it is properly segmented.
- Hosted payment pages, tokenization and point-to-point encryption can shrink scope but do not remove your obligations.
- Requirements and penalties are set by the card brands and your acquirer, so ask your acquirer what applies to you.
What problem it solves
Card numbers are valuable to criminals, and a single breach can expose thousands of them. Before a common standard, each card brand had its own security program and merchants faced conflicting demands. PCI DSS gives everyone in the payment chain one baseline: protect stored card data, encrypt it in transit, control access, patch and monitor systems, test security regularly, and keep written policies.
For a buyer, the practical problem is usually narrower. Your acquirer or payment processor asks you to prove compliance, a customer asks whether your platform is PCI compliant, or you are moving to a new e-commerce, contact center or point-of-sale system and need to know whether it widens or shrinks your obligations.
How it works
Scope. The first step is finding where card data lives and flows: payment terminals, web servers, call recordings, databases, the networks that connect them and the people with access. This set of systems is called the cardholder data environment. Systems that can reach it are often in scope too, which is why network segmentation with firewalls matters so much.
Requirements. The standard groups its requirements around a secure network, protecting stored and transmitted card data, vulnerability management, access control, logging and monitoring, regular testing such as scans and penetration testing, and security policy. The detailed requirements change between versions, so work from the current version published by the Council.
Validation. Each year, a business shows that it meets the standard in the form its level calls for, summarized in an Attestation of Compliance (AOC). The levels and validation types are set out in the next section.
Shared responsibility. When you use a payment processor, hosted checkout, cloud provider or contact center platform, some requirements move to that provider and some stay with you. The provider’s AOC and responsibility matrix show where the line falls.
Merchant and service provider levels
The card brands, not the PCI Security Standards Council, define the levels and decide how each business must validate compliance, and your acquirer tells you which level you are in. Levels depend mainly on yearly transaction volume with each brand, and thresholds differ by brand and change over time. The table shows the broad pattern; confirm your level and the evidence needed with your acquirer. This is not legal advice.
| Level | Who it typically applies to | How compliance is usually validated | Evidence to ask for |
|---|---|---|---|
| Merchant Level 1 | The largest merchants (roughly above 6 million transactions a year with a major brand), plus merchants a brand moves up, for example after a breach | Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA), or an internal assessor where the brand allows; quarterly external scans where applicable | ROC, AOC, scan reports |
| Merchant Level 2 | Mid-sized merchants (roughly 1 to 6 million transactions a year) | Annual Self-Assessment Questionnaire (SAQ), with an assessor’s involvement for some SAQ types depending on the brand; scans where applicable | SAQ, AOC, scan reports |
| Merchant Level 3 | Smaller e-commerce merchants (roughly 20,000 to 1 million online transactions a year) | Annual SAQ generally required (Mastercard’s rules require one), submitted as the acquirer directs; quarterly ASV scans where applicable | SAQ and AOC, scan reports |
| Merchant Level 4 | All other merchants | Compliance is required; brands generally leave validation to the acquirer, which often asks for an annual SAQ; quarterly ASV scans where applicable | SAQ and AOC, scan reports |
| Service provider Level 1 | Larger service providers, and some provider types such as processors and payment gateways, above a brand’s threshold | Annual ROC by a QSA; quarterly external scans where applicable | ROC, service provider AOC, responsibility matrix |
| Service provider Level 2 | Smaller service providers below that threshold | Annual SAQ for service providers; scans where applicable | SAQ, AOC, responsibility matrix |
Validation types. Each SAQ type matches a way of accepting cards, from short versions for fully outsourced online checkouts to the full version for businesses that store card data or fit no other type. A ROC is a formal assessment in which a QSA tests each applicable requirement and documents the results. Internet-facing systems in scope generally need quarterly external vulnerability scans by an Approved Scanning Vendor (ASV). For a buyer, the provider’s AOC is the usual proof.
When it matters for buyers
- When choosing a payment, e-commerce or point-of-sale platform. The design decides how much of your environment stays in scope.
- When taking card payments by phone. Call recordings, agent screens and chat transcripts can pull a contact center into scope; pause-and-resume recording or payment tools that keep card numbers away from agents can help.
- When your acquirer asks for validation. Missing or late paperwork can bring fees from the acquirer, so know your validation level and deadline.
- When outsourcing IT or security. A managed provider with access to in-scope systems is part of your compliance picture.
- When a customer or partner asks. Service providers handling card data on behalf of others are usually expected to show an AOC.
Our governance, risk and compliance overview covers how advisors and platforms help with assessments and evidence.
Questions to ask vendors
- Can you provide your current Attestation of Compliance, and which services does it cover?
- Which PCI DSS requirements do you handle, which do we share, and which stay entirely with us?
- Does card data ever touch our systems, networks or staff when we use your product?
- Do you offer tokenization, hosted payment pages or validated point-to-point encryption?
- How do you keep card numbers out of call recordings, chat logs and support tickets?
- At which service provider level do you validate, who is your assessor, and when is your next assessment?
- How will you notify us if your compliance status changes or you suffer a breach?
How it differs from SOC 2
SOC 2 is an attestation report in which an independent CPA firm gives its opinion on a service organization’s controls against broad trust services criteria; the organization chooses its scope, and the report is not specific to card data. PCI DSS is a prescriptive standard focused only on protecting payment card data, required by the card industry for anyone who handles it. The two overlap on many controls, but one does not substitute for the other. Like HIPAA for health data, PCI DSS is one of the obligations a governance, risk and compliance (GRC) program maps into one set of controls.