PCI DSS and Its Relatives

48.0 What this chapter gives you#

1. You will be able to say who writes PCI DSS, who enforces it and why the Council that owns the standard cannot fine anybody for breaking it.
2. You will be able to explain why your validation level follows transaction volume while the work you must actually do follows how close the card number gets to your own computers.
3. You will be able to explain why the same coffee chain answers 27 requirements or 139 depending on a decision a developer made in an afternoon.
4. You will be able to describe what point-to-point encryption and tokenisation do to scope, and name the conditions that silently forfeit the reduction.
5. You will be able to state the storage rules exactly: sensitive authentication data never retained after authorisation even encrypted, the account number rendered unreadable, display limited to the leading digits and the last four.
6. You will be able to say what an Attestation of Compliance proves — a date, a version, a scope and a sample — and what it therefore cannot tell a buyer.
7. You will be able to describe requirements 6.4.3 and 11.6.1, explain the browser-side attack they exist for, and say what the January 2025 revision of SAQ A did to them.
8. You will be able to state the version position as it stood in August 2026: v4.0.1 the only active version, every future-dated requirement effective since 31 March 2025, and a Request for Comments run from 3 June to 20 July 2026.
9. You will be able to place PCI DSS alongside the UK GDPR and explain how an organisation can be compliant with one and in breach of the other on the same day.
10. You will be able to tell a supplier questionnaire that Direct Debit data creates no cardholder data environment, because the account number is the defining factor and there is no account number.

The plain version#

Imagine a card number is a key to a house with the address stamped on it. Anyone who copies the key can walk in. The person who loses the key is not the person who gets burgled, and the person who gets burgled is not the person who pays for the new locks. That gap between who is careless and who suffers is the whole reason the rules in this chapter exist.

Six card companies sit at the centre of the world’s card payments: American Express, Discover, JCB, Mastercard, UnionPay and Visa. In the early 2000s each wrote its own list of safe-handling rules for card numbers, so a shop taking several brands had to satisfy several overlapping lists. In 2006 they gave up on that and set up a joint body to write one list instead. It is called the PCI Security Standards Council, and the list it maintains is the Payment Card Industry Data Security Standard, or PCI DSS.

Here is the part almost everybody gets wrong. The Council that writes the rules cannot punish you for breaking them. It is not a government; it has no inspectors, no courts and no power to fine anybody, and it is closer to the committee that writes the specification for a plug socket. What gives PCI DSS teeth is that when your shop signed a contract with the bank that pays you — the acquirer — that contract said you would follow PCI DSS. Break it and the person who comes after you is your bank, holding your own signature.

So how much of the rulebook applies to you? Not, as you might expect, according to how big you are. Size decides how you have to prove it. What you actually have to do depends on something much less obvious: how close the card number gets to your own computers.

Take a real-shaped example. A coffee chain has forty shops and a website, and puts 2.4 million Visa card payments through in a year. Under Visa’s published programme at the time of writing, a merchant doing between 1 million and 6 million Visa transactions a year across all channels is a Level 2 merchant, which means it fills in a self-assessment questionnaire once a year rather than paying an outside assessor to write a full report. Good news, so far.

Now look at the website. The Council publishes different questionnaires for different shapes of business, and the one you may use depends on where the payment form comes from. The two numbers below are the Council’s own, published in the April 2025 revision of its questionnaire guidance and accurate at time of writing.

If the checkout page drops in a little window supplied whole by the payment provider — an iframe, or a redirect off to the provider’s own page — then every part of the page that touches the card number came from the provider, not the coffee chain. The chain uses the shortest questionnaire, SAQ A, and answers 27 requirements. If instead the chain’s own website builds the payment form, so the card number is typed into a box the chain’s own code drew on the screen before being sent on, the chain must use a different questionnaire, SAQ A-EP, and answer 139.

Same company. Same turnover. Same forty shops. Twenty-seven items or 139, decided years earlier by a developer choosing how to build a checkout page, probably in an afternoon, probably without knowing that was the decision being made.

The shops themselves can be shrunk the same way, and there are only two tricks that genuinely work.

The first is point-to-point encryption, and it is a locked post box. A card reader approved for it scrambles the card number inside the reader itself, in hardware, the instant the card is read, using a key the shop does not have and cannot get. What travels through the shop’s tills, network and broadband is unreadable, unscrambled only much later inside the payment provider’s own protected building. The shop is carrying sealed post it cannot open. Break into the till and you get nothing worth stealing, and the questionnaire the shop fills in gets dramatically shorter.

The second is tokenisation, and it is a cloakroom ticket. When a customer saves a card for next time, the shop keeps not the card number but a meaningless reference — say tok_8813f2 — that only the payment provider can turn back into a real number, and which the shop can hand back to charge the customer again next month. A thief who steals the shop’s entire customer database steals a pile of tickets for a cloakroom they cannot enter.

What is in the rulebook is less exotic than people expect: twelve numbered sections under six goals, mostly the security housekeeping any competent organisation should be doing anyway. Know what computers you have, change the default passwords, encrypt card numbers at rest and in transit, patch things, restrict access, keep logs and read them, test yourself, write it down. Three specifics are unusually concrete, and these are the figures in force at the time of writing: passwords in scope must be at least twelve characters, or eight if the system genuinely cannot manage twelve; external vulnerability scans must be run at least once every three months by a scanning company the Council has approved; and patches for critical vulnerabilities go on within one month of release.

And when it goes wrong, the money moves in a direction most people do not expect. The card schemes do not bill the breached shop. They assess the shop’s acquiring bank, and the bank then comes after the shop under the contract; Visa’s published rules go further and forbid the bank from telling the shop that Visa imposed the charge on it. Separately and quite independently, the Information Commissioner’s Office can fine a UK organisation for losing personal data up to £17.5 million or four per cent of total annual worldwide turnover, whichever is higher — the statutory maximum in force at the time of writing. Card rules and data protection law are two different animals arriving from two directions on the same bad day.

Where the plain version stops being true#

“Certified” is the wrong word, and the annual pass is not a state of being. Nothing in PCI DSS produces a certificate. What it produces is an Attestation of Compliance, a signed declaration about a single assessment covering a defined scope on a defined date. It is a photograph, not a passport. The standard’s own position, and the schemes’, is that compliance is a continuous obligation: Visa’s rules state that a service provider and merchant must always maintain full compliance, and the standard bakes this in by requiring service providers to review at least once every three months that staff are actually performing security tasks as documented, and to reconfirm their own scope at least once every six months. An organisation can hold a perfectly valid attestation dated four months ago and be flagrantly non-compliant today, and frequently is. Passing the test is not the obligation; meeting the standard every day is, and the test is only evidence.

The club does not fine you, and nobody publishes the tariff. The members’-club analogy is wrong in two ways that matter commercially. First, the direction: the schemes assess the acquirer or issuer, who then recovers under contract, which is why “the PCI fine” is a phrase used by people who have never seen the paperwork. Second, the amounts. Circulating figures for per-card penalties and monthly non-compliance charges are not published by the Council, which does not set them, and the schemes do not put numbers on them either — the Council states plainly that any fines or penalties are a matter for each participating payment brand’s own programme. Anyone quoting a precise penalty schedule is quoting marketing, a leaked contract, or an invention. One published nuance is revealing, though: Visa states that assessments may be waived where a forensic investigation demonstrates there was no evidence of PCI DSS non-compliance prior to and at the time of the breach. The attestation is not what protects you. The evidence trail behind it is.

Tokenisation and point-to-point encryption reduce scope. They do not remove you from the standard, and the reduction is conditional. This is where the cloakroom-ticket and locked-post-box analogies mislead most expensively. A merchant using a validated, PCI-listed P2PE solution still fills in a questionnaire and still has requirements to meet, and eligibility for the short version depends on conditions the merchant can silently fail: all payment processing must run through the validated solution, no account data may be received or stored electronically by any other route, retained data must be on paper not received electronically, and — the one that catches people — the merchant must have implemented all the controls in the P2PE Instruction Manual supplied by the solution provider. That manual is a set of obligations, not a leaflet. Listings also expire, and the Council is explicit that solutions on its list of expired validations are no longer considered validated. Scope reduction is a thing you maintain, not a thing you buy. Tokenisation has the mirror-image trap: the tokens may be harmless, but the vault mapping them back to card numbers is squarely in scope for somebody, and if the merchant can retrieve the original number from the token, the merchant has escaped nothing.

You do not choose your questionnaire, and PCI DSS does not cover fraud. The Council writes the questionnaires but does not decide who may use which. That decision belongs to what the Council calls the compliance-accepting entity — in practice the acquirer, the payment facilitator or the brand. The confusion is live enough that the Council issued a bulletin on 4 August 2026 revising its FAQ 1331 specifically to clarify that merchants should always consult their compliance-accepting entities to confirm validation and reporting requirements, because an earlier May 2025 version of that guidance was being misread. Separately, the whole standard concerns the confidentiality of stored and transmitted account data. It is not about fraud. It will not tell you whether the person holding the card is the cardholder, it does not govern chargebacks, and it does not deliver strong customer authentication. Those live elsewhere, including in 3-D Secure and the regulatory authentication regime, treated below as relatives rather than parts of the same thing.

The technical version#

What PCI DSS is, and who owns it#

The Payment Card Industry Data Security Standard is a private technical standard owned and maintained by the PCI Security Standards Council, LLC, based in Wakefield, Massachusetts. The Council was formed in 2006 and is led by a policy-setting Executive Committee drawn from its Founding Members and Strategic Members: American Express, Discover Financial Services, JCB International, Mastercard, UnionPay and Visa Inc. Participating Organisation membership is open to merchants, banks, processors, hardware and software developers and point-of-sale vendors, who gain access to Request for Comments periods and drafts.

The division of labour, in the Council’s own words, is the single most load-bearing statement in the subject. The Council is responsible for developing and managing the PCI Security Standards and the related qualification and listing programmes; each participating payment brand maintains its own separate compliance enforcement programme, including which entities must validate compliance, at what validation level, whether an entity may complete a Self-Assessment Questionnaire or must complete a Report on Compliance, and any fines or penalties. Visa states the same split from the other side: the Council owns, maintains and manages PCI DSS and its supporting documents, while Visa manages all data security compliance enforcement and validation initiatives.

PCI DSS is therefore not legislation anywhere. It reaches you through a chain of private contracts: scheme rules bind the acquirer, the acquirer’s merchant agreement binds the merchant, and the merchant’s contracts bind its suppliers. That chain is not weaker than a statute in practice — it can terminate your ability to accept cards, worse for most businesses than a fine — but it is legally a different creature, and confusing the two produces bad advice in both directions.

The enforcement chain, concretely#

Visa’s programme is Account Information Security, and the governing instrument is the Visa Core Rules and Visa Product and Service Rules. Visa’s published summary, accurate at time of writing, states that issuers and acquirers are responsible for ensuring the PCI DSS compliance of their service providers and merchants, including service providers the merchant is using, and that a service provider and merchant must always maintain full compliance, citing Visa Core Rules section IDs 0002228 and 0008031. Where a service provider or merchant does not comply or fails to rectify a security issue, Visa may assess a non-compliance assessment to the issuer or acquirer, who is responsible for paying all assessments and must not represent that Visa has imposed any assessment on the service provider or merchant, citing section ID 0001054. Visa also states that assessments may be waived where there is no evidence of PCI DSS non-compliance prior to and at the time of a data breach, as demonstrated during a forensic investigation.

Mastercard’s programme is Site Data Protection. Its published process, at time of writing, has the merchant determine its level using Mastercard transaction volume from the most recent 52-week period, confirm the applicable validation requirement, engage an approved assessor where required, and submit validation documents to the acquirer, who submits an SDP Acquirer Submission and Compliance Status Form semi-annually reporting progress for Level 1 and Level 2 merchants. Level 3 and Level 4 merchants need not validate compliance to Mastercard, but the acquirer must validate to Mastercard that it has a risk management programme identifying and managing payment security risk within those portfolios. Those merchants are still required to comply; only validation is excused.

Visa also operates the Technology Innovation Programme, which at time of writing eliminates the requirement to validate PCI DSS compliance for eligible merchants where at least 75 per cent of yearly transactions originate through EMV chip-enabled terminals, a validated point-to-point encryption solution, or an integrated tokenisation solution meeting the EMVCo tokenisation specification. Note the precise scope of that relief: it removes the obligation to validate, not to comply.

Validation levels#

Levels determine how you prove compliance, not what you must do. The two largest schemes’ published criteria, accurate at time of writing, are below. They are not identical, and a merchant that is Level 2 under one may be Level 1 under another because each scheme also picks up the other’s Level 1 designations.

Visa notes that level identification is based on the corporate entity’s total volume of Visa transactions, inclusive of credit, debit and prepaid, in one country or with one acquirer per year, and that volume from independently owned and operated locations such as franchisees may be excluded if the corporate entity does not process it.

Service providers are treated more strictly. Visa’s published criteria at time of writing put VisaNet processors and any service provider storing, processing or transmitting over 300,000 Visa transactions annually at Level 1, requiring an annual on-site assessment and an AOC signed by both the service provider and the QSA; those below 300,000 are Level 2 and submit a signed SAQ D or an AOC including QSA signature, and QSA validation is required before any service provider can be listed on the Visa Global Registry of Service Providers. Mastercard’s service provider levels are defined by role rather than volume: at time of writing all Third-Party Processors, Staged Digital Wallet Operators, Digital Activity Service Providers, Business Payment Service Providers, Token Service Providers, 3-D Secure Service Providers, Installment Service Providers and Merchant Payment Gateways are Level 1, together with AML and sanctions service providers, Data Storage Entities and Payment Facilitators above 300,000 combined Mastercard and Maestro transactions annually; those below that threshold, plus Terminal Servicers, are Level 2. Mastercard also recommends at time of writing that Level 1 and Level 2 service providers demonstrate compliance with the Designated Entities Supplemental Validation appendix. For any service provider eligible to self-assess, SAQ D for Service Providers is the only questionnaire; there is no short form.

Scope: account data, the CDE, and where the boundary is drawn#

PCI DSS applies to all entities that store, process or transmit cardholder data or sensitive authentication data, or that could impact the security of either. Cardholder data comprises the Primary Account Number, cardholder name, expiry date and service code. Sensitive authentication data comprises full track data — magnetic stripe data or the equivalent on a chip — the card verification code, and PINs and PIN blocks. Together these are account data. The PAN is the defining factor: the Council’s position is that if an entity stores, processes or transmits PAN, a cardholder data environment exists and PCI DSS requirements apply to it. The storage rules that follow are unforgiving, and are worth stating exactly as they stand at time of writing.

Requirement 3.3.1 as published states that SAD is not stored after authorisation, even if encrypted, and that all SAD received is rendered unrecoverable upon completion of the authorisation process; the narrow exception for issuers and companies supporting issuing services is defined separately at Requirement 3.3.3. Requirement 3.4.1 as published states that PAN is masked when displayed, with the BIN and last four digits the maximum number of digits to be displayed, such that only personnel with a legitimate business need can see more.

The cardholder data environment is not only the systems that touch account data. As the Council defines it, the CDE comprises system components, people and processes that store, process or transmit account data, plus components that do not but have unrestricted connectivity to those that do; and PCI DSS additionally applies to components, people and processes that could impact the security of account data. That third category is where most scoping arguments happen, because it pulls in authentication servers, remote access infrastructure, logging servers, jump boxes, monitoring agents and increasingly the entire identity plane.

Scope reduction by segmentation is permitted, and the Council’s test is strict: to be out of scope, a system component must be isolated from the CDE such that it could not impact the security of the CDE even if it were compromised. Requirement 12.5.2 obliges the assessed entity — not its assessor — to confirm scope accuracy at least once every 12 months, identifying all locations and flows of account data and all systems connected to or capable of impacting the CDE, and to retain the documentation; Requirement 12.5.2.1 tightens this for service providers to at least once every six months and upon significant change. Where segmentation is relied upon, Requirement 11.4.5 requires penetration testing of the segmentation controls at least once every 12 months and after any changes, and Requirement 11.4.6 requires it at least once every six months for service providers.

Tokenisation and P2PE as scope-reduction mechanisms#

Tokenisation replaces the PAN with a surrogate value, and its scope effect turns on one question: can the entity holding tokens retrieve the PAN? If it can, the token is a key to cardholder data and the retrieval path is in scope. If it cannot, the token is not cardholder data and the systems holding it may fall outside the CDE, subject as always to whether they could impact the CDE’s security by other routes. The vault performing the mapping is in scope for whoever operates it, in practice usually a service provider assessed at Level 1. Where the tokens are EMV payment tokens issued under the EMVCo Payment Tokenisation Specification Technical Framework, the issuing entity is covered by a separate PCI standard, the Token Service Provider Standard, and Mastercard classes all TSPs as Level 1 service providers at time of writing.

Point-to-point encryption is a more absolute mechanism, because it removes cleartext PAN from the merchant environment rather than substituting for it. The governing standard is PCI P2PE, current at time of writing at v3.2 published June 2025, supported by the P2PE Program Guide v3.2 dated July 2026. A P2PE solution encrypts account data within a PCI-approved point-of-interaction device using keys the merchant never holds, and decrypts it only within the solution provider’s or component provider’s validated environment. The merchant’s own systems carry ciphertext they cannot open.

The reporting consequence is SAQ P2PE, whose eligibility criteria as published at time of writing require that all payment processing is via a validated PCI-listed P2PE solution; that the only systems in the merchant environment storing, processing or transmitting account data are payment terminals from that solution; that the merchant does not otherwise receive, transmit or store account data electronically; that any retained account data is on paper not received electronically; and that the merchant has implemented all controls in the P2PE Instruction Manual provided by the solution provider. It applies to neither e-commerce channels nor service providers. The Council’s footnote on validity matters as much as the criteria: solutions on the PCI list with expired validations are no longer considered validated per the P2PE Program Guide, and a merchant using one should ask its acquirer whether the questionnaire is still acceptable.

Encryption solutions that are not PCI-listed are a much weaker position. The Council published Assessment Guidance for Non-listed Encryption Solutions in June 2020 for exactly this case; such solutions confer no SAQ P2PE eligibility, and any scope reduction is a matter for the acquirer’s judgement on the evidence, not an entitlement.

E-commerce scope: the SAQ A / SAQ A-EP boundary#

For card-not-present channels the decisive question is where each element of the payment page originates. SAQ A is for card-not-present merchants — e-commerce or mail and telephone order — that completely outsource all account data functions to PCI DSS validated and compliant third parties, with no electronic storage, processing or transmission of account data on their systems or premises, and any retained account data on paper not received electronically. SAQ A-EP is for e-commerce merchants that partially outsource, with a website that does not itself receive account data but does affect the security of the transaction or the integrity of the page accepting the customer’s account data.

The Council’s own mapping, in the questionnaire guidance revision of April 2025 and accurate at time of writing:

The Council’s rule of thumb is blunt: if any element of a payment page delivered to consumers’ browsers originates from the merchant’s own website, SAQ A does not apply.

The complete questionnaire set at time of writing is SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, SAQ P2PE, SAQ SPoC and SAQ D, the last in separate merchant and service provider forms. The card-present ones divide by connectivity: SAQ B for imprint machines or standalone dial-out terminals with no internet connection, SAQ B-IP for standalone PCI-listed approved PTS point-of-interaction devices with an IP connection to the processor and isolated from all other system types, SAQ C-VT for manual entry into a validated third-party virtual terminal from an isolated device, SAQ C for payment application systems connected to the internet at a single location, and SAQ SPoC for merchants using a commercial off-the-shelf mobile device with a secure card reader from the Council’s list of validated SPoC solutions.

The SAQ A revision of January 2025#

This episode is the clearest illustration of how the standard and the reporting tools can diverge, and it is dated precisely.

PCI DSS v4.x introduced two requirements aimed squarely at e-commerce script attacks — the pattern in which an attacker modifies or adds a script that a checkout page loads into the customer’s browser, so that card details are copied as they are typed, before any of the merchant’s own encryption applies. The merchant’s servers are never touched and its logs show nothing wrong, which is precisely why the controls exist. Requirement 6.4.3 as published requires that all payment page scripts loaded and executed in the consumer’s browser are managed so that a method confirms each script is authorised, a method assures the integrity of each script, and an inventory of all scripts is maintained with written business or technical justification for each. Requirement 11.6.1 as published requires a change- and tamper-detection mechanism to alert personnel to unauthorised modification — including indicators of compromise, changes, additions and deletions — to the security-impacting HTTP headers and script contents of payment pages as received by the consumer browser, evaluated at least weekly or at a frequency set by the entity’s targeted risk analysis under Requirement 12.3.1.

On 30 January 2025 the Council announced that, in response to stakeholder feedback about the complexity of implementing these controls, Requirements 6.4.3 and 11.6.1 were being removed from SAQ A, along with Requirement 12.3.1 in so far as it supported 11.6.1. In their place SAQ A gained an eligibility criterion requiring the merchant to confirm that its site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce systems. Two versions of SAQ A were live at once for a period: the October 2024 version was retired on 31 March 2025, and the January 2025 version took effect the same day, which was also the day the future-dated requirements became effective. Requirements 6.4.3, 11.6.1 and 12.3.1 themselves became effective on 31 March 2025 and remain in the standard, continuing to apply to merchants reporting on SAQ D and to merchants assessed on-site with a Report on Compliance. All those dates are as published and accurate at time of writing.

Read the substitution carefully: the reporting burden moved, not the security problem. A merchant attesting to the new eligibility criterion has asserted something about its own susceptibility to script attacks with no prescribed method of verifying it.

The version in force, and the migration position, dated#

As at the time of writing, August 2026, the position is as follows, and every element of it is dated. PCI DSS v4.0 was published in March 2022. PCI DSS v3.2.1 was retired on 31 March 2024. PCI DSS v4.0.1, a limited revision containing corrections and clarifications and, in the Council’s words, no additional or deleted requirements, was published in June 2024. PCI DSS v4.0 was retired on 31 December 2024, after which v4.0.1 became the only active version supported by the Council, and the Council’s document library still lists it as the current standard at time of writing.

Version 4.x introduced 64 new requirements, of which 51 were future-dated. Future-dated requirements are treated as best practice until the specified date and are not validated before it; once reached, they become effective and applicable. That date was 31 March 2025, it was not changed by the v4.0.1 revision, and it has passed. There is therefore no remaining phase-in: at the time of writing every requirement of PCI DSS v4.0.1 is fully in force. The requirements below carried the “best practice until 31 March 2025” designation and are now effective; the wording is as published in v4.0.1 and accurate at time of writing.

Others in the same set cover encryption of SAD held before authorisation completes, keyed hashing of the full PAN, software and component inventories, targeted-risk-analysis frequencies for malware scanning and log review, management of lower-ranked vulnerabilities, awareness training on acceptable use of end-user technologies, and multi-tenant support for customer penetration testing.

The forward-looking position, also dated, is that the Council has begun the next iteration. From 3 June to 20 July 2026 it ran a six-week Request for Comments on the currently published v4.0.1, expressly to gather feedback shaping the standard’s evolution and specifically inviting comment on opportunities supporting future technology and artificial intelligence innovation. As at the time of writing no successor version has been published and no publication date has been announced. Anything predicting the content or timing of a next version is speculation; the Council’s pattern with v4.0 was a multi-year development cycle, then a transition period with two versions simultaneously active, then a separate phase-in for future-dated requirements, but it has not committed to repeating that shape.

The relatives#

PCI DSS is one member of a family; the others govern devices, keys, software, mobile acceptance, card manufacture and authentication. The versions below are those current in the Council’s document library at time of writing.

Three sunsets are in progress at time of writing, and they matter because they change what a supplier can validly claim. The Council announced a formal sunset period of 1 May to 31 October 2026 for the PCI 3DS Software Development Kit Standard, and the same window for both the Software-based PIN Entry on COTS and the Contactless Payments on COTS Standards, the latter two superseded in substance by MPoC. The Payment Application Data Security Standard was retired earlier, on 28 October 2022, superseded by the Secure Software and Secure Software Lifecycle Standards; a vendor still advertising PA-DSS validation is advertising something that has not existed for years.

Two of these deserve a paragraph rather than a table row.

PCI PTS POI makes P2PE and PIN entry possible at all, because it defines what a trustworthy card reader is. Approved devices are evaluated against physical and logical requirements including tamper responsiveness: the device is built so that interference with its enclosure or internal signals causes it to erase its cryptographic keys and stop working, which is why the correct response to a suspected-tampered terminal is to take it out of service rather than open it up. This is also why PCI DSS Requirement 9.5.1 exists — periodic inspection of POI devices for tampering and unauthorised substitution — and why Requirement 9.5.1.2.1 lets the entity set inspection frequency and type by targeted risk analysis rather than imposing one interval. Approvals expire; a lapsed device does not stop working but does stop counting for eligibility purposes.

PCI PIN is a separate compliance regime with its own assessor qualification, the Qualified PIN Assessor, whose Qualification Requirements stood at v1.2 in March 2025 and Program Guide at v1.2 in May 2025, with the PIN Attestation of Compliance template at v3.3 dated February 2026 — all as published at time of writing. One wrinkle trips people up: Visa announced the sunset of its own PIN Security compliance programme effective 1 October 2023, while stating that clients, processors and service providers would still be required to comply with PCI PIN security requirements. The programme that collected the paperwork went away; the obligation did not.

What certification does and does not prove#

There is no PCI DSS certificate. There are two reporting outputs and one attestation form that accompanies either. A Report on Compliance is the long form, produced against the Council’s ROC Template — at time of writing v4.0.1 revision 3 dated January 2025, and mandatory for QSAs documenting any assessment as a ROC — recording the entity’s environment, the samples the assessor selected, and how each requirement was assessed. A Self-Assessment Questionnaire is the short form, available only where the entity meets the eligibility criteria in that questionnaire and its compliance-accepting entity permits it. Either way, the Attestation of Compliance is the covering declaration: a statement of the assessment’s results, signed by the assessed entity and, where one was involved, the QSA company.

What an AOC proves is narrow, and the narrowness is the point. It proves that on a stated date, against a stated version of the standard, for a stated scope, on a stated sample, an assessor or the entity itself concluded the applicable requirements were met. Change any one of those variables and the document tells you nothing. The commonest failure in third-party due diligence is not reading the scope section: an AOC covering a supplier’s hosting platform in one region does not cover the product you are buying, and one covering “the tokenisation service” does not cover the support tooling your account managers will actually use.

It does not prove the entity is compliant now, because the obligation is continuous and the document is not. Nor does it prove every requirement was met by the defined method. Requirements may be met by the defined approach, by a compensating control documented on a worksheet, or by the customised approach, in which the entity designs its own control to meet a stated Customized Approach Objective and the assessor writes bespoke testing procedures for it. The Council’s guidance for compensating controls and the customised approach, most recently revised in June 2026 at time of writing, exists because these are the two mechanisms through which an assessment can pass while looking nothing like the standard’s text. Neither is illegitimate; both require you to read further before relying on the attestation.

It also does not discharge your own third-party risk, and PCI DSS pushes that back onto you explicitly. Requirement 12.8.4 requires a programme to monitor third-party service providers’ compliance status at least once every 12 months, and Requirement 12.9.2 requires TPSPs to support their customers’ requests for information to meet 12.8.4 and 12.8.5 by providing compliance status information and stating which requirements are whose responsibility. The Council also notes that a service provider holding an AOC is expected to provide it to customers on request. If a supplier will not hand over an AOC and a responsibility matrix, that refusal is itself the finding — and two scheme-published registries give an independent cross-check, the Visa Global Registry of Service Providers and the Mastercard SDP Compliant Registered Service Provider List.

Finally, there is the programme nobody wants to meet. The PCI Forensic Investigator programme qualifies firms and individuals, who must already be QSAs, to investigate actual or suspected compromises affecting card transactions or cardholder data, under a single set of qualification requirements accepted across the participating brands rather than the brand-by-brand arrangements that preceded it. A PFI investigation is where the attestation and the reality are compared in writing by someone paid to find the difference, and Visa’s waiver language quoted earlier is why that matters: the forensic report decides whether there was evidence of non-compliance before and at the time of the breach.

Where PCI stops and the law starts#

PCI DSS is contract. Data protection is statute, and the two run on separate rails to separate destinations.

In the United Kingdom, a card number combined with anything identifying a person is personal data, and losing it engages the UK GDPR and the Data Protection Act 2018 regardless of PCI DSS status. The Information Commissioner’s Office can impose fines up to the higher maximum of £17.5 million or four per cent of the undertaking’s total annual worldwide turnover in the preceding financial year, whichever is higher — the figures in force at time of writing. A valid AOC is evidence of care that may bear on the ICO’s assessment; it is not a defence, and the ICO is not bound by the schemes’ conclusions or vice versa. An organisation can be compliant with PCI DSS and in breach of data protection law, or the reverse.

The boundary also runs the other way. Bank-transfer and direct debit data — sort code and account number, mandate references, payer details — is not account data as PCI DSS defines it, because the PAN is the defining factor for cardholder data and there is no PAN. Handling UK Direct Debit therefore does not create a cardholder data environment; the obligations that do apply come from the Bacs scheme rules operated by Pay.UK and from the sponsoring bank, separate instruments with separate accreditation routes. Treating one regime as evidence for the other is a category error that turns up regularly in supplier questionnaires.

Strong customer authentication is a third rail again. PCI 3DS Core governs the security of environments where specified 3-D Secure functions are performed; it does not mandate the use of 3-D Secure, and says nothing about when authentication is legally required or what exemptions apply. Three separate documents therefore govern the same checkout page: PCI DSS for the confidentiality of the card number, PCI 3DS Core for the security of the authentication infrastructure where it is in scope, and financial regulation for whether the customer must be authenticated at all.

The final observation is the one to take into a negotiation. PCI DSS is unusually explicit about the limits of its own authority. The Council states that it does not define compliance requirements for any organisation and does not set compliance validation responsibilities; that those are set by brands, acquirers and payment facilitators; and that organisations with questions must consult their compliance-accepting entity — a clarification it repeated as recently as its bulletin of 4 August 2026. When someone tells you PCI DSS requires a particular outcome for your business, the accurate response is that PCI DSS says what it says, and your acquirer decides what you must prove. Those are two different conversations, and only one can be settled by reading the standard.

48.98 Common wrong ideas#

Wrong: We are PCI certified. Right: Nothing in PCI DSS produces a certificate; what it produces is an Attestation of Compliance covering one scope on one date against one version, which is a photograph rather than a passport.

Wrong: Last year’s attestation means we are compliant. Right: Compliance is a continuous obligation, which is why service providers must review quarterly that staff are performing the documented tasks and reconfirm their scope at least every six months.

Wrong: The PCI Security Standards Council fined us, and there is a published tariff of per-card penalties. Right: The Council sets no compliance requirements and levies nothing, the schemes assess the acquirer who then recovers under contract, Visa’s rules forbid the acquirer from representing that Visa imposed the assessment, and nobody publishes a penalty schedule, so a precise figure is marketing, a leaked contract or an invention.

Wrong: Buying a tokenisation or point-to-point encryption product takes us out of the standard. Right: It reduces scope conditionally, and eligibility for the short questionnaire is lost by an expired listing, by receiving account data through any other route, or by not implementing every control in the P2PE Instruction Manual.

Wrong: Tokens are harmless, so the whole token estate is out of scope. Right: If the entity holding tokens can retrieve the account number, the retrieval path is in scope, and the vault performing the mapping is in scope for whoever operates it.

Wrong: We choose which questionnaire we complete. Right: The Council writes the questionnaires but the compliance-accepting entity decides who may use which, a point it restated by revising FAQ 1331 on 4 August 2026.

Wrong: PCI DSS makes us safe from card fraud. Right: The standard concerns the confidentiality of stored and transmitted account data; it will not tell you whether the person holding the card is the cardholder, does not govern chargebacks and does not deliver strong customer authentication.

Wrong: Removing 6.4.3 and 11.6.1 from SAQ A removed the script-attack problem. Right: The reporting burden moved and the requirements remain in the standard for merchants on SAQ D and on-site assessment, while SAQ A merchants now assert their own non-susceptibility with no prescribed method of verifying it.

Wrong: Visa’s Technology Innovation Programme, or being a Mastercard Level 4 merchant, means we need not comply. Right: Both remove the obligation to validate, not the obligation to comply, and Mastercard still requires the acquirer to run a risk management programme over those portfolios.

Wrong: A supplier’s Attestation of Compliance discharges our third-party risk. Right: Requirement 12.8.4 obliges you to monitor supplier compliance status at least annually and 12.9.2 obliges the supplier to tell you which requirements are whose, and the commonest due-diligence failure is not reading the scope section.

48.99 Chapter summary in 20 lines#

1. A card number is a key with the address stamped on it, and the person who loses it is not the person who gets burgled or pays for the locks, which is the gap the whole chapter addresses.
2. Six card companies wrote six overlapping rulebooks until 2006, when they founded the PCI Security Standards Council to maintain one.
3. The Council develops the standards and runs the qualification and listing programmes, and each payment brand separately runs its own enforcement, validation and penalty programme.
4. The standard is therefore not legislation anywhere; it reaches a business through a chain of private contracts and its ultimate sanction is the loss of card acceptance.
5. Validation level follows transaction volume, and the two largest schemes’ criteria do not agree, so a merchant can be Level 2 under one and Level 1 under another.
6. What you must actually do follows how close the card number gets to your own systems, not how big you are.
7. On a website that difference is 27 requirements under SAQ A or 139 under SAQ A-EP, decided by whether the payment form came whole from the provider or was drawn by the merchant’s own code.
8. The Council’s rule of thumb is blunt: if any element of the payment page delivered to the browser originates from the merchant’s own website, SAQ A does not apply.
9. Point-to-point encryption removes cleartext account numbers from the merchant environment using keys the merchant never holds, and tokenisation substitutes a value only the vault can reverse.
10. Both reduce scope conditionally, and the reduction is something you maintain rather than something you buy.
11. Scope covers account data, everything with unrestricted connectivity to it, and everything that could impact its security, which is the category that pulls in identity, logging and remote-access infrastructure.
12. Segmentation removes a component only where it could not impact the cardholder data environment even if compromised, and the segmentation controls must be penetration tested annually, or six-monthly for service providers.
13. The storage rules are unforgiving: sensitive authentication data must not survive authorisation even encrypted, the account number must be rendered unreadable at rest, and display is limited to the leading digits and the last four.
14. Requirements 6.4.3 and 11.6.1 exist for script attacks that copy card details in the shopper’s browser, where the merchant’s servers are untouched and its logs show nothing wrong.
15. On 30 January 2025 the Council removed both from SAQ A in favour of a self-asserted eligibility criterion, which moved the reporting burden and not the security problem.
16. As at August 2026, v4.0.1 is the only active version, all 51 future-dated requirements became effective on 31 March 2025, and the Council ran a Request for Comments on the successor from 3 June to 20 July 2026.
17. There is no certificate: there is a Report on Compliance or a Self-Assessment Questionnaire, and an Attestation of Compliance covering one date, one version, one scope and one sample.
18. A requirement may have been met by the defined approach, by a compensating control or by the customised approach, so the attestation alone does not tell you what the control actually is.
19. PCI DSS is one of a family covering devices, hardware security modules, PINs, encryption solutions, 3-D Secure, mobile acceptance, software and card production, with sunsets in progress that change what a supplier may validly claim.
20. PCI DSS is contract and data protection is statute, running on separate rails to separate destinations: the Information Commissioner’s Office can fine up to £17.5 million or four per cent of worldwide turnover, an attestation is evidence of care rather than a defence, and your acquirer decides what you must prove.

Sources: PCI SSC document library, standards and blog, including PCI DSS v4.0.1, the v4.x Quick Reference Guide and Prioritized Approach, the SAQ Instructions and Guidelines v4.0.1 r1, and the FAQ 1331 bulletin of 4 August 2026; Visa Account Information Security and the Visa Core Rules; Mastercard Site Data Protection; ICO data protection fining guidance. All verified as published in August 2026.