PCI DSS applies when your company stores, processes, or transmits cardholder data. The assessment is run by a Qualified Security Assessor for larger merchants and service providers, and via a Self-Assessment Questionnaire for smaller volumes. Either way, the access control expectations are the same, and the recent v4.0 update raised the bar in several places.
This guide is for executives at merchants and service providers preparing for an assessment. It walks through Requirements 7, 8, and 10, the sections that cover access, authentication, and logging.
What PCI DSS actually is
PCI DSS is the Payment Card Industry Data Security Standard. It is a contractual obligation imposed by the card brands (Visa, Mastercard, American Express, Discover, JCB) on anyone who handles cardholder data. There is no government enforcement. The penalty for non-compliance is losing your ability to accept cards or paying fees the acquiring bank passes through.
The assessment process depends on your transaction volume and how you process cards. Level 1 merchants (over six million transactions annually) and all service providers require a Qualified Security Assessor to perform the assessment and produce a Report on Compliance. Smaller merchants fill out a Self-Assessment Questionnaire and submit an Attestation of Compliance.
The scope of the assessment is whatever touches cardholder data, which the standard calls the Cardholder Data Environment. Everything in the environment has to meet the requirements. Everything outside it is out of scope.
Requirement 7: restrict access by business need
The access model for the Cardholder Data Environment is deny-by-default. Every permission has to trace back to a documented business need. Roles are formal, approvals are recorded, and access is restricted to the narrowest set of people who need it to do their jobs.
In practice, this means the environment cannot share an identity plane with the rest of the company without careful scoping. The people who can reach cardholder data are a small, named population. Their access is reviewed on a cadence.
Requirement 8: identify and authenticate users
This is the requirement with the most teeth for IAM, and v4.0 tightened it further.
Unique user identification
Every person with computer access to the environment has a unique account. Not for the operations team. Not for contractors. Not for the shift-based call center. Every session is attributable to a single human.
Multi-factor for administrative access
Any administrative access that is not from a direct console requires multi-factor authentication. That covers remote administration, VPN sessions that lead to administrative work, web-based administrative portals, and any path where an administrator is reaching the environment over a network.
Multi-factor for all access to the environment
This is the v4.0 change that caught teams with older architectures off guard. Every user account accessing the environment requires multi-factor, not just administrative accounts. If a support agent can reach cardholder data with a password alone, that is a gap.
Service account discipline
Service accounts and application identities cannot be used interactively by humans. If a human logs in as the application account, it is a finding. Service account credentials are managed, rotated, and restricted from interactive use. v4.0 raised the bar on service account governance significantly.
Requirement 10: log access and watch for trouble
Every action in the Cardholder Data Environment has to be logged. Who did what, when, and from where. Logs are protected against tampering, retained for at least a year, and reviewed daily for anomalies. Automated review is effectively required at any meaningful volume, because manual daily review does not scale.
Where teams fail the PCI assessment
Four patterns dominate.
Shared accounts inherited from older architecture. Payment switches, mainframe terminals, and legacy systems often have operational accounts that multiple people use. Every assessment flags these. The remediation is either to modernize the system, add a gateway that forces a unique identification before the shared credential is applied, or document a compensating control that meets the same objective.
Stale service accounts. Service accounts that have been around for five years, owned by nobody in particular, with passwords that rotate every 90 days and end up in an unmanaged password vault. v4.0 expects service account use to be monitored and for deviations to trigger alerts.
Multi-factor only at the perimeter. The VPN requires multi-factor. Once inside the VPN, a lot of the environment is accessible with just a password. That was acceptable under earlier versions of PCI. Under v4.0, multi-factor has to be enforced closer to the data, not just at the edge.
Scope expansion from shared infrastructure. A shared monitoring tool that pulls logs from the environment has to meet environment controls, including the access controls. A shared identity provider that authenticates environment users has to meet environment controls. Teams often under-scope and then discover additional systems in scope when the Qualified Security Assessor starts work.
The executive playbook
Treat the environment as an enclave, not a network segment
A flat network with a cardholder subnet is hard to secure. An architecturally distinct environment with its own identity, its own devices, and its own operations is much easier. That is the pattern I default to for clients with greenfield opportunities, and the pattern I migrate toward for existing environments when the remediation cost is manageable.
Unique identity for humans and for services
Every human has an account in the environment identity provider. Every service has an account that is inventoried, owned, rotated, and monitored. Service account use is restricted to automated processes. Interactive logins with service accounts are blocked technically, not just forbidden by policy.
Multi-factor at every layer
Perimeter multi-factor through VPN or Zero Trust Network Access is the first layer. Application-level multi-factor on the administrative consoles is the second. Step-up authentication for privileged actions is the third. A compromised first factor does not grant continued access into the environment.
Just-in-time elevation for administrative work
Standing administrative rights in the environment are a liability. Privileged access is requested, approved, time-boxed, and logged. This meets the v4.0 emphasis on limiting privileged access, and it produces evidence that pre-populates the assessor's sample requests.
Continuous log aggregation with automated analysis
Logs go to a protected log store. Automated rules detect anomalies like failed multi-factor followed by success from a new location, service account interactive use, or privileged commands outside of an approved window. Daily log review becomes an automated job plus a human sign-off on alerts that fired.
Access reviews on a tighter cadence
Quarterly for the full user population, monthly for the privileged population inside the environment. Reviews are conducted by named owners, captured with evidence, and result in documented changes or documented retention decisions. The assessor's sample request for user access reviews lands on a fully populated system.
Adjustments you may still need for v4.0
If you certified under v3.2.1 and your next assessment is under v4.0, a few items likely need attention. Targeted risk analyses for any requirement where you use customized validation. Stronger authentication on the environment application layer, not just the perimeter. Service account governance that goes beyond password rotation. Phishing-resistant multi-factor for the administrative population, which is increasingly what assessors want to see even where it is not strictly required.
Where to go from here
If your next assessment is within the year and you are concerned about the v4.0 changes, the Hardening Sprint focuses on environment access controls and the governance instrumentation that pre-populates an assessment with evidence. For organizations new to PCI and building their first environment, the Governance Buildout covers the full architecture, identity plane, and control set from scratch.