PCI DSS 7.2.1: An access control model is defined and includes granting access
PCI DSS v4.0.1 control 7.2.1: 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
An access control model is defined and includes granting access as follows:
- Appropriate access depending on the entity’s business and access needs.
- Access to system components and data resources that is based on users’ job classification and functions.
- The least privileges required (for example, user, administrator) to perform a job function.
Summary
Define, in writing, how access is decided in your organisation: by role and business need, with the least privilege that lets someone do their job.
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.1.a | Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement. |
| 7.2.1.b | Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement. |
This is the model; 7.2.2 is the assignment of actual access against it. The distinction matters because the two fail differently: an entity can hand out access carefully and still fail 7.2.1 because no written model says what "appropriate" means, and it can have an elegant model that nobody follows. 7.2.1.a examines the documented model; 7.2.1.b interviews management to verify it is as described, so the model has to be one the people running it can describe without reading it.
What to prepare
- The written access control model: the roles, what each is entitled to, and the approval route.
- Job classifications and the access each maps to.
- The reasoning for privileged roles, showing least privilege was applied rather than assumed.
How to implement it
1. Write the model around jobs, not around people. A model expressed as named individuals cannot survive someone changing role, and it gives the assessor nothing to test the assignments against.
2. Say what least privilege means for each role concretely. "Minimum necessary" repeated in every row is not a model. Which systems, which data, read or write: that is what makes 7.2.2 checkable.
3. Cover privileged and service accounts in the model. They are where the interesting access is, and they are most often outside the role structure because they were created during an incident and kept.
4. Make the approval route part of the model. Who can grant a role is as much a part of access control as what the role can do, and it is the part that decays first.
Where this commonly fails
- A model that exists only as the current state of the identity system, so it documents what happened rather than what is intended.
- Roles so broad that everyone in engineering has the same access, which makes least privilege undemonstrable.
- Service accounts and integrations outside the model entirely.
- Management unable to describe the model in interview, which is exactly what 7.2.1.b tests.
Related controls
Others in section 7.2:
| Control | What it requires |
|---|---|
| 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.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.1.2 · All controls · 7.2.2 →
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.