PCI DSS has 12 requirements grouped into 6 control families. One family, access control, generates more QSA findings than the other five combined. Here's what it actually demands.
Your QSA doesn't spend equal time on all 12 PCI DSS requirements. Firewall configs get checked. Encryption gets verified. But access control is where they dig in, because it's where organizations accumulate the most drift between what a policy says and what actually exists in production.
A former marketing employee who still has database access eight months after switching teams. A shared login three people use because provisioning individual accounts felt like overhead. An admin account nobody remembers creating. These aren't edge cases. They're the default state of access in most organizations, and they're exactly what Requirements 7, 8, and 9 exist to catch.
This article breaks down what PCI DSS access control actually requires, why it's harder to sustain than it looks on paper, and where the other five control families fit around it.
PCI DSS at a Glance: The Other Five Control Families
Before getting into access control, here's the rest of the framework in brief, since access control doesn't exist in isolation.
Secure networks and systems (Requirements 1-2). Firewalls that separate your cardholder data environment (CDE) from the rest of your network, and vendor-default credentials changed before anything goes into production.
Protect cardholder data (Requirements 3-4). Encryption for stored card data, and strong cryptography for card data in transit over public networks.
Vulnerability management (Requirements 5-6). Updated anti-malware tooling and a documented process for identifying, ranking, and patching security vulnerabilities in systems and application code.
Monitoring and testing (Requirements 10-11). Logging every access attempt to the CDE with enough detail to reconstruct who did what and when, plus regular vulnerability scans and penetration tests (quarterly scans by an Approved Scanning Vendor are mandatory).
Information security policy (Requirement 12). A documented InfoSec policy, shared with everyone who touches cardholder data, reviewed at least annually.
All five matter. None of them generate the volume or complexity of findings that access control does, because they're largely set-once-and-monitor. Access control is different: it has to hold up every single day, as people join, move teams, get promoted, and leave.
Requirement 7: Restrict Access by Business Need-to-Know
Requirement 7 is simple to state and hard to sustain: nobody gets access to cardholder data unless their job requires it.
That sounds obvious until you look at how access actually gets granted in most organizations. A new hire gets copied from a colleague's access profile because it's faster than defining what they actually need. A contractor gets broad access "just in case" because scoping it precisely takes longer than the engagement is worth. An engineer keeps CDE access from a project that ended eighteen months ago because nobody built a process to remove it.
What Requirement 7 actually mandates:
- Access assignment based on job classification and function, not convenience or default settings
- A default-deny posture, meaning access is denied unless explicitly authorized, not granted unless explicitly denied
- Documented approval for every access grant, showing who authorized it and why
- Role-based access control (RBAC), least-privilege access, or a comparable need-to-know model applied consistently
Where this breaks down in practice:
The HR department doesn't need cardholder data access, yet in a surprising number of environments, someone in HR has standing access to a payment system because they needed it once for a specific task and nobody revoked it afterward. Requirement 7 treats this as a finding regardless of intent. The QSA doesn't ask whether the HR employee ever misused the access. They ask whether the access should exist at all.
The fix isn't a one-time cleanup. It's an access model where grants are scoped narrowly from the start (role-based, need-to-know, or just-in-time) and an approval workflow that makes it structurally harder to over-provision than to provision correctly. When Zluri customers automate this, the rule is typically expressed as: user department equals X, role equals Y, then access to CDE-scoped applications is denied by default and requires explicit approval with a documented business reason.
Requirement 8: Identify and Authenticate Every User
Requirement 8 is about knowing exactly who is behind every action taken against cardholder data. That starts with unique identification and extends into how those identities are authenticated and maintained over time.
What Requirement 8 actually mandates:
- A unique ID for every user with CDE access, no shared or group logins
- Strong authentication, with multi-factor authentication required for all access into the CDE under PCI DSS v4.0
- Password and credential policies that meet minimum complexity and rotation standards
- Account lifecycle discipline: accounts disabled promptly on termination, and inactive accounts removed after 90 days (a v4.0 requirement, detailed further in our article on PCI DSS user access reviews)
Why shared credentials keep showing up despite being an obvious violation:
Shared logins persist because they're operationally convenient. A small ops team accessing a payment dashboard might all use one login because provisioning four separate accounts with four separate MFA setups feels like unnecessary overhead, until a QSA asks who accessed the system on a specific date and the honest answer is "we don't know, it could have been any of them." At that point the convenience argument collapses. Requirement 8 exists precisely because shared credentials make accountability impossible, and accountability is the entire point of identification and authentication controls.
Where unique IDs alone aren't enough:
Assigning a unique ID satisfies the letter of the requirement but not necessarily its intent if the account sits dormant, unmonitored, for months. A QSA sampling accounts doesn't just check whether IDs are unique. They check last-login timestamps, and an account that's technically unique but hasn't authenticated in 150 days is a finding under the dormant-account provisions, not a pass because it happens to have a proper ID.
Requirement 9: Restrict Physical Access to Cardholder Data
Requirement 9 covers the physical side of access control: the servers, workstations, and paper records where cardholder data lives or is handled.
What Requirement 9 actually mandates:
- Controlled entry to facilities and areas where CDE systems are physically located, typically via badge access or key card systems
- Visitor logs and escort procedures for anyone without standing authorization
- Video surveillance or equivalent monitoring, with footage retained for at least 90 days
- Restrictions on removable media (USB drives, external hard drives) so cardholder data can't walk out on a device
- Secure destruction procedures for any physical media containing cardholder data once it's no longer needed
Physical access control gets less attention than its digital counterpart because most PCI conversations happen entirely in the context of cloud infrastructure and SaaS applications. But if your CDE includes any on-premises component (a local server, a point-of-sale terminal, a data center you control), Requirement 9 applies in full, and QSAs will test it during on-site assessments for Level 1 organizations.
Why Access Control Generates More Findings Than Any Other Requirement
The other five control families are largely static. You configure a firewall rule and it holds until someone changes it. You encrypt a database and the encryption doesn't degrade over time. Access control has none of that stability, because the underlying population it governs (employees, contractors, service accounts) is constantly changing.
Someone gets hired. Someone changes teams. Someone goes on leave. Someone's contract ends. Someone builds a service account for an integration and forgets it exists. Every one of these events is a potential access control violation waiting to happen, and there's no configuration setting that prevents it. It requires an ongoing process: provisioning that's scoped correctly from day one, and review cycles that catch what provisioning misses.
This is why Requirement 7.2.3 (quarterly review of user access) and Requirement 8.1.4 (90-day dormant account removal) sit at the center of most QSA findings. They're not testing whether you configured something correctly once. They're testing whether your access control holds up under the pressure of constant organizational change. We go deep into exactly how those reviews work, what QSAs test for, and where reviews break down in our companion article on PCI DSS user access reviews.
Building Access Control That Holds Up Under QSA Testing
Manually enforcing need-to-know restrictions, unique ID discipline, and dormant account removal is possible at small scale and increasingly untenable as headcount and application count grow. The typical failure mode isn't a deliberate policy violation. It's drift: access granted correctly at the start, then never revisited as circumstances change.
Zluri's access management automates the parts of Requirement 7 and 8 that manual processes handle poorly. Provisioning rules enforce need-to-know at the point of access grant, not after the fact. Automated workflows revoke access the moment a trigger condition is met (department change, termination, role change) instead of waiting for someone to remember. Dormant account tracking flags accounts approaching the 90-day threshold before they become a violation, not after a QSA finds them during sampling.
For example, to enforce Requirement 7 for a department that shouldn't have CDE access, a rule can be set up as: when a user's department equals HR, then revoke access to all applications storing cardholder data. Once configured, this runs automatically whenever the condition is met, without anyone remembering to check.
Frequently Asked Questions
What is the difference between PCI DSS Requirements 7, 8, and 9?
Requirement 7 governs need-to-know access restrictions (who should have access based on role). Requirement 8 governs identification and authentication (verifying who is actually accessing the system, through unique IDs and MFA). Requirement 9 governs physical access to systems and media containing cardholder data.
How often does PCI DSS require access reviews?
PCI DSS v4.0 technically requires reviews at least every six months. In practice, most QSAs and payment processors expect quarterly reviews, especially for organizations with significant transaction volume. Requirement 8.1.4 separately mandates that accounts inactive for 90+ days be disabled or removed.
Is multi-factor authentication mandatory under PCI DSS?
Yes. PCI DSS v4.0 requires multi-factor authentication for all access into the cardholder data environment, not just for administrative or remote access as earlier versions specified.
Can shared login credentials ever be compliant with PCI DSS?
No. Requirement 8 mandates a unique ID for every individual with CDE access. Shared or group logins make it impossible to attribute actions to a specific person, which directly conflicts with the requirement's purpose.
Does Requirement 9 apply if our cardholder data environment is entirely cloud-based?
Requirement 9's physical security provisions are most relevant when your organization directly controls physical infrastructure, such as on-premises servers or point-of-sale terminals. If your CDE runs entirely on a PCI DSS-compliant cloud provider, physical security responsibility largely shifts to that provider, though you should confirm this is documented in your shared responsibility agreement.
What is the most common cause of a QSA finding under access control requirements?
Dormant or orphaned accounts (access that was never revoked after a role change, offboarding, or project end) is the most common finding, followed by service accounts that were never included in access reviews at all.
.svg)
