In plain words
Think of card numbers as keys to other people’s houses. If you keep a box of them in your office, you need a strong lock, a guest list, cameras and regular checks that all of it works. If you never keep the keys at all, there is much less to protect.
The Payment Card Industry Data Security Standard (PCI DSS) is that set of locks and checks for card data. It was created by the major card brands and is maintained by the PCI Security Standards Council. 1 It applies to any company that stores, processes or transmits card numbers: merchants, payment processors, card issuers and the technology suppliers that work for them.
It is not a law in most countries. It is enforced through contracts. Card schemes require it, and the banks and payment firms in the chain pass the requirement on to every company they work with.
How it works
How PCI DSS compliance works
The same cycle repeats every year.
-
1
Map where card data goes
Every system, person and supplier that stores, processes or transmits card data, or could affect its security, is in scope.
-
2
Shrink the scope
Send card data straight to a processor, replace it with tokens and separate what remains. Fewer systems in scope means fewer controls to prove.
-
3
Apply the controls
Encryption, access control, logging, vulnerability scans, penetration testing and written policies, for everything still in scope.
-
4
Validate and report
Complete a self-assessment or an audit, and send the result to your acquirer or card partner. Then keep the controls running until next year.
What the standard asks for
The current version, PCI DSS v4.0.1, has 12 core requirements grouped under six goals. 2
Secure networks
Network security controls and secure configuration of every system.
Protect account data
Protect stored card data, and encrypt it when it travels over open networks.
Manage vulnerabilities
Protection against malware, and secure development and patching of systems.
Control access
Access only for those who need it, strong authentication, and physical security.
Monitor and test
Log and monitor all access, and test security regularly.
Policy
An information security policy and programme, owned by the business.
Version 4.0 was published in 2022 and replaced the older 3.2.1. Version 4.0.1 followed in 2024 as a clarifying update. Requirements that v4.0 had marked as future-dated became mandatory at the end of March 2025, so any assessment today is against the full set. 2
Levels, SAQs and ROCs
How you prove compliance depends on two things: whether you are a merchant or a service provider, and how many card transactions you handle. The levels are set by the card brands and your acquirer, not by the standard itself, so check the exact thresholds with them.
| Merchant | Service provider | |
|---|---|---|
| Who it is | A business that accepts card payments from its customers | A business that stores, processes or transmits card data for others, such as a processor, a card issuing platform or a hosting firm |
| Number of levels | Usually four, by yearly transaction volume | Usually two, by yearly transaction volume |
| Highest level | The largest merchants, for Visa and Mastercard those with over six million card transactions a year | Providers above a volume threshold set by each card brand |
| How the top level proves compliance | A Report on Compliance (ROC) by a Qualified Security Assessor (QSA) | A ROC by a QSA |
| How lower levels prove it | A Self-Assessment Questionnaire (SAQ) | An SAQ, if the card brands allow it |
Both routes end with an Attestation of Compliance (AOC), the short signed document that partners ask for. There are several SAQ types. The shortest ones are for businesses that hand all card data to a third party and never touch it. The longest, SAQ D, covers nearly the whole standard.
How to keep your scope small
Shrinks scope
- Hosted payment pages or card fields from your processor
- Tokenisation: store tokens, never card numbers
- Showing card details in the app through the processor’s secure component
- Separating the few systems that must touch card data
Grows scope
- Card numbers passing through your own servers or APIs
- Card numbers in logs, support tickets or spreadsheets
- One flat network where every system can reach card data
- Staff reading card numbers over the phone
Using a compliant processor does not make you compliant by itself. It moves most of the work to them, but you still validate the part that remains with you, even if that is a short SAQ. Card issuing works the same way: if your card processor holds the card numbers and you only ever see tokens, most of the standard sits with them.
PCI DSS in the UK, EU and Gulf
PCI DSS is a global standard. The same version applies in London, Frankfurt, Dubai and Riyadh, because it comes from the card schemes rather than from any government. What differs is the local law around it. Data protection rules such as GDPR apply to card data too, and regulators in all these markets expect strong security from the firms they supervise. In the Gulf, central bank cyber security rules and national card networks may add their own requirements, so check them with your local partner.
Example: a wallet with cards
Yusuf is launching a wallet with a virtual debit card, issued through a BIN sponsor and a card processor.
- Design. His team agrees that full card numbers will never touch their servers. The processor creates and stores them.
- In the app. When a customer taps “show card details”, the number appears inside the processor’s secure component. Yusuf’s systems only see a token and the last four digits.
- Partner check. The sponsor asks for the processor’s AOC and for Yusuf’s own evidence for the part that remains with him.
- Every year. Yusuf’s team reviews the data flows again, so a new feature does not quietly pull card data back into scope.
Common misconceptions
“Our processor is PCI compliant, so we are too.”
Their compliance covers their systems. You still own and validate the parts of the flow that run in yours.
“PCI DSS is a one-off certificate.”
Compliance is validated every year and the controls must work all year. A passed assessment says nothing about a system changed the week after.
“Encrypting card numbers takes them out of scope.”
Encrypted card data stays in scope for whoever can decrypt it. Tokenisation and not handling the data at all are what shrink scope.
FAQ
What is PCI DSS in simple terms?
A set of security rules for anyone who handles payment card numbers. It covers how card data is stored, transmitted and protected, who can access it, and how systems are tested and monitored.
Is PCI DSS a legal requirement?
It is not a law in most countries. It is a contractual requirement: card schemes require it, and acquirers and card issuers pass it on to the companies they work with. Failing it can lead to fines from the acquirer or the loss of the right to accept or issue cards.
What is the current version of PCI DSS?
PCI DSS v4.0.1, published by the PCI Security Standards Council in 2024. It replaced v4.0, and the requirements that v4.0 had marked as future-dated became mandatory at the end of March 2025.
What is the difference between an SAQ and a ROC?
An SAQ (Self-Assessment Questionnaire) is a checklist a company completes itself, used by smaller merchants and service providers. A ROC (Report on Compliance) is a full assessment by a Qualified Security Assessor, required at the highest levels.
Do I need PCI DSS if I use a payment processor?
Usually yes, but in a much smaller form. If card numbers go straight to the processor and never pass through your systems, you typically complete one of the shortest SAQs instead of a full assessment.
How do I reduce PCI DSS scope?
Keep card numbers out of your systems. Use the processor's hosted payment fields or card components, store tokens instead of card numbers, and separate any system that does touch card data from the rest of your network.
Related terms
Sources
-
1
PS
PCI Security Standards Council PCI Security Standards Council
https://www.pcisecuritystandards.org -
2
PS
PCI Security Standards Council Document library: PCI DSS and SAQs
https://www.pcisecuritystandards.org/document_library/
