PCI DSS Requirement 7: need-to-know access
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 2 min read · PCI DSS
Requirement 7 is about who should have access. Requirement 8 is about proving they are who they claim. Conflating the two is the most common structural mistake in PCI access control.
Authorisation, not authentication
Requirement 7 answers "should this person have access to this?" Requirement 8 answers "is this person who they say they are?" They are frequently merged into a single "access control" workstream, which causes evidence gaps — an assessor asking for the access control model does not want your MFA configuration.
Keeping them separate also clarifies ownership. Requirement 7 is largely a business and process question about roles and approvals; Requirement 8 is largely a technical identity question.
The access control model
Requirement 7.2.1 requires a defined access control model that grants access based on job classification and function, with least privilege as the operating principle, and a default of deny-all. Requirement 7.2.2 requires that access assignment is appropriate to the job function and privileges are the least required.
The practical implementation is role-based: define roles, define what each role may reach, assign people to roles, and document the approval by authorised personnel specifying the required privileges (7.2.3). Individual ad-hoc grants outside the model are where entitlement drift begins.
The six-monthly review
Requirement 7.2.4 requires all user accounts and related access privileges to be reviewed at least once every six months, confirming that access remains appropriate, that it corresponds to the user's job function, and that any inappropriate access is addressed. Management must acknowledge the review.
Requirement 7.2.5 extends the same logic to application and system accounts, with 7.2.5.1 requiring periodic review of their access at a frequency determined by a targeted risk analysis. Service accounts are usually the least reviewed and most over-privileged identities in an environment, so this is a meaningful addition rather than paperwork.
The evidence assessors want is not the list of who has access — it is proof the review happened: who performed it, when, what was found, what changed as a result, and management acknowledgement.
Common findings
- Access reviews performed as a spreadsheet export with no evidence of anyone actually reviewing it.
- Service and application accounts excluded from review entirely.
- Privileges granted for a project and never revoked — the classic accumulation pattern for long-tenured staff.
- A documented role model that does not match the access actually provisioned in the system.
- Break-glass and emergency accounts with standing access rather than time-bound, monitored elevation.