The PCI DSS requirements are twelve numbered requirements grouped under six control objectives, covering network security, protection of stored and transmitted account data, vulnerability management, access control, monitoring and testing, and security policy. They apply to every system that stores, processes or transmits payment card account data, plus anything connected to those systems.
Twelve sounds manageable until you read one. Each expands into dozens of testable sub-requirements, and an assessment runs against those, not the headline. This guide walks all twelve in their objective groups and names the evidence an assessor looks for. For a working sequence instead, start with the PCI DSS compliance checklist.
What the PCI DSS Requirements Are
The 12 PCI DSS requirements are organised under six control objectives, and the grouping is not decoration — it tells you which requirements fail together. The current version of the standard is v4.0.1.
The six objectives and their requirements:
| Control objective | Requirements |
|---|---|
| Build and maintain a secure network and systems | 1–2 |
| Protect account data | 3–4 |
| Maintain a vulnerability management programme | 5–6 |
| Implement strong access control measures | 7–9 |
| Regularly monitor and test networks | 10–11 |
| Maintain an information security policy | 12 |
Read as a system, the twelve describe a loop: define and segment the environment, protect the data inside it, control who can reach it, watch what happens, and govern it with policy and ownership. Teams treating them as independent checklist items find the gaps cluster at the seams — a system in scope for Requirement 1 but missing from Requirement 10's logging.
Who Writes the Standard and Who Enforces It
PCI DSS is written and maintained by the PCI Security Standards Council, founded by the major card brands. The Council publishes the standard — currently v4.0.1 — and does not enforce it. Enforcement sits with the card brands and, in practice, with your acquiring bank.
That split catches people out. There is no PCI certification issued by the Council, and anyone offering you one is selling something else. What exists is a validation document — an attestation you or an assessor signed — which your acquirer accepts or rejects, under an obligation that comes from your merchant agreement. So questions about which route applies, or what deadline you are working to, go to your acquirer. The Council's document library holds the standard, the questionnaires and the attestation templates.
The Cardholder Data Environment Sets the Size of the Job
Scope is the cardholder data environment — the CDE — and it is the biggest determinant of how much work the twelve requirements represent. The CDE is the people, processes and technology that store, process or transmit account data, plus systems connected to that environment or able to affect its security.
That last clause is where scope quietly expands. The jump host administrators use to reach the CDE is in scope, and so is the identity provider authenticating them, the logging platform receiving CDE logs, and the pipeline deploying code into it. None hold card data; all can compromise the systems that do.
Understate scope and the assessment stalls on an in-scope system you never hardened. Overstate it and you apply twelve requirements to half your estate for no benefit. Deliberate PCI DSS scope reduction — segmentation, tokenisation, a provider-hosted payment form — is the highest-return work in the programme, because it removes requirements rather than satisfying them.
What Counts as Account Data
Cardholder data is the primary account number (PAN), cardholder name, expiry date and service code. The PAN is the anchor: wherever it is stored, the other elements come into scope with it, and the PAN itself must be rendered unreadable.
Sensitive authentication data is the full track data from the magnetic stripe or chip, the card verification code, and PINs or PIN blocks. None of it may be stored after authorisation — not encrypted, not truncated, not retained. The common finding is not a database column; it is sensitive authentication data in debug logs, API traces, error-reporting payloads or support-ticket attachments because nobody told the application to redact it.
Want the twelve requirements mapped against what you already run?
Share your work email and we'll send a requirement-by-requirement gap view for your cardholder data environment, marking which of the twelve your current controls and evidence already cover.
The Six PCI DSS Control Objectives, Requirement by Requirement
Here are the six PCI DSS control objectives and the twelve requirements under each, with what the requirement demands and what an assessor asks to see. Evidence follows one pattern throughout — a documented expectation, a configuration matching it, and a record showing the control operated over time — so the question is never only "is this control in place" but "can you show it was in place all year".
Build and Maintain a Secure Network and Systems
Requirement 1 — network security controls. Control traffic into and out of the CDE and between it and everything else: documented, justified rules on firewalls, security groups and routers, with inbound and outbound traffic restricted to what the business needs.
Assessors ask for a current network diagram showing the CDE boundary and every connection crossing it, a data-flow diagram, the rule sets, a justification per rule, and evidence the rules are reviewed. The usual finding is a diagram that stopped matching reality two releases ago.
Requirement 2 — secure configurations. In-scope systems configured to a hardening standard with vendor defaults changed — default passwords, SNMP community strings, sample applications — and only necessary services, protocols and functions enabled.
Evidence is the hardening standard per system type plus configuration output from a sample of live systems showing it applied. For cloud and container estates the credible answer is infrastructure-as-code plus configuration scanning output, not a screenshot.
Protect Account Data
Requirement 3 — protect stored account data. Keep less, and make what you keep unreadable: a defined retention period with a business justification, a process that actually deletes data past it, the PAN rendered unreadable wherever stored, and key management controls around whatever cryptography you use.
Evidence is the retention policy, an inventory of every location account data is stored, proof of the deletion process running, and — most importantly — results of a search for account data outside the places you declared. Assessors also examine who holds keys and whether anyone can reach both the keys and the ciphertext they protect.
Requirement 4 — protect cardholder data with strong cryptography during transmission over open public networks. Any time cardholder data crosses a public network it must be protected with strong cryptography and secure protocols. The requirement also covers never sending unprotected PANs over end-user messaging technologies.
Evidence is an inventory of transmission points, TLS and certificate configuration for each, and scan output confirming weak protocols and cipher suites are refused. Findings sit at the edges — a legacy batch file transfer, or an internal endpoint that turns out to traverse a public path.
Maintain a Vulnerability Management Programme
A vulnerability management programme under PCI DSS spans two requirements: keeping malware out, and stopping known software weaknesses accumulating.
Requirement 5 — protect against malicious software. Systems at risk from malware need anti-malware protection that is current, actively running and generating audit logs, with periodic evaluation for system types considered not at risk. Scope has broadened to include phishing detection and protection mechanisms.
Evidence is deployment coverage against the in-scope asset list, definition currency, logs showing the protection ran, and the documented evaluation for anything excluded. Coverage gaps, not product choice, fail here.
Requirement 6 — develop and maintain secure systems and software. Two halves. Patching: known vulnerabilities identified and remediated on a defined timeline driven by risk ranking, critical and high-severity items fastest. Secure development: secure coding practices, code review, change control separating development from production, and protection for public-facing web applications.
Evidence is the vulnerability intake process, the risk-ranking method, patch records showing the timeline was met, change tickets with approvals and test evidence, secure-coding training records, and either web application firewall configuration or application vulnerability assessment results. Most of this sits in a ticketing system and has never been pulled into a form an assessor can sample.
Implement Strong Access Control Measures
Requirement 7 — restrict access by business need to know. Access to system components and account data limited to people whose jobs require it, with roles and privileges defined, documented and approved, from a default-deny position.
Evidence is the role definitions, approval records for each grant, and periodic access reviews showing someone removed what was not needed. Assessors ask for the review output and then test it — picking a user who left and checking whether the review caught them. It rarely does.
Requirement 8 — identify users and authenticate access. Every user gets a unique ID, shared and generic accounts are controlled or eliminated, authentication is strong, and multi-factor authentication is required for access into the CDE and for all remote access. Application and system accounts need managed credentials too.
Evidence is the user list reconciled against HR records, joiner-mover-leaver records, authentication policy configuration, MFA enforcement proof for every path into the CDE, and an inventory of service accounts with how their credentials are managed — service and break-glass accounts are where this is weakest. The discipline is the same access control model other frameworks ask for, held to a stricter bar.
Requirement 9 — restrict physical access. Physical access to the CDE and to media containing account data controlled, visitors identified and logged, media inventoried and destroyed securely when no longer needed, and point-of-interaction devices protected from tampering and substitution.
Cloud-hosted entities inherit most of this, so the evidence is the provider's attestation plus a responsibility matrix showing which parts remain yours. Offices handling paper forms, storing backup media or hosting card-present terminals carry it directly, and device inspection records are frequently missing.
Regularly Monitor and Test Networks
Requirement 10 — log and monitor all access. Audit logs capturing access to system components and account data, including privileged actions and access to the logs themselves, with synchronised time, protection against alteration, review for anomalies, and retention for a defined period.
Evidence is logging configuration per in-scope system, the retention setting, time synchronisation, access controls on the log store, alert definitions, and — the hard one — records showing log review happened and someone acted on it. "We have a SIEM" is not evidence of review.
Requirement 11 — test security of systems and networks regularly. Wireless access points detected; internal and external vulnerability scans on a schedule and after significant change, the external ones performed by an Approved Scanning Vendor; penetration testing on a defined cadence and after significant change; segmentation controls tested to confirm they hold; intrusion and change-detection mechanisms deployed.
Evidence is scan reports with passing results and remediation history for failures, the ASV scanning attestations, the penetration test report with scope and methodology stated, retest results, and segmentation test output. A failed scan is not a finding if you remediated and rescanned to a pass — the gap is having no record of the cycle. PCI DSS penetration testing covers how scope and cadence are judged.
Maintain an Information Security Policy
Requirement 12 — support information security with organisational policies and programmes. The governance requirement: a security policy reviewed on a defined cycle; documented scope reviewed periodically; roles and responsibilities with assigned ownership; awareness training; personnel screening where permitted; third-party service provider management including written agreements and monitoring of their compliance status; and a tested incident response plan.
Evidence is the policy set with approval and review dates, the scope documentation, role assignments, training completion records across the workforce, the service provider inventory with current attestations, the responsibility matrix for shared controls, and incident response test records. Requirement 12 fails more assessments than its subject matter suggests, because its controls are annual rather than continuous and nobody notices when a review date slides.
Version 4.0.1 and the End of the Transition
Version 4.0.1 is the current version of the standard, and the transition that shaped the last few years of PCI programmes is over. Version 3.2.1 was retired, and the requirements v4.0 introduced as future-dated became mandatory on 31 March 2025, so assessments now cover the full v4 set with no grace period left.
If your programme was built against v3.2.1 and maintained incrementally, the risk is a control that was once optional and is now required. The areas most often needing new work are authentication, targeted risk analyses justifying the frequency of certain activities, and the expectations around scripts on payment pages. The detail is in what changed in PCI DSS v4.
Meeting a Requirement by Other Means
Meeting a requirement by other means is permitted in v4, and it is the standard's most substantive structural change. Alongside the defined approach — meet the requirement as written — the customised approach lets an entity meet a requirement's stated objective by a different means, supported by a targeted risk analysis and documented in detail.
This is not a looser path. It shifts the burden onto you: articulate the security objective, describe how your control meets it, analyse the risk your alternative introduces, and give the assessor enough to test it — the assessor then has to design a test procedure, because the standard's own assumes the defined control. Use it where a modern architecture genuinely achieves the objective by other means, not as a route around a control you never built. The test is whether you would rather write and defend that analysis than implement the control as written.
How PCI DSS Compliance Gets Validated
PCI DSS compliance is validated by one of two routes, and which applies is set by your acquirer or the card brands, not chosen by you. A Report on Compliance is produced with a Qualified Security Assessor or, where permitted, an Internal Security Assessor, who tests every applicable requirement and samples systems and evidence. A Self-Assessment Questionnaire is completed by the entity itself, in one of several versions scoped to different payment channels. Both carry an Attestation of Compliance, the document your acquirer actually receives.
Neither is an audit opinion in the SOC 2 sense; PCI DSS versus SOC 2 covers why the documents are not interchangeable. Route and questionnaire follow transaction volume and channel: PCI DSS levels maps volume to validation expectations, and the SAQ types covers choosing the questionnaire. Get your acquirer to confirm in writing first — getting this wrong means scoping an assessment to the wrong document.
What Happens When You Are Not Compliant
What happens when you are not compliant is set privately, so treat published fine figures with suspicion. Card brands can impose fines through acquirers, who pass them on under your merchant agreement, but the amounts are contractual and confidential and the numbers circulating online are not sourced from the brands.
What is predictable is commercial rather than punitive. An acquirer can place conditions on your account, raise transaction costs, or withdraw card acceptance; after a suspected compromise a forensic investigation may be required at your expense; enterprise buyers make a current attestation a condition of contract. Non-compliance costs are unbounded where compliance costs are knowable — what PCI DSS compliance costs breaks down the knowable side, and you can model the programme cost first.
PCI DSS Requirements Questions Teams Ask
These are the PCI DSS requirements questions teams ask when they first map the twelve against what they already run.
All twelve apply to any entity in scope, but individual sub-requirements can be not applicable depending on how you operate. An entity storing no account data still has Requirement 3 obligations around not retaining sensitive authentication data, and a cloud-hosted entity still has Requirement 9, largely inherited from the provider with a responsibility matrix as evidence. Not applicable must be documented and justified, not assumed — the assessor tests the justification.
It reduces them, sometimes dramatically, but never removes them. Redirecting payment entry to a provider's hosted page or iframe keeps account data out of your systems, narrowing the cardholder data environment and often qualifying you for a much shorter questionnaire. You remain responsible for the systems controlling the redirect, the scripts on the payment page, third-party management under Requirement 12, and the provider's own compliance status.
No. The PCI Security Standards Council publishes the standard but issues no certification to assessed entities. What you produce is a Report on Compliance or a Self-Assessment Questionnaire plus an Attestation of Compliance, and the attestation is what your acquirer accepts. Vendors advertising PCI certification are selling something else — usually their own assessment service or a scan result.
For a company with reasonable engineering hygiene and a narrow cardholder data environment, three to six months of focused work before a first assessment is realistic. Scope drives it, not company size: a broad environment with account data in several systems and no segmentation can take a year. The slowest items need a history — log review records, access reviews, training completion — because an annual record cannot be produced retrospectively. Plan around those first.
See the twelve requirements as a live control set
Book a demo and we'll show how Konfirmity maps your systems to the twelve PCI DSS requirements, collects the recurring evidence automatically, and flags the annual controls before they lapse.
Book a demo
Scope First, Then Work the Twelve
The twelve requirements are a fixed list. The work they represent is not, and it is set almost entirely by the size of your cardholder data environment. Teams that scope first — drawing the real data flows, finding every place account data lands, then shrinking the footprint — spend far less effort than teams that start at Requirement 1 and work down.
Then map each of the twelve to the controls you already run and the evidence you can produce, and be strict about the difference between a control existing and a control being evidenced over time. The requirements that fail assessments are rarely the ones nobody built; they are the periodic ones that ran once and then drifted.
Work through the PCI DSS compliance checklist with your own architecture in front of you, confirm your validation route with your acquirer, and know what PCI DSS covers well enough to argue scope boundaries when an assessor pushes.
