PCI DSS levels expose where access reviews and audit scope diverge

At a glance

What this is: This is an explainer on PCI DSS merchant and service provider levels, showing how transaction volume drives different compliance obligations and evidence requirements.

Why it matters: It matters to IAM, PAM, and governance teams because PCI compliance still hinges on access review, entitlement control, and auditable proof that only authorised identities can reach cardholder data.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's explanation of PCI DSS levels and compliance obligations

Context

PCI DSS levels are a transaction-based compliance model, not a simple label for company size. The key governance question is how much cardholder data exposure an organisation creates, who can reach it, and how much evidence it can produce when auditors ask for proof of control.

For IAM and access governance teams, the practical issue is that PCI obligations do not stop at network scans and questionnaires. They rely on entitlement accuracy, review cadence, offboarding discipline, and role scoping across human and non-human identities that can touch payment data.

Key questions

Q: How should security teams prepare for PCI DSS audits when access to cardholder data spans multiple systems?

A: They should first map which systems store, process, or transmit cardholder data, then identify every human and non-human identity with access to those systems. After that, align access reviews, scan evidence, and remediation records to the exact PCI scope so the organisation can defend its classification and the controls it claims to operate.

Q: Why do cardholder data environments need tighter access governance than general IT systems?

A: Because PCI evidence is not only about technical hardening. It also depends on proving that access to cardholder data is limited, reviewed, and corrected when exceptions appear. If entitlements are broad or stale, the organisation can still fail compliance even when scans and questionnaires are completed on schedule.

Q: What do organisations get wrong about PCI DSS levels and compliance effort?

A: They often treat the level as a paperwork category instead of a scope control. In reality, the level determines which evidence is required, but the organisation still needs accurate identity governance, offboarding discipline, and audit-ready documentation for systems that touch payment data.

Q: Who is accountable when a payment environment fails PCI requirements?

A: Accountability usually sits with the organisation that owns the cardholder data environment, but service providers, auditors, and internal control owners each have distinct obligations. The practical answer is that the business must assign named owners for scope, access review, scan evidence, and remediation so compliance does not become fragmented.

Technical breakdown

How PCI DSS merchant levels map to audit evidence

PCI DSS merchant levels are segmented by annual transaction volume, with Level 1 carrying the heaviest external validation requirements and lower levels relying more on internal attestation. The distinction matters because evidence expectations change with scale: report on compliance, self-assessment questionnaires, quarterly scans, and penetration testing are not universal. Compliance teams therefore need a transaction inventory that is accurate, current, and separated from personal or irrelevant volumes before level assignment can be defended.

Practical implication: build a reliable transaction evidence chain before assigning PCI level so the audit path is defensible.

Service provider levels and the identity boundary around card data

The article draws a clear line between merchants that directly accept payments and service providers that store, process, or transmit card data on behalf of others. That boundary is an identity boundary as much as an operational one, because service providers often hold the downstream access that determines whether payment data stays contained. In practice, the risk is not just possession of card data but the breadth of accounts, integrations, and administrative access that can reach it.

Practical implication: map every identity that can touch card data, especially third-party and delegated access paths.

Why access review remains a PCI control, not just a governance exercise

The article's automation example shows that PCI evidence can be generated more efficiently when access reviews are tied to specific applications and remediation rules. That points to a larger control truth: PCI compliance is strengthened when review scope, entitlement anomalies, and remediation actions are explicit rather than manual and ad hoc. Access review is therefore not a paper exercise. It is the mechanism that proves only approved users retain access to systems holding CHD.

Practical implication: tie access reviews to the exact applications and identities that store or process CHD.

NHI Mgmt Group analysis

PCI DSS level assignment is an access-governance problem disguised as a transaction-count exercise. The article correctly starts with volume thresholds, but the real control question is who can reach cardholder data and whether that access can be proved and reviewed. When compliance evidence depends on internal assessment, external audit, and entitlement validation, identity governance becomes part of the PCI control surface. Practitioners should treat level assignment as the start of governance scoping, not the end of it.

Service provider status creates a wider identity boundary than merchant status. Merchants can often reason about direct payment flows, but service providers inherit delegated access, shared responsibility, and third-party trust chains that expand the audit problem. That makes access reviews, offboarding, and privileged access control more important than transaction counts alone suggest. The implication is that the organisation must govern the identities around payment data, not just the data path.

CHD access review drift: PCI programmes fail when review cadence is detached from the identities that actually change access to cardholder data. The article's discussion of SAQ, RoC, ASV scans, and annual attestations points to a familiar failure mode: governance catches up slowly while access changes continuously. When that happens, the organisation can be compliant on paper and exposed in practice. Practitioners should read this as a signal that evidence quality depends on entitlement freshness.

Automation in PCI evidence generation should be judged by control fidelity, not convenience. The article's access review workflow is only useful if the underlying scope is correct, the anomaly rules are meaningful, and the remediation path is documented. Otherwise, the organisation produces faster evidence without improving control quality. For identity teams, the right question is whether the process proves least privilege over CHD with enough precision to satisfy both auditors and risk owners.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader baseline on why this matters, see NHI Lifecycle Management Guide for the lifecycle controls that keep access current.

What this signals

PCI programmes increasingly fail at the boundary between evidence collection and identity governance. When access reviews are disconnected from the identities that can reach cardholder data, the organisation may satisfy a form requirement while leaving real exposure untouched.

Identity evidence gap: the next maturity step is not more reporting, but tighter linkage between CHD scope, entitlement changes, and remediation records. That is the only way audit artefacts remain faithful to actual access conditions.

For teams building a stronger control baseline, the useful reference point is Ultimate Guide to NHIs, especially where service accounts, tokens, and delegated access influence payment systems.

For practitioners

• Validate PCI scope before assigning level Reconcile annual transaction counts, payment channels, and card-data touchpoints before deciding whether the organisation fits merchant or service provider criteria.
• Map every identity that can reach CHD Inventory human admins, service accounts, integrations, and delegated access paths that can store, process, or transmit cardholder data.
• Tie access reviews to CHD-bearing applications Run entitlement reviews against the exact applications that hold cardholder data and record the remediation outcome for each anomaly.
• Preserve audit evidence for SAQ, RoC, and AoC Keep review outputs, scan records, and control attestations together so the organisation can defend its PCI classification and control narrative.

Key takeaways

• PCI DSS levels change the audit path, but they do not reduce the need to govern who can reach cardholder data.
• The article's strongest lesson is that service provider and merchant models expand the identity boundary, not just the reporting burden.
• Access review quality, offboarding discipline, and evidence traceability are the controls that make PCI scope defensible.

Key terms

• Cardholder Data Environment: The cardholder data environment is the set of systems, people, and processes that store, process, or transmit payment card data. In PCI work, scope is everything because the security obligation follows the data and every identity that can reach it.
• Report On Compliance: A Report On Compliance is the formal audit record produced after an external assessment of PCI controls. It documents what was tested, what passed, and what gaps remain, making it a key evidence artefact for large merchants and service providers.
• Self-Assessment Questionnaire: A Self-Assessment Questionnaire is an internal compliance declaration used by organisations that qualify for a self-review path under PCI DSS. It is only as strong as the scope definition behind it, which is why access review evidence and transaction data matter.
• Service Provider: A service provider is a third party that stores, processes, or transmits cardholder data on behalf of another organisation. That role expands the identity boundary because delegated access, shared integrations, and offboarding discipline become part of PCI control assurance.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: What You Need to Know About the 4 PCI DSS Levels. Read the original.