Notifications
Clear all
Topic starter
12/06/2026 10:25 pm
TL;DR: PCI DSS merchant and service provider levels are determined by annual transaction volume, and the article explains how those thresholds change audit obligations, scanning cadence, and evidence requirements according to Zluri. The deeper issue for identity teams is that payment compliance still depends on access governance, review discipline, and provable control over who can reach cardholder data.
NHIMG editorial — based on content published by Zluri: What You Need to Know About the 4 PCI DSS Levels
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.
Questions worth separating out
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.
Q: Why do cardholder data environments need tighter access governance than general IT systems?
A: Because PCI evidence is not only about technical hardening.
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.
Practitioner guidance
- 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.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Exact transaction thresholds for each PCI DSS merchant level and service provider level
- Step-by-step guidance for choosing the right SAQ, RoC, and AoC path for your organisation
- The article's comparison of merchants versus service providers in PCI scope terms
- Zluri's access review workflow example for cardholder data environments
👉 Read Zluri's explanation of PCI DSS levels and compliance obligations →
PCI DSS levels and access reviews: what IAM teams need to know?
Explore further
13/06/2026 1:09 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS levels expose where access reviews and audit scope diverge
