Danielle Osei had been CISO at Larkspur Outfitters for eleven weeks when the board meeting happened. Larkspur — a $180 million-a-year direct-to-consumer apparel retailer with a growing B2B wholesale marketplace — had just watched a close competitor, ThreadForge, get hit with a Magecart-style card-skimming attack. Attackers had planted JavaScript on ThreadForge's checkout page for four months, quietly harvesting card numbers, expiry dates, and CVVs from roughly 340,000 transactions. The fallout: $2.1 million in card brand fines and assessments, $890,000 in forensic investigation and legal fees, a 90-day suspension of card-processing privileges from their acquiring bank, and an estimated $3.3 million in lost revenue during the shutdown. Total damage: north of $6.3 million, plus a reputational hit that Larkspur's own board could see playing out in ThreadForge's stock price.
The board's question to Danielle was blunt: "Are we protected from this? Are we PCI compliant? Should we also get ISO 27001 certified?" Danielle realized, standing in front of that slide deck, that half the room believed PCI DSS and ISO 27001 were competing options — pick one — and the other half believed ISO 27001 certification would automatically cover PCI DSS. Neither was true, and the confusion was about to shape a budget decision worth several hundred thousand dollars.
This is one of the most common questions I get from clients who touch card data: do we need PCI DSS, ISO 27001, or both? The honest answer is that if you store, process, or transmit cardholder data, PCI DSS is not really optional — it is a contractual condition of accepting Visa, Mastercard, American Express, Discover, or JCB cards, enforced through your merchant agreement and acquiring bank rather than by government statute. ISO 27001, by contrast, is a voluntary, certifiable standard that most organizations pursue for broader competitive, contractual, or risk-management reasons. They are not substitutes for each other, and they are not mutually exclusive — in fact, for a meaningful slice of organizations, the smart move is to run both, with PCI DSS scoped as a rigorous subset inside a broader ISO 27001-certified information security management system (ISMS).
This article walks through what each framework actually requires, how to decide whether you need one or both, where the two overlap enough to share evidence, where they diverge in ways that will trip you up if you assume overlap, and how to structure a combined program so you're not running two disconnected compliance efforts with two disconnected budgets.
Who This Is For
This is written for CISOs, compliance directors, and founders at merchants, payment facilitators, payment processors, and SaaS platforms that touch card data in any capacity — from a small e-commerce shop using a hosted checkout page to a Level 1 service provider processing millions of transactions a year. You'll walk away with a clear framework for deciding whether PCI DSS alone is sufficient for your situation, when ISO 27001 adds real value on top of it, a control-by-control sense of where the two frameworks overlap and where they don't, and a practical model for running both without duplicating work or dollars.
What PCI DSS Actually Is
The Payment Card Industry Data Security Standard (PCI DSS) is a set of technical and operational security requirements created and maintained by the PCI Security Standards Council (PCI SSC) — a body founded in 2006 by American Express, Discover, JCB, Mastercard, and Visa. PCI DSS is not a law and not a government regulation. It is a contractual requirement: if you want to accept, store, process, or transmit payment card data, your merchant agreement with your acquiring bank (and, indirectly, your relationship with the card brands) obligates you to comply with it. Non-compliance doesn't get you arrested — it gets you fined, and in serious or repeated cases, it can get your card-processing privileges suspended or revoked entirely, which for most consumer-facing businesses is close to a death sentence. (If some of this terminology is new, our ISO 27001 glossary of terms defines AOC, ROC, QSA, and the ISO-side vocabulary used throughout this piece.)
The current version is PCI DSS v4.0.1, a maintenance release published in June 2024 that clarified and corrected the major v4.0 update from March 2022. PCI DSS v3.2.1 was formally retired at the end of March 2024, and a set of "future-dated" v4.0 requirements — new, more rigorous controls that were optional during a transition window — became mandatory as of March 31, 2025. If your organization is still validating against v3.2.1 language today, that's a compliance gap worth flagging immediately.
PCI DSS is intentionally narrow and prescriptive. It applies specifically to the Cardholder Data Environment (CDE): the people, processes, and technology that store, process, or transmit cardholder data (primary account number, cardholder name, expiration date, service code) or sensitive authentication data (full track data, CVV/CVC, PINs). Everything outside that environment is, in principle, out of scope — though in practice, poor network segmentation drags a lot of "unrelated" systems into scope anyway, which is one of the most expensive mistakes I see in PCI programs.
What ISO 27001 Actually Is
ISO/IEC 27001:2022 is an internationally recognized, certifiable standard for building and operating an information security management system (ISMS) — a structured, risk-based program for protecting all forms of information an organization holds, not just payment card data. It's published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), and organizations are certified against it by accredited, independent certification bodies following a formal audit (Stage 1 and Stage 2), with ongoing surveillance audits and a three-year recertification cycle.
Structurally, ISO 27001 has two parts. Clauses 4 through 10 define the management-system requirements: how you establish the context of your organization, secure leadership commitment, plan and treat risk, support the ISMS with resources and competence, operate it day to day, evaluate its performance, and drive continual improvement. Annex A then lists 93 specific controls across four themes — organizational (5.1–5.37), people (6.1–6.8), physical (7.1–7.14), and technological (8.1–8.34) — that you select from and justify (or exclude and justify) based on your own risk assessment, documented in a Statement of Applicability. If you're new to how that scoping and justification process works, our guide to defining the scope of your ISMS and our walkthrough of building a Statement of Applicability are good starting points.
Unlike PCI DSS, ISO 27001 doesn't hand you a fixed checklist and tell you exactly which cryptographic algorithms to use or how many days you have to patch a critical vulnerability. It's risk-based: you assess your own threats and business context, and you choose proportionate controls, subject to an external auditor agreeing that your reasoning holds up. That flexibility is a strength for organizations managing diverse information assets across a whole business — and a weakness if what you actually need is a narrow, unambiguous bar for protecting sixteen-digit numbers on a card.
That is really the crux of the "PCI vs. ISO" question, and it's worth putting side by side before going further.
PCI DSS vs. ISO 27001: The Snapshot Comparison
Dimension | PCI DSS v4.0.1 | ISO/IEC 27001:2022 |
|---|---|---|
Governing body | PCI Security Standards Council (founded by card brands) | International Organization for Standardization (ISO) / IEC |
Nature | Contractual requirement enforced via acquiring banks and card brands | Voluntary, certifiable international standard |
Legal status | Not a law — a private industry mandate | Not a law — a voluntary management-system standard |
Scope | Cardholder Data Environment (CDE) only | Entire ISMS scope as defined by the organization (can be whole-company or bounded) |
Structure | 12 requirements across 6 control goals | Clauses 4–10 (management system) + 93 Annex A controls across 4 themes |
Approach | Prescriptive — specific, often numeric requirements | Risk-based — organization selects proportionate controls |
Validation | Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC) via a QSA | Stage 1 + Stage 2 certification audit by an accredited certification body |
Outcome | Attestation of Compliance (AOC), not a public "certificate" | ISO 27001 certificate, valid 3 years with annual surveillance audits |
Renewal cycle | Annual (revalidation required every 12 months) | 3-year certification cycle with annual surveillance audits |
Covers | Only cardholder data and the systems touching it | All information assets: financial, HR, IP, customer data, card data, and more |
Who enforces it | Acquiring banks, card brands, payment processors | Certification body (accredited under ISO/IEC 17021-1) |
That table alone answers the most common misconception I run into: people assume PCI DSS and ISO 27001 sit on the same axis, as if choosing one excuses you from the other. They don't. PCI DSS is a narrow, deep, mandatory floor for one specific category of data. ISO 27001 is a broad, risk-calibrated, voluntary ceiling for your whole information estate. A useful comparison of how ISO 27001 sits relative to other frameworks generally — including PCI DSS, SOC 2, and NIST — is in our piece on ISO 27001 vs. NIST, SOC 2, and PCI DSS.
Mandated vs. Voluntary: Why the Distinction Matters More Than It Sounds
I've sat across the table from finance executives who ask, "If we get ISO 27001 certified, can we drop PCI DSS?" The answer is no, and it's worth being precise about why. PCI DSS compliance isn't something a certification body grants you after an audit — it's an ongoing contractual obligation baked into your merchant agreement with your acquiring bank. Stop complying, and you're in breach of that contract regardless of what other certificates hang on your wall. Card brands and acquirers don't recognize ISO 27001 as a substitute for PCI DSS validation, full stop.
The inverse is just as important: PCI DSS compliance does not make you ISO 27001 certified, and it doesn't even get you meaningfully far down that road on its own. PCI DSS says nothing about management review meetings, internal audit programs, risk treatment plans, or dozens of the Annex A controls covering areas like supplier relationship security, HR security, or business continuity planning outside the CDE. A PCI Attestation of Compliance (AOC) is a compliance artifact for one narrow domain; an ISO 27001 certificate is a statement about your entire information security management system, verified by an independent accredited body.
Where this distinction actually matters commercially: enterprise customers, especially in regulated industries, increasingly ask for ISO 27001 certification as a vendor-onboarding requirement — it signals a mature, audited security program across your whole business, not just the part that touches card numbers. PCI DSS, meanwhile, is what your acquiring bank and the card brands require, full stop, if you want to keep taking cards. You can be PCI compliant and lose enterprise deals for lack of ISO 27001. You can be ISO 27001 certified and still lose your ability to process cards if you let PCI validation lapse. They answer different questions for different audiences.
Scope: Cardholder Data Environment vs. Whole-Organization ISMS
Scope is where the two frameworks diverge most concretely, and it's the single biggest source of wasted effort when organizations try to run both without thinking it through.
PCI DSS scope is defined narrowly: the Cardholder Data Environment, plus any systems that could impact the security of the CDE even if they don't directly touch card data (a jump box that has network access into the CDE, for instance, is in scope even if it never stores a card number). Good network segmentation is the primary lever for keeping PCI scope small — segment the CDE away from the rest of your network with properly configured firewalls and access controls, and the systems outside that segment fall out of PCI scope entirely. Our detailed guide to network security controls under ISO 27001 8.20–8.23 covers the segmentation and network-security principles that do double duty here.
ISO 27001 scope, by contrast, is something the organization defines for itself as part of establishing the ISMS — it can be the whole company, a single business unit, a specific product line, or a defined set of locations and services, but whatever you choose, it covers all information assets within that boundary, not just payment card data. Most organizations that pursue both frameworks end up defining their ISO 27001 ISMS scope broadly enough to contain their PCI CDE as a subset, rather than running two entirely separate scoping exercises. That containment relationship is the visual worth internalizing:
flowchart TB
subgraph ISMS["ISO 27001 ISMS Scope — All Information Assets in Scope"]
direction TB
subgraph CDE["PCI DSS Scope — Cardholder Data Environment (CDE)"]
direction TB
A["Payment Processing Application"]
B["Cardholder Data Storage / Tokenization"]
C["Point-of-Sale / E-Commerce Checkout"]
end
D["HR & Payroll Systems"]
E["Corporate Email & Collaboration"]
F["Product Engineering Systems"]
G["Physical Facilities & Data Centers"]
H["Supplier & Vendor Management"]
end
CDE -.shared controls: segmentation, crypto, logging, access control.-> ISMSThe overlap zone isn't the CDE containing the ISMS, or vice versa — it's that a well-run ISMS treats the CDE as one especially sensitive, especially well-documented pocket of a larger risk-managed environment. Segmentation controls, encryption standards, logging practices, and access control policies you build for PCI DSS can — and should — be written once and referenced from both frameworks' evidence sets, which we'll come back to in the "running them together" section.
PCI DSS's 12 Requirements Across 6 Goals
For a deeper breakdown of PCI DSS's twelve core requirements, our PCI DSS pillar coverage goes requirement-by-requirement. Here's the goal-level structure that matters for this comparison. PCI DSS v4.0.1 organizes its requirements into six broad goals, each containing one or more of the 12 numbered requirements:
Goal | Requirement # | Requirement Focus |
|---|---|---|
Build and Maintain a Secure Network and Systems | 1 | Install and maintain network security controls |
Build and Maintain a Secure Network and Systems | 2 | Apply secure configurations to all system components |
Protect Account Data | 3 | Protect stored account data |
Protect Account Data | 4 | Protect cardholder data with strong cryptography during transmission over open, public networks |
Maintain a Vulnerability Management Program | 5 | Protect all systems and networks from malicious software |
Maintain a Vulnerability Management Program | 6 | Develop and maintain secure systems and software |
Implement Strong Access Control Measures | 7 | Restrict access to system components and cardholder data by business need to know |
Implement Strong Access Control Measures | 8 | Identify users and authenticate access to system components |
Implement Strong Access Control Measures | 9 | Restrict physical access to cardholder data |
Regularly Monitor and Test Networks | 10 | Log and monitor all access to system components and cardholder data |
Regularly Monitor and Test Networks | 11 | Test security of systems and networks regularly |
Maintain an Information Security Policy | 12 | Support information security with organizational policies and programs |
Each requirement breaks down further into dozens of specific sub-requirements with defined testing procedures — PCI DSS v4.0.1 runs to well over 300 individual sub-requirements once you account for all the testing procedures a QSA has to validate. That granularity is a deliberate design choice: the Council wants a QSA in Toronto and a QSA in Singapore to reach the same conclusion about whether a given control is in place, which is much harder to guarantee under a purely risk-based standard.
How PCI Compliance Is Validated: SAQs, ROCs, and QSAs
Not every organization validates PCI DSS the same way — see our full walkthrough of PCI DSS merchant levels and validation requirements for validation-path specifics beyond what's summarized here. Validation path depends primarily on transaction volume and role (merchant vs. service provider), and the card brands — Visa, Mastercard, American Express, Discover, JCB — each maintain their own merchant-level thresholds, though they're broadly aligned. The figures below reflect commonly cited Visa/Mastercard merchant-level thresholds; always confirm current thresholds with your acquirer, since brands adjust them periodically.
Merchant Level | Approximate Annual Transaction Volume | Typical Validation Path |
|---|---|---|
Level 1 | Over 6 million transactions annually (any channel), or any merchant a brand designates as Level 1 | Annual Report on Compliance (ROC) by a QSA, quarterly network scans by an ASV |
Level 2 | 1 million to 6 million transactions annually | Annual SAQ (or ROC by QSA in some brand programs), quarterly ASV scans |
Level 3 | 20,000 to 1 million e-commerce transactions annually | Annual SAQ, quarterly ASV scans |
Level 4 | Fewer than 20,000 e-commerce transactions, or up to 1 million transactions in other channels | Annual SAQ per acquirer requirements, quarterly ASV scans as applicable |
Service providers follow a parallel but stricter framework — most card brands require any service provider storing, processing, or transmitting cardholder data on behalf of others above a lower volume threshold to validate via ROC rather than SAQ, precisely because a breach at a service provider tends to cascade across many downstream merchants at once.
The Self-Assessment Questionnaire itself isn't one document — it's a family of questionnaires, and picking the wrong one is a common early mistake:
SAQ Type | Typical Use Case | Approx. Question Count |
|---|---|---|
SAQ A | Card-not-present merchants that fully outsource payment processing to a PCI-validated third party and retain no cardholder data on their own systems | ~24 |
SAQ A-EP | E-commerce merchants that outsource payment processing but whose website affects the payment transaction (e.g., redirects, iframes with some page control) | ~150+ |
SAQ B | Merchants using only imprint machines or standalone, non-networked terminals | ~24 |
SAQ B-IP | Merchants using standalone, PTS-approved payment terminals with an IP connection | ~80+ |
SAQ C | Merchants with payment application systems connected to the internet, no electronic cardholder data storage | ~150+ |
SAQ C-VT | Merchants using only web-based virtual terminals, no electronic cardholder data storage | ~70+ |
SAQ D (Merchant) | All other merchants not covered above, including those storing cardholder data | ~330+ |
SAQ D (Service Provider) | Service providers eligible to self-assess rather than undergo a full ROC | ~350+ |
For Level 1 merchants and most service providers above the SAQ threshold, self-assessment isn't available — a Qualified Security Assessor (QSA), an individual certified by the PCI SSC and employed by a QSA company, conducts an on-site or remote assessment and produces the formal Report on Compliance.
Do You Need Both? The Decision Matrix
This is the question that actually matters for budget conversations. Here's how I walk clients through it:
Your Situation | PCI DSS Needed? | ISO 27001 Needed? | Recommended Path |
|---|---|---|---|
You accept cards in any form (in-store, online, phone) | Yes — always, if you touch card data | Optional | PCI DSS is non-negotiable; evaluate ISO 27001 based on customer/market demand |
You're a payment processor, gateway, or PSP | Yes — as a service provider, usually via ROC | Strongly recommended | Both — enterprise merchants and banks will expect ISO 27001 or SOC 2 on top of PCI |
You fully outsource checkout to a PCI-validated third party (e.g., Stripe Checkout, hosted payment page) | Yes — but a lightweight SAQ A | Optional, but valuable for broader trust | PCI (light) alone may suffice; add ISO 27001 if enterprise customers ask for it |
You're a SaaS company that never touches card data directly | No | Optional | Skip PCI DSS; pursue ISO 27001 or SOC 2 based on customer demand |
You're in financial services, fintech, or banking infrastructure | Yes, if cards are involved | Strongly recommended | Both, almost always — regulators and partners expect layered assurance |
You sell to enterprise or government customers who require independent security certification | Depends on card involvement | Yes | ISO 27001 (or SOC 2) regardless of PCI status, to win the deal |
You're a small merchant using a single, non-networked card terminal | Yes — SAQ B, minimal burden | Rarely worth it at this size | PCI DSS alone; revisit ISO 27001 if you scale or add e-commerce |
You process, store, or transmit cardholder data directly on your own systems | Yes — SAQ C/D or ROC | Recommended given elevated risk | Both — the data sensitivity alone justifies broader ISMS discipline |
The short version: if you touch card data, PCI DSS isn't a decision — it's a condition of doing business with the card brands. ISO 27001 is the actual decision, and it turns on scale, customer expectations, regulatory context, and how much of your risk surface sits outside the card data environment. Organizations in regulated or high-trust sectors — see our guide on ISO 27001 for financial services — tend to need both almost by default, because the market and the regulators both expect layered assurance.
When PCI Alone Is Genuinely Enough
I don't want to oversell ISO 27001 here, because sometimes it isn't the right next move. A small e-commerce business that outsources 100% of its payment processing to a provider like Stripe or Braintree, never stores a card number, has a simple hosted-checkout integration, and has no enterprise sales motion demanding independent certification, is often well served by nailing SAQ A and putting energy elsewhere. I've seen founders burn $60,000–$90,000 pursuing ISO 27001 certification a year before they had product-market fit, when that money and attention would have been better spent hardening the actual payment integration and building a real incident response plan. If your customer base isn't asking for it, your regulator doesn't require it, and your card-data footprint is genuinely minimal, PCI DSS alone — done properly, not just checked off — is a defensible stopping point. This is where a broader read of who actually needs ISO 27001 is worth doing before committing budget.
When You Actually Need Both
The calculus flips once any of a few conditions show up: you're a service provider whose customers include banks or larger merchants who will contractually require ISO 27001 or SOC 2 as a condition of doing business; you're processing, storing, or transmitting cardholder data on your own infrastructure rather than fully outsourcing it (which usually means SAQ C/D or a ROC — a meaningfully heavier PCI lift where the marginal cost of extending discipline ISMS-wide is smaller than it looks); you operate across multiple jurisdictions or verticals where information security expectations extend well beyond card data (health records, financial account data, personally identifiable information); or your board and executive team, like Danielle's at Larkspur, have decided that a security incident anywhere in the business — not just in the CDE — is an existential risk they want independently assured against. In every one of those cases, PCI DSS validates one narrow, mandatory slice, and ISO 27001 gives you (and your customers) confidence in everything else.
Where PCI DSS and ISO 27001 Overlap
Despite being built for different purposes, PCI DSS's 12 requirements map reasonably cleanly onto a subset of ISO 27001 Annex A controls — not one-to-one, and not with identical rigor, but closely enough that a well-designed combined program can implement a control once and produce evidence for both frameworks.
PCI DSS Requirement | Related ISO 27001 Annex A Control(s) | Overlap Notes |
|---|---|---|
Req 1 – Network security controls | 8.20 Networks security, 8.22 Segregation of networks | PCI is far more prescriptive about firewall rule review cadence and documented data-flow diagrams |
Req 2 – Secure configurations | 8.9 Configuration management | ISO requires a configuration baseline exists; PCI specifies hardening standards and default-credential removal explicitly |
Req 3 – Protect stored account data | 8.10 Information deletion, 8.11 Data masking, 8.24 Use of cryptography | PCI bans storage of certain data elements (CVV) outright post-authorization; ISO has no equivalent blanket prohibition |
Req 4 – Protect data in transit | 8.24 Use of cryptography | PCI specifies minimum TLS versions and disallowed protocols; ISO leaves cryptographic strength to risk assessment |
Req 5 – Anti-malware | 8.7 Protection against malware | Close alignment; PCI adds specific update-frequency expectations |
Req 6 – Secure systems and software | 8.8 Management of technical vulnerabilities, 8.25–8.29 Secure development life cycle | PCI mandates specific patch timelines (e.g., critical vulnerabilities within a defined window); ISO requires a documented, risk-based process |
Req 7 – Restrict access by need to know | 5.15 Access control, 5.18 Access rights | Strong overlap; both require least-privilege, formally reviewed access |
Req 8 – Identify and authenticate users | 5.16 Identity management, 5.17 Authentication information, 8.5 Secure authentication | PCI mandates MFA for all CDE access under v4.0; ISO requires authentication proportionate to risk |
Req 9 – Restrict physical access | 7.1 Physical security perimeters, 7.2 Physical entry, 7.4 Physical security monitoring | Strong overlap for on-premises CDE components; less relevant for cloud-hosted CDEs |
Req 10 – Log and monitor access | 8.15 Logging, 8.16 Monitoring activities | PCI specifies exact data elements to log and 12-month retention (3 months immediately available); ISO requires logging proportionate to risk |
Req 11 – Regularly test security | 8.8 Management of technical vulnerabilities, 8.29 Security testing in development and acceptance | PCI mandates quarterly ASV scans and annual penetration testing explicitly; ISO requires testing but not on a fixed calendar |
Req 12 – Information security policy | 5.1 Policies for information security, 5.24–5.28 Incident management, 6.3 Security awareness training | Broad overlap across policy, incident response, and awareness domains |
This mapping is exactly why organizations already running one framework find the second meaningfully cheaper to bolt on than starting from zero — your logging architecture, your access review cadence, your incident response plan, and your vulnerability management process can genuinely serve both audits, provided they're documented in a way both a QSA and an ISO 27001 auditor can independently trace. For teams also weighing SOC 2 alongside these two, the crosswalk logic is similar to what we cover in running ISO 27001 and SOC 2 together and our ISO 27001, SOC 2 and NIST CSF crosswalk.
Where They Differ: Prescriptiveness
The overlap table above undersells how differently the two frameworks treat the "same" topic. PCI DSS Requirement 3, for example, doesn't just say "protect stored account data" — it prohibits storage of full track data, CVV/CVC, and PIN data after authorization, full stop, regardless of your risk appetite. There's no risk-acceptance path around that; it's an absolute prohibition, because the Council decided the risk is never acceptable for anyone. ISO 27001's equivalent controls (8.10 Information deletion, 8.11 Data masking) require you to make a risk-based decision and document your reasoning — an auditor is checking that your logic holds together, not comparing your practice against a fixed rule. That's the core philosophical difference in miniature: PCI DSS tells you the answer; ISO 27001 makes you show your work. Our guide to cryptographic controls under ISO 27001 control 8.24 covers how a risk-based cryptography policy is built — useful context for seeing exactly where PCI's fixed TLS and cipher-suite rules sit inside a broader, ISO-aligned crypto standard.
This shows up constantly in patch management. PCI DSS Requirement 6 sets explicit timelines for remediating vulnerabilities based on severity rating (critical vulnerabilities typically require remediation on a much tighter clock than lower-severity findings). ISO 27001's control 8.8 (technical vulnerability management) requires you to have a documented process and a risk-based prioritization approach — a QSA will fail you for missing PCI's specific deadline even if your ISO auditor would accept a longer, well-justified timeline for the same finding. Pull both auditors into the same room and you'll get two different verdicts on an identical patching backlog, and both would be correct under their respective standards.
Where They Differ: Scope Depth vs. Breadth
The second major axis of difference is what falls inside the fence at all. ISO 27001, once you've defined your ISMS scope, expects coverage of domains that PCI DSS never touches:
ISO 27001 Domain (Not Addressed by PCI DSS) | Why It Matters Beyond Card Data |
|---|---|
Clause 4 – Context of the organization, interested parties | Understanding the full range of stakeholder security expectations, not just card brands |
Clause 6 – Risk assessment and treatment across all assets | HR data, intellectual property, and operational data all carry risk PCI doesn't address |
5.8 Information security in project management | Ensuring security is built into all projects, not just payment features |
5.19–5.23 Supplier relationship security | Broader vendor risk management across the whole supply chain, not just payment processors |
5.29–5.30 Business continuity and ICT readiness | Whole-organization resilience planning, not just CDE availability |
6.1–6.8 People controls (screening, training, disciplinary process) | HR security lifecycle across the entire workforce |
7.1–7.14 Physical controls beyond the CDE | Office security, equipment disposal, and environmental protection company-wide |
5.34 Privacy and protection of PII | Personal data broader than cardholder data (employee, customer, applicant data) |
Clause 9 – Internal audit and management review | Formal governance and continual improvement cadence across the whole ISMS |
If your organization's risk exposure is concentrated almost entirely in the payment flow, this breadth might feel like overkill. If your risk exposure spans HR records, intellectual property, customer PII well beyond card numbers, and a sprawling vendor ecosystem — which describes most mid-market and larger organizations — this is exactly the gap PCI DSS was never designed to close.
Where They Differ: PCI-Only Depth
The relationship cuts both ways. PCI DSS goes deeper than ISO 27001 in several specific, card-data-centric areas that an ISO 27001 certificate simply won't validate:
PCI-Specific Depth (Not Guaranteed by ISO 27001) | What It Requires |
|---|---|
Prohibition on storing sensitive authentication data post-authorization | Absolute rule, not a risk-based judgment call |
Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) | Fixed cadence, specific accreditation requirement for the scanning provider |
Annual penetration testing of the CDE, including segmentation testing | Specific scope and frequency requirements ISO does not mandate |
Multi-factor authentication for all access into the CDE | Explicit, non-negotiable requirement under PCI DSS v4.0 |
Defined cardholder data retention and disposal policy with specific data elements named | Named data elements (PAN, CVV, track data) rather than a general classification scheme |
File integrity monitoring / change-detection on critical CDE files | Specific technical control PCI names explicitly |
Formal, PCI SSC-defined incident response testing tied to a suspected cardholder data compromise | Card-brand-specific escalation and notification obligations |
An ISO 27001 certificate on your wall says nothing about whether you've run a segmentation-validating penetration test in the last twelve months, or whether MFA is enforced on every path into your CDE. That's precisely why acquiring banks and the card brands will never accept an ISO 27001 certificate as a substitute for PCI validation — the standard simply wasn't built to prove those specific things.
Where They Differ: Validation Mechanics
Mechanic | PCI DSS | ISO 27001 |
|---|---|---|
Who assesses you | QSA (for ROC) or self (for SAQ), plus an ASV for external scans | Accredited certification body auditor |
Assessor accreditation | QSA companies certified by PCI SSC | Certification bodies accredited under ISO/IEC 17021-1 by a national accreditation body |
Output document | Attestation of Compliance (AOC) + ROC or SAQ | ISO 27001 certificate + audit report |
Public artifact | Not typically public; shared with acquirer/card brands on request | Certificate is a recognized, often publicly displayed credential |
Point-in-time vs. ongoing | Point-in-time validation, revalidated annually | Point-in-time certification, but surveillance audits sample the ISMS annually between recertifications |
Failure consequence | Loss of ability to process cards; fines; increased transaction fees | Loss of certification; reputational and contractual impact, but no direct payment-processing consequence |
Running Them Together: PCI Scope as a Subset of the ISMS
The most efficient combined model I've implemented with clients — including, eventually, Danielle's team at Larkspur — treats the ISO 27001 ISMS as the parent structure and the PCI DSS Cardholder Data Environment as a rigorously governed subset inside it. Practically, that means:
First, define your ISMS scope broadly enough to include the CDE, then explicitly document within your Statement of Applicability where PCI-specific requirements exceed the baseline ISO control you've selected — for example, noting against control 8.24 (Use of cryptography) that the CDE additionally follows PCI DSS's specific TLS version and cipher-suite restrictions. Second, build your control documentation once, at the higher PCI bar wherever PCI and ISO overlap, so a single access-review procedure, a single vulnerability-management SLA, and a single logging standard can satisfy both auditors without maintaining two versions of the same policy. Third, keep PCI-only controls (ASV scans, segmentation-validating penetration tests, the sensitive-authentication-data storage prohibition) clearly flagged as CDE-specific requirements that don't need to be forced onto the rest of the ISMS, where they'd be disproportionate. Fourth, run your internal audit program (an ISO 27001 Clause 9 requirement) so that it explicitly tests PCI-relevant controls on a cadence that keeps you audit-ready for both the QSA and the certification body, rather than scrambling separately for each.
Practical Scope-Reduction Tactics That Serve Both Frameworks
One lever I push clients toward early, because it pays off in both directions at once, is aggressive PCI scope reduction. The smaller and cleaner your Cardholder Data Environment, the less expensive your annual PCI validation becomes, and the cleaner your ISO 27001 Statement of Applicability gets, because you're not stretching CDE-grade controls across systems that never needed them.
Tokenization is usually the single highest-leverage move available. Replacing stored primary account numbers with tokens issued by a PCI-validated payment gateway removes the raw card data from your environment entirely for most downstream systems, shrinking the CDE down to the handful of components that actually touch the token exchange. Point-to-point encryption (P2PE) does something similar at the point of capture — a validated P2PE solution can encrypt card data at the terminal before it ever reaches your network, which, if implemented against a PCI SSC-listed P2PE solution, can qualify you for a shorter SAQ than you'd otherwise need. Network segmentation, covered earlier, remains the workhorse: a properly firewalled, access-controlled boundary around the CDE is what lets an ISO 27001 auditor accept "the CDE is a distinct risk zone within the ISMS" as a credible statement rather than a hand-wave.
The mistake I see most often here is treating scope reduction as a one-time project rather than an ongoing discipline. New integrations creep in — a marketing team connects a new analytics tool to the checkout flow, a support team gets read access to a database that happens to sit inside the CDE boundary — and scope quietly expands again without anyone updating the network diagrams or the ISMS asset inventory. Because ISO 27001's Clause 9 internal audit and PCI's annual revalidation both force a fresh look at your environment, running them on a coordinated schedule gives you two independent checkpoints a year where scope creep gets caught before it turns into an expensive surprise during an actual assessment.
Building a Combined Control Framework: Shared Controls in Practice
Control Area | Shared Implementation Approach | PCI-Specific Addition | ISO-Specific Addition |
|---|---|---|---|
Network segmentation | Documented data-flow diagrams, firewall rule reviews | Segmentation-validating penetration test annually | Risk assessment justifying segmentation boundary choices |
Encryption | TLS 1.2+ for data in transit, strong encryption at rest | Explicit ban on weak/deprecated protocols within the CDE | Cryptographic policy covering all sensitive data, not just cardholder data |
Access control | Role-based access, least privilege, periodic access reviews | MFA mandatory for all CDE access | Access reviews extend to all information assets in ISMS scope |
Logging and monitoring | Centralized logging, defined retention | Specific PCI-mandated log data elements, 12-month retention | Logging scaled to risk across the whole ISMS, not just the CDE |
Vulnerability management | Regular scanning and patch management process | Quarterly ASV scans, fixed remediation SLAs by severity | Broader technical vulnerability process covering all systems |
Incident response | Documented plan, defined roles, tested annually | Card-brand notification obligations for suspected CHD compromise | Incident learning process feeding continual improvement (Clause 10) |
Security awareness training | Annual training program, phishing simulation | PCI-specific handling procedures for staff touching card data | Broader awareness program covering all information assets |
Building it this way means a control like logging isn't implemented twice — it's implemented once, at whichever bar is higher, with clear notes in your evidence library about which requirement each element satisfies. That's the entire efficiency argument for running both frameworks together rather than as two separate compliance tracks with two separate teams.
Governance and RACI for a Combined PCI + ISO Program
Activity | PCI DSS Owner | ISO 27001 Owner | Shared/Combined Owner |
|---|---|---|---|
Scope definition | Security/compliance lead defines CDE boundary | ISMS owner defines ISMS scope | Both scopes reconciled by CISO/compliance director |
Risk assessment | Not formally required by PCI (compensating controls process exists) | Risk owner conducts formal ISO 27001 risk assessment | Combined risk register references CDE-specific risks |
Policy documentation | QSA reviews policy artifacts during ROC | Certification body auditor reviews ISMS documentation | Single policy set maintained by compliance team, mapped to both |
Vulnerability management | IT/security ops meets ASV scan and PCI patch SLAs | IT/security ops runs risk-based vulnerability process | Combined vulnerability management program with PCI SLA as the floor |
Internal audit | Not a PCI requirement itself, though evidence supports ROC | Mandatory under Clause 9 | Internal audit program samples PCI-relevant controls each cycle |
Executive review | Not formally mandated by PCI | Mandatory management review under Clause 9 | Combined quarterly review covering both programs |
External assessment | QSA (ROC) or self (SAQ) annually | Certification body audit (3-year cycle + annual surveillance) | Compliance calendar coordinates both assessment windows |
Timeline for Running Both
Phase | Activities | Approx. Duration (Illustrative, Mid-Market Merchant) |
|---|---|---|
Phase 1: Combined gap analysis | Assess current state against both PCI DSS and ISO 27001 Annex A; identify shared vs. framework-specific gaps | 4–6 weeks |
Phase 2: Scope definition | Define CDE boundary and ISMS scope; document containment relationship | 2–3 weeks |
Phase 3: Control design and documentation | Build shared policies, segmentation architecture, risk register, SoA | 8–10 weeks |
Phase 4: Control implementation | Deploy technical controls (MFA, logging, encryption, segmentation) | 10–16 weeks (can run parallel to Phase 3 tail) |
Phase 5: Internal audit and remediation | Run internal audit program; close findings before external assessment | 4–6 weeks |
Phase 6: PCI validation | QSA-led ROC (or SAQ completion) and ASV scans | 3–5 weeks |
Phase 7: ISO 27001 Stage 1 audit | Documentation review by certification body | 1–2 weeks, often scheduled 4–8 weeks after Phase 6 |
Phase 8: ISO 27001 Stage 2 audit | Full ISMS operational audit and certification decision | 2–4 weeks after Stage 1 |
Total elapsed time for a mid-market organization running both from a standing start typically lands between 12 and 16 months, though organizations with a mature security baseline already in place have compressed this closer to 8–9 months. Running the PCI validation slightly ahead of the ISO Stage 1 audit tends to work well operationally, since PCI's more prescriptive requirements surface gaps that would otherwise show up as ISO nonconformities later. For a general sense of how ISO certification timelines run on their own, see our breakdown of how long ISO 27001 certification realistically takes.
Cost and Effort of Doing Both
These figures are illustrative, drawn from the range of mid-market engagements I've advised on, and will vary significantly by organization size, existing security maturity, number of locations, and whether you use consultants versus building entirely in-house.
Cost Category | PCI DSS Alone (Mid-Market, SAQ D/ROC) | ISO 27001 Alone (Mid-Market) | Combined Program (Illustrative Total) |
|---|---|---|---|
Gap analysis / readiness assessment | $15,000–$35,000 | $15,000–$30,000 | $25,000–$45,000 (shared effort) |
Consulting / implementation support | $40,000–$120,000 | $50,000–$150,000 | $70,000–$180,000 (overlap reduces duplicate hours) |
Technical remediation (segmentation, MFA, logging, encryption tooling) | $50,000–$200,000+ | $30,000–$100,000 | $70,000–$220,000 (shared infrastructure investment) |
QSA assessment / ROC | $20,000–$80,000 depending on scope | N/A | $20,000–$80,000 |
Certification body audit fees (Stage 1 + Stage 2) | N/A | $12,000–$30,000 | $12,000–$30,000 |
Internal staff time (FTE-equivalent, annualized) | 0.5–1.5 FTE | 0.5–1.5 FTE | 0.75–2 FTE (shared compliance function) |
Ongoing annual maintenance | $30,000–$90,000/year | $15,000–$40,000/year (surveillance audits, internal audit) | $40,000–$110,000/year (combined, not additive) |
The pattern worth internalizing from that table: the combined program is meaningfully cheaper than the sum of running both independently, because the biggest cost centers — technical remediation and consulting hours — overlap heavily once you've designed shared controls. Organizations that run them as two disconnected initiatives, with two separate consulting engagements and two separate internal teams, routinely pay 30–50% more than they would running a coordinated combined program. For a deeper look at how ISO 27001 costs break down on their own, see our realistic ISO 27001 implementation cost breakdown, and our ISO 27001 Certification Cost Calculator can help you model your own numbers before committing budget.
Common Mistakes When Running PCI DSS and ISO 27001 Together
Mistake | Why It Happens | Consequence |
|---|---|---|
Treating PCI DSS as a subset of ISO 27001 controls | Assuming overlap means equivalence | QSA fails you on PCI-specific requirements ISO never validated (MFA, ASV scans, retention rules) |
Letting ISO 27001 ISMS scope exclude the CDE | Scoping ISO narrowly to minimize audit effort | Loses the efficiency of a combined program; duplicates policy work |
Poor network segmentation inflating PCI scope | Underinvesting in segmentation architecture upfront | Dramatically increases cost and audit burden by pulling unrelated systems into the CDE |
Running two disconnected compliance calendars | No single owner coordinating both programs | Audit fatigue, duplicated evidence requests, wasted staff time |
Assuming an ISO 27001 certificate satisfies acquiring bank requirements | Misunderstanding what each framework's assurance actually covers | Acquirer rejects the substitution; PCI validation still required separately |
Documenting policies twice, once per framework | Compliance and security teams working in silos | Policy drift between the two versions; auditors catch inconsistencies |
Skipping internal audit sampling of PCI-relevant controls | Treating Clause 9 internal audit as an ISO-only formality | Nonconformities surface for the first time during the external ISO audit or QSA assessment |
Underestimating the retention and disposal specificity PCI demands | Applying a general ISO data-classification scheme without card-data-specific rules | PCI Requirement 3 violations even with a mature ISO classification program in place |
Case Study 1: Larkspur Outfitters — Combining Both After a Competitor's Wake-Up Call
Back to Danielle Osei's board meeting. Larkspur was already PCI DSS compliant at SAQ D level — they stored tokenized cardholder data for a subscription-box product line, which pushed them out of the lighter SAQ tiers. But their PCI program had been treated as a standalone annual scramble owned by a single compliance analyst, disconnected from the rest of the security function, and the board wanted independent assurance that covered more than just the payment flow.
Danielle's team ran a combined gap analysis against both PCI DSS v4.0.1 and ISO 27001 Annex A over five weeks, and found that roughly 60% of the technical controls needed for ISO 27001 were already substantially in place because of the PCI program — logging, access control, encryption, and vulnerability management were all mature within the CDE. The gaps were almost entirely outside the payment flow: no formal risk assessment methodology covering non-card data, no documented supplier risk management program for non-payment vendors, and no internal audit function at all.
Over the following 14 months, Larkspur redefined its ISMS scope to contain the existing CDE, built a single combined policy set, stood up an internal audit program that sampled both PCI and ISO controls each quarter, and passed both its ROC (via QSA) and its ISO 27001 Stage 2 audit within seven weeks of each other. Total program cost, including consulting support and technical remediation (primarily improved network segmentation and a new SIEM deployment), came to approximately $210,000 — which the CFO calculated as roughly 3.3% of the $6.3 million ThreadForge had absorbed in breach costs alone.
"The board didn't want to hear 'we're PCI compliant' anymore — ThreadForge was PCI compliant too, right up until they weren't. What convinced our customers and our board was showing them an independently certified management system that covered the whole business, with PCI DSS as the rigorous, mandatory floor inside it, not a separate island." — Danielle Osei, CISO, Larkspur Outfitters
"Larkspur's biggest advantage going into their ROC was that their access control and logging evidence had already been organized for an ISO audit. I didn't have to chase down a dozen different owners for a dozen different spreadsheets — it was one evidence library, tagged by requirement. That alone probably saved them three weeks of assessment time." — Marcus Chen, QSA, Ferrous Assurance Partners
Case Study 2: Meridian Pay — A Service Provider Scaling Trust
Meridian Pay, a mid-sized payment processing service provider handling card transactions for roughly 4,000 downstream merchants, had been PCI DSS Level 1 compliant (via annual ROC) for six years before pursuing ISO 27001. The trigger wasn't a breach — it was a string of lost enterprise deals. Three separate prospective bank partners had, in the same quarter, asked Meridian's sales team for an ISO 27001 certificate during due diligence, and Meridian didn't have one to show.
Because Meridian's PCI program was already mature — quarterly ASV scans, annual penetration testing, MFA enforced across the CDE, a tested incident response plan — their ISO 27001 gap analysis came back unusually clean on the technological control side. The real work was on the management-system side: building a formal risk assessment methodology, standing up a management review cadence, and extending their existing vendor risk program (built for PCI's supplier requirements) to cover the full Annex A supplier relationship controls (5.19–5.23).
Meridian achieved ISO 27001 certification in nine months — faster than the mid-market average — specifically because their PCI maturity had already built most of the technical control evidence. Within five months of certification, Meridian's sales team reported that ISO 27001 had become a named requirement in roughly 40% of new enterprise RFPs they were responding to, and closed two bank partnerships that had explicitly stalled during the pre-certification period.
"Being a QSA-validated Level 1 service provider used to be the whole story we told prospects. It isn't anymore. Banks doing vendor due diligence want to see a certified management system — governance, risk treatment, internal audit — not just a technical attestation for the card-processing slice of what we do." — Tom Reyes, Director of Compliance, Meridian Pay
"Meridian is a good example of what I look for when a PCI-mature organization comes in for Stage 1: the technical controls are usually solid, but I'm checking whether the management system around them — risk ownership, management review, documented decision-making — actually exists, or whether PCI compliance has been running on tribal knowledge. Meridian had done the harder organizational work before we ever showed up." — Priya Nataraj, ISO 27001 Lead Auditor, Cascade Certification Body
Case Study 3: Fenwick Cloud Suite — Minimal PCI Footprint, Full ISO Investment
Fenwick Cloud Suite, a project-management SaaS platform, illustrates the opposite pattern: a genuinely light PCI footprint paired with a strategic, full-scale ISO 27001 investment. Fenwick outsources all payment processing to a PCI-validated third party via a hosted checkout integration, stores no cardholder data on its own systems, and validates PCI DSS annually via SAQ A — a low-burden, roughly 24-question self-assessment that takes their compliance team about two weeks to complete each year.
Fenwick's ISO 27001 program, by contrast, was a deliberate, full 10-month implementation covering the entire SaaS platform — customer project data, source code, employee records, and infrastructure — because their target customers were mid-market and enterprise buyers who required independent security certification as a condition of the sales cycle, regardless of how little card data Fenwick actually touched. Fenwick's team was explicit internally that the ISO 27001 investment had nothing to do with payment card risk and everything to do with proving broader data-handling maturity to buyers who cared about their customers' project data, not their card numbers.
Fenwick's finance team tracked a 22% increase in average enterprise deal size and a two-week reduction in average security-review cycle time during procurement, in the twelve months following certification — evidence that, for a SaaS company, ISO 27001 paid for itself as a sales enabler even though its PCI DSS obligation remained minimal throughout.
"We get asked about ISO 27001 in nearly every enterprise security questionnaire now. We get asked about PCI maybe one time in twenty, and when we are, 'SAQ A, fully outsourced' closes the question in one line. The two frameworks are just answering completely different buyer concerns for us." — Sofia Bianchi, Head of Information Security, Fenwick Cloud Suite
Case Study Outcomes Summary
Organization | Starting Point | Program Pursued | Duration | Key Quantified Outcome |
|---|---|---|---|---|
Larkspur Outfitters | PCI SAQ D compliant, no ISMS | Combined PCI ROC + ISO 27001 | 14 months | ~$210,000 total cost vs. $6.3M competitor breach cost; single evidence library cut QSA assessment time |
Meridian Pay | PCI Level 1 ROC compliant, no ISO certification | ISO 27001 added on mature PCI base | 9 months | ISO 27001 became a requirement in ~40% of new enterprise RFPs within 5 months; 2 bank partnerships closed |
Fenwick Cloud Suite | SAQ A (outsourced payments), no ISMS | Full ISO 27001 implementation | 10 months | 22% increase in average enterprise deal size; 2-week reduction in security review cycle time |
The Strategic Close: Compliance as Competitive Positioning, Not Just a Cost Center
I've watched a lot of organizations treat PCI DSS and ISO 27001 as two boxes on a compliance checklist, budgeted grudgingly and staffed as thinly as an auditor will tolerate. That's a mistake, and it's an increasingly expensive one. The market has shifted: enterprise buyers, banks, and increasingly insurers are treating independent, audited security assurance as a baseline expectation rather than a differentiator, and organizations that can point to both a clean PCI validation history and an ISO 27001 certificate close deals faster, negotiate better cyber-insurance terms, and recover trust faster after an incident than competitors running on PCI alone.
The efficient path isn't choosing between the two — for most organizations handling card data at any meaningful scale, it's building one coherent security program where PCI DSS sets the non-negotiable, prescriptive floor for the cardholder data environment, and ISO 27001 extends that same discipline, risk-based and independently certified, across everything else the business touches. Danielle's board at Larkspur didn't actually want to choose between PCI and ISO 27001 — they wanted assurance that a ThreadForge-style breach couldn't happen on their watch, in the card environment or anywhere else. That's what a combined program delivers, and it's a stronger story to tell customers, auditors, and your own board than either framework can tell alone.
"Clients ask me constantly whether PCI or ISO is 'the better' framework, as if it's a single choice. It's the wrong question. PCI DSS is the price of admission for touching card data. ISO 27001 is how you prove the rest of your house is in order. The organizations that get hurt are the ones that only ever built the one room the card brands were looking at." — Aaron Whitfield, Payments Risk Consultant, Whitfield Advisory
If you're trying to figure out where your organization actually sits on the PCI-only-versus-both spectrum, start with a structured gap analysis rather than a guess — our ISO 27001 Gap Analysis Tool will show you exactly which Annex A controls you already satisfy through your existing PCI program and which represent genuinely new work, and our ISO 27001 vs. SOC 2 vs. NIST CSF Comparison Guide can help you sequence a broader multi-framework roadmap if PCI DSS is just one piece of a bigger assurance picture. For a fast reference while you scope the Annex A side of a combined program, keep our Annex A — All 93 Controls at a Glance cheat sheet on hand, and once you're ready to formalize scope decisions, our Statement of Applicability (SoA) Template and Complete ISO 27001 Implementation Guide eBook will save you from building your documentation set from a blank page.
Whether you land on PCI DSS alone, PCI DSS plus SOC 2, or the combined PCI DSS and ISO 27001 model most mid-market and enterprise organizations eventually adopt, the decision should follow your actual risk exposure and customer expectations — not a guess made in a board meeting under pressure, the way Danielle's almost was. Get the gap analysis done, map your controls before you build anything twice, and let the evidence tell you which framework — or both — your organization genuinely needs.