PCI DSS 7.2.5: All application and system accounts and related access privileges are assigned and managed
PCI DSS v4.0.1 control 7.2.5: 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 application and system accounts and related access privileges are assigned and managed as follows:
- Based on the least privileges necessary for the operability of the system or application.
- Access is limited to the systems, applications, or processes that specifically require their use.
Summary
Application and system accounts get the least privilege the system needs, limited to what it actually touches.
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.a | Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement. |
| 7.2.5.b | Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement. |
The service-account counterpart to 7.2.2, and it matters more than the human one because these accounts are typically the most privileged and the least reviewed. Two elements: least privilege for the operability of the system, and access limited to the systems, applications and processes that specifically require it. Its partners are 8.6.1, which governs whether such an account may be used interactively, and 7.2.5.1, which requires the privileges to be reviewed periodically. The default failure is an account provisioned with broad rights during setup because narrowing them was harder than making it work.
What to prepare
- An inventory of application and system accounts with their privileges.
- The justification for each privilege, tied to what the system does.
- Evidence of periodic review, which 7.2.5.1 requires.
How to implement it
1. Start from what the application calls. Privileges granted from the documentation are usually broader than the code needs; privileges derived from actual operations are defensible and smaller.
2. Give each integration its own account. One shared service identity across several systems makes least privilege impossible to state, because its rights are the union of every consumer.
3. Scope to resources, not just actions. Read access to one bucket or one schema is least privilege; read access to everything is a role name that sounds like it.
4. Review them with the human accounts. 7.2.4 covers users; service accounts have their own cadence and are the ones nobody owns after the person who created them leaves.
Where this commonly fails
- A database service account with owner or superuser rights because setup was easier that way.
- One integration account shared by several systems.
- Cloud roles granted at the account level rather than scoped to the resources used.
- Never reviewed, because reviews are aimed at people.
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.4 | All user accounts and related access privileges, including third-party/vendor accounts… |
| 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.4 · All controls · 7.2.5.1 →
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.