PCI DSS 7.2.5.1: All access by application and system accounts and related access privileges are reviewed
PCI DSS v4.0.1 control 7.2.5.1: the requirement in full, the 3 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 access by application and system accounts and related access privileges are reviewed as follows:
- Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
- The application/system access remains appropriate for the function being performed.
- Any inappropriate access is addressed.
- Management acknowledges that access remains appropriate.
Summary
Review what the application and system accounts can reach, on a frequency you have justified, and have management confirm it is still appropriate.
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.5.1.a | Examine policies and procedures to verify they define processes to review all application and system accounts and related access privileges in accordance with all elements specified in this requirement. |
| 7.2.5.1.b | Examine the entity’s targeted risk analysis for the frequency of periodic reviews of application and system accounts and related access privileges to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1. |
| 7.2.5.1.c | Interview responsible personnel and examine documented results of periodic reviews of system and application accounts and related privileges to verify that the reviews occur in accordance with all elements specified in this requirement. |
The service-account counterpart to the six-monthly user access review in 7.2.4, and the review entities most often skip entirely. Application and system accounts tend to be the most privileged and the longest-lived things in an environment: created for a project, granted broadly to make an integration work, and never revisited because no leaver process touches them. Four elements, and two are worth reading closely. The frequency comes from a targeted risk analysis under 12.3.1, making this the seventh control on that pattern alongside 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1, 11.3.1.1 and 12.10.4.1. And management acknowledges that access remains appropriate, which is a sign-off, not a technical exercise, so somebody has to be named to give it.
What to prepare
- The inventory of application and system accounts with their privileges.
- The targeted risk analysis defining the review frequency.
- Documented results of the reviews, which 7.2.5.1.c examines.
- Management acknowledgements, and the role that gives them.
How to implement it
1. Build the account inventory first. The review cannot be scoped without it, and these accounts are rarely in the same place as user accounts.
2. Give each account a named human owner. Reviewing a service account is impossible if nobody knows what it is for, and the owner is who answers that.
3. Show what was removed. "Any inappropriate access is addressed" is an element, and a review that finds nothing every cycle across accounts granted broadly at creation invites the question.
4. Keep the targeted risk analysis with the other six. One register makes the annual 12.3.1 review a single task.
Where this commonly fails
- The user access review performed and service accounts never reviewed at all.
- A frequency chosen with no targeted risk analysis behind it.
- Reviews performed with no management acknowledgement recorded, which is a named element.
- Accounts with no owner, so the review cannot judge whether access remains appropriate.
Related controls
This control refers to 12.3.1.
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.4 | All user accounts and related access privileges, including third-party/vendor accounts… |
| 7.2.5 | All application and system accounts and related access privileges are assigned and managed… |
| 7.2.6 | All user access to query repositories of stored cardholder data is restricted… |
← 7.2.5 · All controls · 7.2.6 →
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.