PCI DSS 7.2.3: Required privileges are approved by authorized personnel
PCI DSS v4.0.1 control 7.2.3: 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
Required privileges are approved by authorized personnel.
Summary
Someone with the authority to do so has to approve each privilege before it is granted, and there has to be a record of it.
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.3.a | Examine policies and procedures to verify they define processes for approval of all privileges by authorized personnel. |
| 7.2.3.b | Examine user IDs and assigned privileges, and compare with documented approvals to verify that: • Documented approval exists for the assigned privileges. • The approval was by authorized personnel. • Specified privileges match the roles assigned to the individual. |
The paper trail that makes the rest of 7.2 checkable. 7.2.1 is how access is decided, 7.2.2 is what people actually hold, and 7.2.3 is the evidence that someone with authority agreed to it. Procedure 7.2.3.b tests three things at once, and they fail independently: that a documented approval exists, that the approver was authorised, and that the privileges match the role the person holds. The second is the one entities lose. Approvals frequently exist and were given by the requester's teammate, or by the IT administrator who then performed the change, which is a record of the work rather than an approval of it.
What to prepare
- The policy defining who may approve which privileges.
- Access request records for a sample of users, dated before the access was granted.
- The current privilege listing for those same users, so the two can be compared.
- The role definitions the approvals refer to.
How to implement it
1. Write down who is authorised to approve what. Without this the assessor cannot test the second element and neither can you. A short table of role to approver is enough.
2. Separate the approver from the implementer. The administrator who makes the change should not be the person who authorised it, and this is visible in any ticketing system as two names.
3. Approve the role, then grant the role. Approving individual permissions one at a time is what makes the third element fail, because privileges drift out of alignment with the role nobody re-approved.
4. Keep the record with the identity, not in an inbox. Approvals in email are approvals until the person leaves.
Where this commonly fails
- Approvals given by a peer or by the implementing administrator, so no authorised person approved.
- Access granted first and approved retrospectively when the assessment approaches.
- Privileges that no longer match the role, because the role changed and the grant did not.
- Elevated access approved verbally in an incident and never documented afterwards.
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.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.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.2 · All controls · 7.2.4 →
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.