PCI DSS 7.2.2: Access is assigned to users, including privileged users, based
PCI DSS v4.0.1 control 7.2.2: 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
Access is assigned to users, including privileged users, based on:
- Job classification and function.
- Least privileges necessary to perform job responsibilities.
Summary
The access people actually hold matches their job and is the least they need, privileged accounts included.
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.2.a | Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement. |
| 7.2.2.b | Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement. |
| 7.2.2.c | Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement. |
The assignment that 7.2.1's model describes. The two fail differently and are assessed together: a good model with careless assignments fails here, careful assignments with no written model fail there. Three procedures, and the third examines privileged users specifically. The phrase to plan around is least privileges necessary: not "appropriate", not "reasonable". Where an assessor sees a role that grants more than the job needs, the finding is here even if the model is sound. 7.2.4 then re-checks these assignments twice a year.
What to prepare
- The current access assignments per user, exportable rather than described.
- The mapping from job function to entitlement, from 7.2.1.
- The approval record for each privileged account.
- Evidence that access granted for a past role was removed when the role changed.
How to implement it
1. Assign through roles, not individually. Per-person grants cannot be reviewed meaningfully at 7.2.4, and they are how privilege accumulates after a transfer.
2. Look hardest at role changes, not leavers. Leavers are usually handled; someone moving from support to engineering typically gains the new access and keeps the old, and nothing in the joiner or leaver process catches it.
3. Justify each privileged account in writing. The third procedure examines them specifically, and "the team needs admin" is not a justification for four named individuals.
4. Prefer time-bounded elevation where the platform offers it. Standing privilege is what least-privilege is measured against, and elevation on request with an audit trail evidences both this control and Requirement 10.
Where this commonly fails
- Access that accumulated across role changes, which is the commonest single finding here.
- Administrator rights granted to a whole team because one task needed them.
- Service accounts assigned interactive privileges they never use.
- A model at 7.2.1 that the real assignments do not follow, so one control passes and this one does not.
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.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.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.1 · All controls · 7.2.3 →
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.