PCI DSS and ISO 27001 answer different questions. PCI DSS, the Payment Card Industry Data Security Standard, is a set of technical and operational requirements for protecting payment card data, written by the PCI Security Standards Council and enforced not by the Council or by any government but by the payment brands and the acquirers that contract with you. It applies to anyone who stores, processes or transmits card data, and it is proven with a Report on Compliance or a Self-Assessment Questionnaire plus an Attestation of Compliance, not a certificate. ISO/IEC 27001 is a management system standard: you set the scope, assess your own risks, choose controls, and a certification body certifies the system. The Council's own answer is that there is "no direct correlation" between PCI DSS and the ISO controls, that ISO work "is a good start", and that it has no document mapping one onto the other. Neither replaces the other.
This guide compares the two from the primary texts, shows where one piece of evidence can serve both, and ends with a table to fill in. If you are still working out whether PCI DSS applies to you, start with who must comply and which SAQ applies.
| PCI DSS | ISO 27001 | |
|---|---|---|
| Written by | The PCI Security Standards Council; current version v4.0.1, June 2024 | ISO and IEC; current edition ISO/IEC 27001:2022 |
| Applies to | Entities that store, process or transmit cardholder data or sensitive authentication data, or could impact the security of the cardholder data environment | Any organisation that adopts it |
| Enforced by | Payment brands and acquirers, through their contracts | Nobody; certification is chosen |
| Scope | Wherever account data goes, confirmed at least every 12 months, requirement 12.5.2 | Set by the organisation, clause 4.3 |
| Style | Prescriptive: fixed lengths, frequencies and test types | Risk based: controls selected in a Statement of Applicability |
| Proof | Report on Compliance or SAQ, with an Attestation of Compliance | A certificate from a certification body |
| Cycle | Validation as often as the brands and your acquirer require | Three year cycle, surveillance audits in years one and two |
What is the difference between PCI DSS and ISO 27001?
Who it protects and who holds you to it. The PCI Security Standards Council describes PCI DSS as applying to "Entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE)." It is about one kind of data. Its twelve requirements sit under six goals, from building and maintaining a secure network and systems to maintaining an information security policy, and v4.0.1, published in June 2024, replaced v4.0, which the Council retired on 31 December 2024 with "no new or deleted requirements".
PCI DSS is not law, and the Council does not police it. In FAQ 1212 the Council says: "we do not enforce compliance or define validation reporting requirements. Compliance validation programs are maintained by the individual payment brands". Its role summary adds that "determination of any non-compliance penalties are carried out by the individual payment brands and not by the PCI SSC." The obligation reaches you through your acquirer or your customer contract, wherever in the world you take cards.
ISO/IEC 27001 is about the system, not the data. Clause 4.3 of the standard says "The organization shall determine the boundaries and applicability of the information security management system to establish its scope", and clause 6.1.3 d) requires a Statement of Applicability listing "the necessary controls", "whether the necessary controls are implemented or not" and "the justification for excluding any of the Annex A controls". You decide what the controls are; the standard decides how you decide.
Does ISO 27001 certification make you PCI DSS compliant?
No. In FAQ 1131 the Council says: "There is no direct correlation between PCI DSS and ISO 27002. The ISO standards provide a framework for implementing an information security program while PCI DSS provides a baseline of technical and operational requirements for the protection of payment card data. Work performed to implement an ISO standard is a good start to becoming PCI DSS compliant, and can provide input and support for PCI DSS compliance efforts. The PCI Security Standards Council does not have a document that maps PCI DSS to other standards." ISO/IEC 27002 is the guidance behind the Annex A controls of ISO 27001.
The reverse holds too. PCI DSS has no certificate to give. In FAQ 1220 the Council lists the official outputs as "template versions of the Report on Compliance (ROC), Attestations of Compliance (AOC), Self-Assessment Questionnaires (SAQ), and Attestations of Scan Compliance for ASV scans", and says that anyone handed "certificates or documents that purport to indicate compliance" in another form should ask for the official templates. A PCI attestation tells an ISO auditor nothing about the rest of your ISMS.
How prescriptive is PCI DSS compared with ISO 27001?
Much more. ISO 27001 lets your risk assessment set the strength and frequency of a control. PCI DSS writes many of them down. The requirement wording below is from the v4.0 SAQ D for service providers, which reproduces the requirements; the Annex A titles are from the ISO/IEC 27002:2022 table of contents.
| PCI DSS requirement | What it fixes | Closest ISO 27001 Annex A control |
|---|---|---|
| 8.3.6 Passwords | A minimum length of 12 characters, or eight if the system cannot support 12, with numbers and letters | 5.17 Authentication information |
| 8.4.2 Multi-factor authentication | MFA for all access into the CDE | 8.5 Secure authentication |
| 10.4.1 Log review | Security events and logs of in-scope and critical components reviewed at least once daily | 8.15 Logging |
| 10.5.1 Log retention | At least 12 months, the most recent three months immediately available | 8.15 Logging |
| 11.3.1 and 11.3.2 Vulnerability scans | Internal and external scans at least once every three months, external ones by an Approved Scanning Vendor | 8.8 Management of technical vulnerabilities |
| 11.4.2 and 11.4.3 Penetration tests | Internal and external, at least once every 12 months and after significant change | 8.8 Management of technical vulnerabilities |
| 12.6.3 Security awareness | Training upon hire and at least once every 12 months | 6.3 Information security awareness, education and training |
| 12.8.4 Service providers | Each provider's PCI DSS compliance status monitored at least once every 12 months | 5.19 Information security in supplier relationships |
| 3.3.1 Sensitive authentication data | Not retained after authorization, even if encrypted | No equivalent; ISO 27001 does not name card data |
Read the right hand column as where the evidence lives in an ISMS, not as proof of the left. An ISO control that meets your own risk appetite with ten character passwords or six monthly scans is conforming to ISO 27001 and failing PCI DSS.

PCI DSS v4.0 did add one risk based route. The customized approach "is an alternative to the defined approach and focuses on a PCI DSS requirement's stated Customized Approach Objective", supported by a targeted risk analysis under requirement 12.3.2. It is the closest PCI DSS comes to the ISO way of working, and it has limits: the SAQ notes that "Use of the Customized Approach is not supported in SAQs."
How does scope differ?
ISO 27001 scope is a decision; PCI DSS scope is a finding. Under requirement 12.5.2, "PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment"; requirement 12.5.2.1 makes that every six months for service providers. The scope is wherever account data goes and whatever could affect it. An ISO certificate scoped to your product platform may leave the call centre that takes card payments by phone outside the audit. PCI DSS will not.

How is each one proven?
PCI DSS by the route your card brands and acquirer set. Depending on your merchant or service provider level, that is a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the SAQ notes that brands and acquirers decide "whether an entity is required to use a QSA, or may use an ISA". What drives the cost of each route is in our guide to PCI DSS compliance cost.
ISO 27001 by certification. ISO states that it "doesn't provide certification or conformity assessment"; certification bodies do. ISO also notes that "accreditation is not compulsory", so check whether yours is accredited before you rely on its certificate. Under ISO/IEC 17021-1 clause 9.1.3.2, as IAS reproduces it, the cycle is a "two-stage initial audit, surveillance audits in the first and second years following the certification decision, and a recertification audit in the third year". The ISO side is covered in what to expect in an ISO 27001 audit.
What the other results get wrong
Page one is mostly compliance vendors and consultancies, and four errors turn up. Older pages still ranking describe ISO 27001 Annex A as 114 controls, the count in the 2013 edition; ISO/IEC 27001:2022 has 93. One puts the overlap at "roughly 40%" of controls, with no method, though the Council says it has no mapping document to measure against. One says organisations "must undergo an annual assessment by a Qualified Security Assessor"; under FAQ 1212 the brands set the validation programme, and many entities validate with an SAQ. And at least one still quotes the v3.2.1 firewall wording for requirement 1, which v4.0 renamed "Install and Maintain Network Security Controls".
Should you do PCI DSS or ISO 27001 first?
If you take or handle cards, PCI DSS is not optional: your acquirer or customer contract already requires it. ISO 27001 is the choice. If you run both, run them on one control set. Confirm your validation level with your acquirer, map where account data flows, bring that cardholder data environment into your ISMS scope, and set each shared control to the stricter of the two numbers. Then the PCI evidence is ISMS evidence, and the ISO internal audit can test the PCI controls in the same pass. The same reasoning for two other regimes is in ISO 27001 vs DORA.
Check your own programme
Fill in the middle column. A blank row is a question your QSA or your certification auditor will ask.
| Question | Your answer | Why it matters |
|---|---|---|
| Which validation level has your acquirer assigned you, in writing? | Brands and acquirers set the route, FAQ 1212. | |
| Does your ISMS scope include every system that touches account data? | Clause 4.3 against requirement 12.5.2. | |
| When was PCI DSS scope last confirmed? | Every 12 months, six for service providers. | |
| Do password and MFA settings meet 8.3.6 and 8.4.2, not just your ISO policy? | PCI DSS fixes the number. | |
| Who runs your quarterly external scans, and are they a listed ASV? | Requirement 11.3.2. | |
| Do you hold a current AOC from every service provider that touches account data? | Requirement 12.8.4. | |
| Does your Statement of Applicability reference the PCI DSS requirements? | One control set, two sets of evidence. |
If most rows are blank, the free compliance check gives you a baseline. Venvera's PCI DSS module and ISO 27001 module share one control library, so an access review, scan report or training record collected once is linked to the PCI DSS requirement and the Annex A control it serves.
Frequently asked questions
Is PCI DSS a law?
No. It is an industry standard. The PCI SSC says it does not enforce compliance; the payment brands run the validation programmes and set any penalties, and acquirers pass the obligation on by contract.
Can an ISO 27001 certificate replace a PCI DSS assessment?
No. The Council's FAQ 1131 says there is no direct correlation, calls ISO work "a good start", and says the Council has no document mapping PCI DSS to other standards.
Is there a PCI DSS certificate?
No. The official outputs are the Report on Compliance, the Self-Assessment Questionnaire, the Attestation of Compliance and ASV scan attestations. FAQ 1220 tells anyone shown a certificate to ask for those instead.
How many controls does PCI DSS have?
The Council publishes twelve principal requirements under six goals and does not publish a control count. Be wary of any total quoted for it.
Which one should a payment service provider do?
PCI DSS if it stores, processes or transmits card data or could affect its security, because the brands require it. ISO 27001 if customers or regulators ask for a certified management system. Running both on one control set costs less than running them apart.
Primary sources
Applicability is quoted from the PCI SSC PCI DSS page; enforcement from FAQ 1212 and the role of the PCI SSC; the ISO relationship from FAQ 1131; validation documents from FAQ 1220; the version change from the v4.0.1 announcement; the customized approach from the PCI SSC blog. Requirement wording is from the v4.0 SAQ D for service providers; v4.0.1 added or deleted no requirements. ISO/IEC 27001:2022 clauses 4.3 and 6.1.3 are from the published preview and Annex A titles from the ISO/IEC 27002:2022 preview; certification from ISO's help centre and ISO's certification page; the audit cycle from ISO/IEC 17021-1 clause 9.1.3.2 as reproduced by IAS. Your acquirer's requirements take precedence over any general guide.





