Support PCI DSS readiness with adaptive compliance

PCI DSS — the Payment Card Industry Data Security Standard — is published by the PCI Security Standards Council. Enforcement belongs to the card brands, and it reaches you through your bank. Enforcement belongs to the card brands, and it reaches you through your bank.

The Council develops and maintains the standard and runs the programs that qualify assessors. It does not enforce anything and it does not certify any merchant. In its own words, each participating payment brand "maintains its own separate compliance enforcement programs, including which entities need to validate compliance, validation levels, whether an entity is eligible to complete a Self-Assessment Questionnaire (SAQ) or must complete a Report on Compliance (ROC), and any fines or penalties."

Visa states its side of the arrangement directly: the Council "owns, maintains and manages the PCI DSS and all its supporting documents; however, Visa manages all data security compliance enforcement and validation initiatives."

One detail worth knowing: the brands assess non-compliance fees against your acquirer, not against you. The acquirer passes them down under your merchant agreement. "Visa fined the merchant" is never technically what happened.

PCI DSS v4.0.1, published 11 June 2024. It is the only version you can be assessed against. Version 3.2.1 retired on 31 March 2024 and v4.0 retired on 31 December 2024.

Note the order — v3.2.1 retired before v4.0 did, because v4.0 was itself replaced mid-life by the v4.0.1 limited revision. Vendor timelines routinely garble this.

Every one of the future-dated requirements introduced in v4.0 became mandatory on 31 March 2025. There is no remaining grace period. If your last assessment treated MFA for all non-console CDE access, automated log review, or twelve-character passwords as "best practice until," that window closed.

The Council ran a six-week request for comments on v4.0.1 from 3 June to 20 July 2026 to begin shaping the next iteration. No successor has been published and no date has been announced, and the RFC solicited feedback on the current standard rather than on a draft.

1. Install and Maintain Network Security Controls
2. Apply Secure Configurations to All System Components
3. Protect Stored Account Data
4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
5. Protect All Systems and Networks from Malicious Software
6. Develop and Maintain Secure Systems and Software
7. Restrict Access to System Components and Cardholder Data by Business Need to Know
8. Identify Users and Authenticate Access to System Components
9. Restrict Physical Access to Cardholder Data
10. Log and Monitor All Access to System Components and Cardholder Data
11. Test Security of Systems and Networks Regularly
12. Support Information Security with Organizational Policies and Programs

Underneath those twelve sit more than three hundred individual requirements. The Council does not publish a total, so treat any specific number you see — including ours — as someone's count rather than an official figure.

No — and the Council has gone out of its way to say so.

"PCI SSC does not provide compliance certificates or compliance logos, and organizations do not have permission to use a PCI SSC or PCI DSS logo on a certificate or document purporting PCI DSS compliance. Except for the official forms or documents on the PCI SSC website, any certificate or document that indicates PCI DSS compliance is not from the Council nor is it an official verification of PCI DSS compliance."

There is a sharper edge to this than the branding question. The Council's FAQ 1220 states that using a non-authorized certificate to validate a third party's compliance "is also not acceptable" for your obligations under Requirements 12.8 and 12.9. So if a vendor hands you a "PCI Certified" badge and you file it as due diligence, the defect is now yours.

What you actually end up with is an Attestation of Compliance, backed by either a Report on Compliance or a Self-Assessment Questionnaire.

• ROC (Report on Compliance) — the detailed assessment report. It documents your environment, the samples the assessor selected, and how each requirement was tested. Required for the largest merchants, and a QSA must use the Council's template.
• SAQ (Self-Assessment Questionnaire) — the alternative for entities whose card brand program lets them self-assess. There are nine merchant variants plus one for service providers, each scoped to a particular payment setup. SAQ D for Service Providers is the only option a service provider can use.
• AOC (Attestation of Compliance) — the signed summary of the result. It reflects what's in the ROC or SAQ.
  

Note: the AOC is the document that gets shared. The Council treats the ROC and SAQ as sensitive, and expects third-party service providers to share their AOC with customers — not the underlying report.

Whether you're eligible for an SAQ at all is a decision for your acquirer or the card brands, not for the Council and not for your assessor.

There is also no expiry date on an AOC. The Council's template has no validity field. The familiar "good for twelve months" is a card brand convention — Visa requires acquirers to confirm their service providers' compliance at least every twelve months — not a Council rule.

Quite a lot — and the thresholds are far lower.

You reach Level 1 much sooner. Visa puts service providers at Level 1 above 300,000 transactions a year, against six million for merchants. Level 1 means an annual Report on Compliance by a Qualified Security Assessor. Below that it’s an annual self-assessment. Both tiers need quarterly external scans.

There’s only one self-assessment form available to you. SAQ D for Service Providers. Merchants pick from nine questionnaires scoped to their payment setup; you don’t get that choice.

The standard carries around fifteen requirements that apply to service providers only, and several of them double the frequency of something merchants do once a year:

• Scope confirmation every six months rather than twelve
• Segmentation penetration testing every six months rather than twelve
• A review every three months confirming personnel are actually performing their security tasks — and it has to be done by someone other than the person who performs the task
• Failures of critical security control systems detected, alerted and addressed promptly

And you carry obligations to your customers that merchants don’t. You must provide written agreements acknowledging you’re responsible for the security of the account data you hold or could affect. You must support customers’ requests for your compliance status, and for which requirements you’re covering on their behalf.

Your Attestation of Compliance is the document that gets shared — the Council treats the underlying report as sensitive but expects service providers to hand the attestation over.

By the card brands, from your annual transaction volume — and they don't agree with each other.

The Council sets no merchant levels at all; the concept doesn't appear anywhere in PCI DSS. Each brand runs its own tiers:

• Visa consolidated Levels 3 and 4 into a single Level 3 effective 25 April 2024. Level 1 is above six million annual transactions, Level 2 is one to six million, Level 3 is everything below.
• Mastercard still runs four levels, counting combined Mastercard and Maestro volume: over six million, one to six million, 20,000 to one million e-commerce, and everything else.
• American Express uses much lower thresholds: Level 1 starts at 2.5 million Amex transactions, then 50,000 and 10,000.

Because the bases differ — Visa counts all channels at the top tiers, Mastercard counts e-commerce at Level 3, Amex counts only its own transactions — a single company can sit at a different level with every brand simultaneously, and has to satisfy the strictest.

Two escalation rules worth knowing: both Visa and Mastercard can move you to Level 1 at their discretion, and an account data compromise is the usual trigger.

More than people expect. The Council defines the cardholder data environment in three parts, and the second and third are the ones that surprise teams:

1. System components, people, and processes that store, process, or transmit account data
2. System components that don't touch account data but have unrestricted connectivity to ones that do
3. System components, people, and processes that could impact the security of account data

The standard's own definition of "system components" explicitly names cloud infrastructure, containers and orchestration tools, cloud-based identity and access management, end-user devices, SIEM systems, and the code repositories and deployment tooling that push objects into the CDE. Your laptop fleet, your IdP, and your CI/CD pipeline are all named.

On reducing that scope, the Council is precise about what works:

• Segmentation is not a PCI DSS requirement — but without it, "the entire network is in scope."
• Encryption alone is generally insufficient to take data out of scope. If the environment holds the keys or the processes that use them, it stays in.
• A PCI-listed P2PE solution "can significantly reduce the number of PCI DSS requirements applicable… However, it does not completely remove the applicability of PCI DSS."

And one rule that catches people out: sensitive authentication data must not be stored after authorization, even if encrypted — and that applies even where no PAN (primary account number) is present.

No, and you should be careful with anyone who implies that SOC 2 and ISO 27001 map to this framework.

The Council has formally mapped PCI DSS to exactly one other framework — NIST CSF 2.0, in a mapping published on 23 July 2026 — and it attached a disclaimer to the footer of every page:

"The mapping is not a tool for demonstrating compliance to either PCI DSS or the NIST CSF, nor does meeting either a PCI DSS requirement or its corresponding NIST CSF outcome result in the other being met."

Even there, the Council's position is that the two "are not interchangeable, and neither is a replacement for the other."

For SOC 2 and ISO 27001 the Council has published nothing at all — no mapping, no comparison, no statement. Work done for those frameworks will often produce evidence you can reuse, but there is no authority anywhere that says one gets you the other.

Version 4.0 added a second route to meeting a requirement. The defined approach is the traditional one: implement the control as written, and the assessor follows the standard's testing procedures. The customized approach lets you meet the requirement's stated objective a different way — but there are no pre-written testing procedures, so your assessor has to derive them, and the documentation burden is explicitly higher. The Council describes it as intended for "risk-mature entities."

It is not the same as a compensating control. Compensating controls sit inside the defined approach and exist for entities that cannot meet a requirement because of a documented technical or business constraint. The customized approach is for entities that choose a different path to the same objective.

You can mix the two, even using different approaches for the same requirement in different parts of your environment.

Certain requirements in the main body are closed to the customized approach, including some under Requirement 3.3 covering sensitive authentication data, and 11.3.2, external vulnerability scanning by an Approved Scanning Vendor. The logic is clean: you can't customize your way out of not storing SAD, and you can't customize your way out of using a Council-approved scanning vendor.

No platform can, and PCI DSS is a case where it's worth being specific about why.

Your cardholder data environment is mostly infrastructure — payment applications, network segmentation, key management, physical access to card data. Several requirements are closed to us by design: external vulnerability scans under Requirement 11.3.2 must come from a PCI SSC Approved Scanning Vendor, and penetration testing under 11.4 needs an independent tester. Iru is neither.

What Iru does is the device and identity layer of your CDE, and it takes the platform rather than the compliance product alone. Iru Workforce Identity restricts access by business need to know and enforces multi-factor authentication for non-console access. Iru Endpoint Management applies secure configurations, enforces encryption on the devices that reach account data, and governs media and device disposal. Iru Vulnerability Management keeps software patched inside the one-month window Requirement 6.3.3 sets and runs the internal scans Requirement 11.3.1 asks for every three months. Iru Endpoint Detection & Response protects systems from malicious software and supports your incident response obligations. Iru Compliance Automation collects the evidence from all of them continuously.

That last part matters more here than on most frameworks. PCI DSS assesses you at a point in time but requires the controls to hold daily — log review every day, scans every three months, patches within a month. An annual AOC describes a snapshot. Continuous evidence is what shows the snapshot wasn't staged.

If you need an assessment, we can connect you with one of the assessors in our auditor network. Book a demo to explore the compliance solution, or if you're already a customer, reach out to your rep.