We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

PCI DSS v4.0.1 · Requirement 7 of 12

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

Requirement 7 is the access-model requirement: who may see what, and why. v4 added the discipline that was always implied — semi-annual reviews of all user accounts and explicit governance of application/system account privileges.

Reviewed by Abhay Singh, PCI SSC-qualified QSA professional · CyberSigma is a PCI SSC-listed QSA company · Part of the Requirement 1–12 series

The controls that decide your assessment

7.2.1–7.2.2
Access model on least privilege

An access-control model defines access needs per role; assignments grant the least privilege necessary for the job.

7.2.3
Privileges require documented approval

Required privileges are approved by authorised personnel — the paper trail behind every grant.

7.2.4
All user accounts reviewed every six months

New in v4: every user account and its privileges reviewed at least semi-annually, with remediation of inappropriate access. Fully effective 31 March 2025.

7.2.5
Application/system account privileges governed

Service-account privileges are assigned least-privilege and reviewed at a TRA-defined frequency (7.2.5.1) — new in v4.

7.3.1–7.3.3
Access control system, default deny

An access-control system covers all components, enforces per-role permissions, and is set to deny-all by default.

Control numbers reference PCI DSS v4.0.1 (June 2024). Verify wording against the standard itself — PCI SSC document library.

Where programmes actually fail

No semi-annual access review

The single most common v4 gap in year one: 7.2.4 needs evidence of the review itself — account listings, reviewer sign-off, and the removals that resulted.

Access via ever-growing AD groups

Nested groups accumulated over years make least-privilege unprovable. The assessor asks "why does this role have this?" — the model must answer.

Service accounts with domain admin

7.2.5 exists precisely for the integration account granted DA in 2019. Least privilege applies to non-humans too.

Evidence a QSA accepts

A policy document proves intent; configuration proves control. Bring these to the assessment:

  • Documented access-control model mapping roles to data/system needs
  • Semi-annual access-review records with actions taken (7.2.4)
  • Approval trail for privilege grants (tickets, forms)
  • Service-account inventory with privilege justification (7.2.5)
  • Access-control system configuration showing default deny

Requirement 7 FAQ

How often must user access be reviewed?

At least once every six months for all user accounts and related privileges, including third-party/vendor accounts (7.2.4), with documented remediation.

Does Requirement 7 cover service accounts?

Yes — 7.2.5 requires application and system accounts to follow least privilege, with periodic reviews at a frequency defined by targeted risk analysis (7.2.5.1).

Is deny-by-default really testable?

Assessors verify the access-control system’s default disposition (7.3.3) in configuration — "everyone can read unless blocked" fails it.

← Requirement 6: Secure Development & PatchingRequirement 8: Identity & Authentication

Requirement 7 in your environment

A PCI SSC-listed QSA firm can tell you in one session whether your controls will survive assessment — before the assessment.