Skip to content

PCI DSS vs ISO 27001

By Sam Rivera, Founder, SentinelPanda · August 5, 2026 · 3 min read · PCI DSS

One is a prescriptive control list scoped to card data and imposed by contract. The other is a risk-based management system you scope yourself and get certified against. They are not alternatives.

Different things entirely

The most common mistake is treating these as two options for the same job. PCI DSS is a security standard for one specific data type — cardholder data — maintained by the PCI Security Standards Council and imposed on you contractually if you store, process, or transmit it. ISO/IEC 27001 is a management-system standard: it certifies that you run a functioning Information Security Management System (ISMS) over whatever scope you define.

Put another way: PCI DSS tells you what to do about card data. ISO 27001 tells you how to run the machine that decides what to do about anything.

Prescriptive versus risk-based

PCI DSS is unusually prescriptive for a security standard. Its 12 requirements name specific controls — network segmentation, MFA into the cardholder data environment, quarterly external ASV scans, retention limits on stored data. There is little room to argue a requirement does not apply; if it is in scope, you meet it, take a compensating control, or (since v4.0) use the customised approach with a documented targeted risk analysis.

ISO 27001 inverts this. Annex A's 93 controls are a reference set, not a mandate. Your risk assessment drives which apply, and the Statement of Applicability is where you justify every inclusion and exclusion. Two certified organisations can have materially different control sets and both be legitimately compliant.

Who is asking, and what you hand them

  • PCI DSS: your acquiring bank or payment processor, because the card brands require it. You produce an Attestation of Compliance — self-signed via an SAQ, or QSA-signed off a Report on Compliance if you are Level 1.
  • ISO 27001: enterprise and international buyers, especially in Europe. You produce a certificate from an accredited certification body, plus the SoA if they ask.
  • Neither substitutes for the other in procurement. A buyer asking for your AOC will not accept an ISO certificate, and vice versa.

Where they genuinely overlap

The control-level overlap is substantial: access control, cryptography, logging and monitoring, vulnerability management, change management, supplier security, and incident response all appear in both. If you have a mature ISMS, a large share of PCI evidence already exists — you are mapping and re-scoping it rather than building it.

The overlap breaks down on PCI's specifics. ISO 27001 will never tell you to run quarterly ASV scans, mask PAN when displayed, or prohibit storing sensitive authentication data after authorisation. Those are PCI-only and have no ISO equivalent to inherit from.

Sequencing them

If you take card payments, PCI DSS is not optional and the timeline is set by your acquirer — do it first, on their schedule. ISO 27001 is a strategic choice about market access, and it can wait for a quarter without anyone invoicing you a fine.

Running both, scope them deliberately: many organisations define the ISO 27001 scope to include the cardholder data environment, so the ISMS governs the CDE and PCI evidence falls out of the same control operation. The alternative — two parallel programs with separate evidence — is how teams end up collecting the same access-review screenshot twice a year for two different auditors. Cross-framework mapping is exactly the problem SentinelPanda is built around: one control, one piece of evidence, satisfying both obligations.

PCI DSS 4.0.1: what changed ISO 27001 Statement of Applicability Cross-framework control mapping

Run your compliance program in one workspace.