PCI DSS 7.2.4: All user accounts and related access privileges, including third-party/vendor accounts
PCI DSS v4.0.1 control 7.2.4: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 7.2.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know › Section 7.2
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:
- At least once every six months.
- To ensure user accounts and access remain appropriate based on job function.
- Any inappropriate access is addressed.
- Management acknowledges that access remains appropriate.
Summary
Review every user account and its access at least twice a year, fix what is no longer appropriate, and have management sign that it is.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 7.2.4.a | Examine policies and procedures to verify they define processes to review all user accounts and related access privileges, including third-party/vendor accounts, in accordance with all elements specified in this requirement. |
| 7.2.4.b | Interview responsible personnel and examine documented results of periodic reviews of user accounts to verify that all the results are in accordance with all elements specified in this requirement. |
The control that keeps 7.2.1 and 7.2.2 true over time, and one of the more demanding in Requirement 7 because it has four separate elements and an explicit cadence. Third-party and vendor accounts are named, which is deliberate: they are the ones nobody owns internally. Note the fourth bullet: management acknowledges the access remains appropriate, so a review performed by an administrator and never signed off does not meet it. 7.2.4.a examines the policy for all four elements; 7.2.4.b interviews and examines documentation to verify the reviews happen.
What to prepare
- The review records, dated, showing accounts and privileges examined at least every six months.
- The management acknowledgement for each review, identifiable as such.
- Evidence that inappropriate access found was actually removed, with dates.
- The list of third-party and vendor accounts, included in the same review.
How to implement it
1. Give each system an accountable reviewer. A central list reviewed by IT tests whether accounts exist; a list reviewed by the manager who owns the function tests whether the access is appropriate, which is what the requirement asks.
2. Include the accounts nobody thinks of as users. Vendor support logins, integration accounts and break-glass credentials are in scope and are the ones most likely to have outlived their purpose.
3. Record the removals as part of the review. The third element is that inappropriate access is addressed, so a review that identifies problems and hands them to a queue is only half the evidence.
4. Make the acknowledgement explicit. A signature, an approval in a workflow tool, or a dated email. A spreadsheet with no sign-off satisfies the first three elements and fails the fourth.
Where this commonly fails
- Reviewing accounts but not the privileges attached to them, which misses accumulated access after a role change.
- Third-party and vendor accounts excluded because they belong to a supplier.
- A review completed with findings that were never actioned, so the record shows the problem and not the fix.
- Annual reviews where the requirement says at least once every six months.
Related controls
Others in section 7.2:
| Control | What it requires |
|---|---|
| 7.2.1 | An access control model is defined and includes granting access… |
| 7.2.2 | Access is assigned to users, including privileged users, based… |
| 7.2.3 | Required privileges are approved by authorized personnel |
| 7.2.5 | All application and system accounts and related access privileges are assigned and managed… |
| 7.2.5.1 | All access by application and system accounts and related access privileges are reviewed… |
| 7.2.6 | All user access to query repositories of stored cardholder data is restricted… |
← 7.2.3 · All controls · 7.2.5 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.