PCI DSS is the rulebook the payment card industry wrote for itself. Its full name is the Payment Card Industry Data Security Standard, and it sets the minimum security controls any organisation must have in place if it stores, processes, or transmits cardholder data. If your business takes card payments — in a shop, online, or over the phone — PCI DSS applies to you. The current version is PCI DSS v4.0.1, and its job is narrow: keep the card data moving through your systems protected while it is there.
That is the whole answer. The rest of this page is the detail: who runs the standard, what its twelve requirements say in plain words, who has to comply, how you prove it — and what PCI DSS is not.
Who runs it, and why it binds if it is not a law
The standard is written and maintained by the PCI Security Standards Council (PCI SSC), an industry body founded by the major card brands — Visa, Mastercard, American Express, Discover, and JCB. The Council publishes and updates the standard; it does not enforce it.
Enforcement belongs to the card brands, and it reaches you through contracts. Your acquiring bank and the brands decide whether you must comply and how you must validate, and that obligation sits in the very agreement that lets you accept cards. The Council says this plainly itself: whether an entity is required to comply is at the discretion of the organisations that manage compliance programs, such as a payment brand or an acquirer.
So the honest description is this: PCI DSS is not a law, and no government issues your compliance certificate. But because it is written into the contracts of the payment system, it is binding in practice on everyone who participates in that system. Fall out of compliance and the consequences run through those contracts — up to, at the far end, losing the ability to accept cards at all.
The six goals and the twelve requirements
PCI DSS is organised as six goals, with twelve core requirements grouped underneath them. Each carries detailed sub-requirements, but the twelve headings show the shape of the whole standard.
Goal 1: Build and maintain a secure network and systems
- Requirement 1: Install and maintain network security controls — firewalls and their modern equivalents, configured deliberately and reviewed.
- Requirement 2: Apply secure configurations to all system components. In practice this starts with never leaving vendor-supplied default passwords and settings in place.
Goal 2: Protect account data
- Requirement 3: Protect stored account data. Keep as little of it as you can, make what you keep unreadable, and never store sensitive authentication data — full magnetic-stripe data, card verification codes, PINs — after authorisation.
- Requirement 4: Protect cardholder data with strong cryptography when it travels over open, public networks.
Goal 3: Maintain a vulnerability management program
- Requirement 5: Protect all systems and networks against malicious software, and keep that protection current.
- Requirement 6: Develop and maintain secure systems and software — patching known vulnerabilities and building or buying software that does not introduce new ones.
Goal 4: Implement strong access control measures
- Requirement 7: Restrict access to system components and cardholder data to people whose jobs genuinely need it — business need to know, nothing broader.
- Requirement 8: Identify users and authenticate access to system components, with multi-factor authentication for access into the cardholder data environment.
- Requirement 9: Restrict physical access to cardholder data — the locked room matters as much as the login.
Goal 5: Regularly monitor and test networks
- Requirement 10: Log and monitor all access to system components and cardholder data, so that when something happens you can reconstruct it.
- Requirement 11: Test the security of systems and networks regularly — vulnerability scans and penetration testing, not a one-off check at audit time.
Goal 6: Maintain an information security policy
- Requirement 12: Support information security with organisational policies and programs — the written policy, staff awareness, a maintained list of service providers that touch card data, and a tested incident response plan, ready before you need it.
Read the twelve together and a pattern emerges: this is a baseline, not a ceiling. The Council describes PCI DSS as a baseline of technical and operational requirements for protecting payment account data. It tells you the floor. What good looks like above that floor is still your judgement — the same judgement any sound risk management process asks for.
Who has to comply
Everyone in the payment chain who touches card data. The Council’s own audience definition covers entities that store, process, or transmit cardholder data or sensitive authentication data, or that could affect the security of the environment that data lives in. It names merchants, processors, acquirers, issuers, and service providers.
Two things follow. First, size is no exemption: a market stall with a card terminal and a multinational retailer are both in scope, because scope follows the data, not the headcount. Second, outsourcing shrinks your burden but does not erase it — if a provider processes payments for you, the heavy controls sit with them, but you remain responsible for choosing a compliant provider and being able to show that you did.
The burden then scales with volume. Merchants are sorted into levels by annual transaction volume, and the level drives how much validation work you owe. At the top — Visa’s scale, for example, puts Level 1 at over six million transactions a year — the assessment is formal and external. At the smaller end the standard is the same but the proof is lighter: a self-assessment, described below. Each brand sets its own thresholds, so your level is a question to settle with your acquirer, not a number to assume.
How you prove it: SAQ, ROC, and the attestation
Compliance is validated annually, and there are two main routes.
The Self-Assessment Questionnaire (SAQ) is the route for most merchants. There are nine SAQ types in v4.x, and you complete the one that matches how you take payments. SAQ A is the lightest: it fits merchants who fully outsource card handling to compliant providers and never hold card data on their own systems. SAQ D is the longest and most demanding: it covers merchants who fit no other category, and service providers. Between them sit variants for standalone terminals, virtual terminals, and other specific setups. Choosing the wrong SAQ is a common and avoidable error — the form must match the payment flow you actually have.
The Report on Compliance (ROC) is the formal route for the largest merchants and service providers. An independent Qualified Security Assessor (QSA) — an organisation qualified and trained by the Council — performs the assessment and produces the report. Large-scale environments may also face quarterly network scans by an Approved Scanning Vendor (ASV).
Whichever route you take, it ends with an Attestation of Compliance (AOC): the signed statement that accompanies the SAQ or ROC, declaring your compliance status. The validation documents go to your acquirer and the brands that ask for them.
What PCI DSS is not
Three clarifications, because this site’s readers meet PCI DSS from the risk and continuity side, where neighbouring standards blur together.
It is not a law. It is an industry standard enforced through contracts. Data protection law still applies alongside it — a separate obligation that PCI compliance does not discharge.
It is not a business continuity standard. PCI DSS says almost nothing about recovering your business after a disruption: no recovery time objectives, no impact analysis, no continuity plan requirement of the kind ISO 22301 asks for. Readers who know ISO 27001, explained on this site will recognise the neighbourhood — both are security frameworks — but ISO 27001 certifies a management system, while PCI DSS prescribes a specific control set for one kind of data. Neither keeps your business running when something breaks. That is continuity work, and it is separate work.
It is not a guarantee. A compliant organisation can still suffer a breach; a breach does not automatically prove an organisation was non-compliant. Compliance is a point-in-time attestation against a baseline, and treating it as the finish line rather than the floor is the most common misreading.
Where PCI DSS meets continuity and risk work
PCI DSS is a security standard, but three parts of it land squarely on the desks this site writes for.
First, incident response is inside the standard. Requirement 12 expects an incident response plan ready to execute when card data is compromised — roles, escalation, and communication worked out in advance. The PCI plan and your wider response arrangements should be the same muscle, not two documents that have never met. Our guide to cyber incident response for small business covers the operational side of that work.
Second, service providers are a named obligation. Requirement 12 also requires you to manage the providers that handle card data for you or could affect its security — a maintained list, due diligence, and written acknowledgment of their responsibilities. That is third-party risk management wearing a PCI badge — the same discipline set out in our guide to third-party risk management.
Third, it belongs in the risk register, scoped correctly. Card data compromise is a risk like any other: it has owners, controls, a review cadence, and an attestation date that comes round every year. Recorded that way — as one row among your other assessed risks, not a separate compliance universe — it stays visible between audits. Our risk register guide sets out the fields and cadence that keep entries like this one alive.
The short version
If card data touches your systems, PCI DSS applies to you. The current version is v4.0.1. Twelve requirements under six goals set the floor; your merchant level sets the validation burden; and an SAQ or a QSA-assessed ROC with its Attestation of Compliance is how you prove it each year. It will not write your continuity plan, and it was never meant to. It does one job — keeping payment card data protected — and your acquirer will measure you against it.