PCI DSS levels expose where access reviews and audit scope diverge

At a glance

What this is: This article explains the four PCI DSS merchant levels and service provider levels, with the key finding that transaction volume drives audit obligations while access reviews still determine whether cardholder data access can be defended.

Why it matters: IAM, IGA, and PAM teams should treat PCI DSS scope as a governance problem as much as a compliance classification problem, because evidence of authorised access is often what makes the difference between a manageable assessment and a failed one.

Context

PCI DSS levels are a transaction-volume classification system, not a general security maturity score. They determine whether a merchant or service provider must produce an on-site report on compliance, a self-assessment questionnaire, quarterly scans, or annual penetration testing.

For identity teams, the useful question is not only which PCI DSS level applies. The operational question is whether access to cardholder data is tightly enough governed that the organisation can prove scope, reviewer accountability, and evidence quality when audit time arrives.

Key questions

Q: What breaks when PCI DSS scope is not mapped to access and lifecycle controls?

A: The boundary becomes a paper exercise. Systems that connect to cardholder data, accounts with lingering privileges, and third-party access paths can all expand the cardholder data environment without anyone formally noticing, which is how organisations end up auditing the wrong assets and missing the real risk.

Q: Why do PCI DSS obligations change by merchant level?

A: They change because PCI DSS uses annual transaction volume as a risk and complexity proxy. Higher-volume merchants face more formal assurance requirements, including external audits and deeper evidence collection, while lower-volume organisations can use self-assessment routes. The practical consequence is that controls, documentation, and review depth scale with processing volume.

Q: What are the signs that access review evidence will not hold up in a PCI assessment?

A: Weak signs include stale entitlements, unclear system scope, manual review notes without remediation, and reviewer decisions that are not tied to specific cardholder-data applications. If the evidence cannot show who had access, who approved it, and what was fixed, the assessment will be difficult to defend.

Q: Should organisations treat PCI DSS self-assessments as an identity governance exercise?

A: Yes. A self-assessment is only credible when the organisation can show that access to cardholder data is current, limited, and reviewed with clear ownership. Identity governance supplies the evidence trail behind that claim, so access reviews and remediation records are part of the compliance control set, not optional extras.

Technical breakdown

How PCI DSS merchant levels change audit evidence

PCI DSS levels change the evidence path, not the underlying need to control access. Higher-volume merchants generally need a qualified security assessor, a report on compliance, quarterly scanning, annual penetration testing, and an attestation of compliance. Lower-volume merchants may rely on a self-assessment questionnaire, but that still depends on the organisation being able to demonstrate which systems, users, and processes are in scope. In practice, the level determines who validates the control environment and how formally the findings must be documented. The control problem remains the same: you still need provable control over the identities that can reach cardholder data.

Practical implication: Treat PCI level assignment as a scope and evidence exercise, not just a compliance label.

Why access reviews matter to PCI DSS scope

The article’s Zluri example shows why identity governance sits underneath PCI work. Access review automation is being used to document which users have access to applications that store cardholder data, detect anomalies, and produce a user access review report that supports the annual self-assessment process. That matters because PCI evidence is not just about network scans and policy statements. It also has to show that access is authorised, current, and reviewable. If review outcomes are stale, manual, or poorly scoped, the organisation may have a compliance form but not a defensible access control story.

Practical implication: Use access reviews to prove who can reach cardholder data systems before audit evidence is assembled.

Merchant and service provider classification is an access governance issue

PCI DSS draws a line between merchants, which directly accept and handle cardholder data, and service providers, which process it on behalf of others. That distinction changes the obligations, but it also changes where identity controls need to be strongest. Service providers inherit trust from multiple customers, so their access reviews, offboarding, and scoping discipline matter even more because they can affect several downstream compliance programmes at once. For merchants, the control challenge is often internal sprawl across apps and teams. For service providers, the challenge is proving that delegated access has not expanded beyond the role that was originally justified.

Practical implication: Map access governance separately for merchants and service providers because their audit evidence and risk boundaries are not the same.

NHI Mgmt Group analysis

PCI DSS levels are an audit-scoping mechanism, but access governance decides whether the scope is defensible. The article correctly separates transaction volume from compliance obligations, yet identity teams should notice that every path still depends on proving who can reach cardholder data. That makes access governance a prerequisite to a credible PCI narrative, not a downstream administrative task. The practical conclusion is that scope classification and access evidence have to be managed together.

Access review quality becomes the hidden control behind PCI self-assessment. A self-assessment questionnaire is only as reliable as the identity data behind it, including who has access, which applications are in scope, and whether anomalies are remediated before submission. Manual or informal review processes create the appearance of compliance without the proof. Practitioners should treat review completeness and reviewer accountability as part of the compliance control set.

Delegated payment processing creates a governance boundary that many programmes under-model. Service providers and merchants are different compliance actors, but both depend on access governance that reflects actual data handling paths. When third parties process cardholder data on behalf of multiple customers, lifecycle discipline and entitlement scoping become central to trust. The conclusion is that PCI programmes need identity boundaries as precise as their transaction thresholds.

Transaction thresholds do not reduce the need for least privilege and evidence discipline. The article frames lower levels as less burdensome, but lower burden is not lower risk. Even organisations using a self-assessment route still need to show that access to cardholder data is limited, reviewable, and correctly remediated. The practical implication is that review automation and entitlement hygiene should scale with PCI scope, not after it becomes painful.

PCI compliance is increasingly an identity evidence problem, not just a controls checklist. The more organisations automate assessments, the more the quality of identity records, access reviews, and remediation trails determines whether evidence holds up. That shifts importance from annual paperwork to continuous access visibility. Practitioners should prepare for compliance programmes that are judged by the quality of identity evidence they can produce on demand.

What this signals

PCI DSS scope is easier to classify than it is to prove. The article’s useful lesson for practitioners is that transaction thresholds set the compliance route, but access evidence determines whether the route stands up in audit. Identity teams should therefore align PCI scope reviews, access reviews, and remediation trails instead of treating them as separate workstreams.

Access reviews are the control that turns PCI categorisation into audit evidence. When the organisation can show which identities can reach cardholder data and how anomalies are handled, the self-assessment or audit process becomes materially more defensible. Without that identity evidence, the level classification still exists, but the assurance story is weak.

For practitioners

• Tighten cardholder-data scope definitions Identify every application, user group, and service account that can reach cardholder data, then keep the scope register aligned to actual access paths rather than org charts.
• Automate user access reviews for in-scope systems Run recurring reviews against the apps that store or process cardholder data, and require timely remediation for anomalous or unapproved entitlements.
• Separate merchant and service-provider evidence Maintain different control evidence, review cadences, and ownership records for internal merchant processing and third-party service-provider processing.
• Document audit-ready remediation trails Retain reviewer decisions, anomaly outcomes, and approval history so the SAQ or RoC can be backed by specific access evidence.

Key takeaways

• PCI DSS levels define how organisations are assessed, but they do not remove the need to prove who can access cardholder data.
• The article shows that merchant level, service provider status, and annual transaction volume change the audit path and evidence burden.
• Identity governance is the practical bridge between PCI scope and compliance proof, especially where access reviews support SAQ or RoC submission.

Key terms

• PCI DSS Level 1: PCI DSS Level 1 is the highest validation level in the Payment Card Industry Data Security Standard. It indicates that a service provider has met the most stringent assessment requirements for handling cardholder data. Organisations still need correct configuration, access control, and monitoring to remain compliant when using the service.
• Report on Compliance (RoC): A formal assessment report used by larger merchants and service providers to evidence PCI DSS compliance. It typically requires a qualified assessor and becomes expensive when the underlying control environment is fragmented or poorly documented.
• Self-assessment questionnaire: A self-assessment questionnaire is a PCI compliance form used by organisations that are permitted to validate controls internally. It is not a substitute for security work, but a structured way to document scope, control coverage, and evidence for lower-tier PCI environments.
• Access review automation: Access review automation is the use of workflow, policy, and evidence collection to reduce manual certification work. It does not remove governance. It changes the operating model so reviewers focus on exceptions, risk, and accountability instead of reading every entitlement one by one.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.