PCI DSS 7.3.2: The access control system(s) is configured to enforce permissions assigned to individuals
PCI DSS v4.0.1 control 7.3.2: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 7.3.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know › Section 7.3
The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function.
Summary
The access control system enforces the permissions, so access depends on configuration rather than on people following policy.
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.3.2 | Examine vendor documentation and system settings to verify that the access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. |
Section 7.3 is about the machinery, where 7.2 is about the access itself. 7.2 asks whether the right people have the right privileges; 7.3 asks whether something enforces that. The distinction matters because an entity can have an exemplary access model documented in 7.2.1 and approved under 7.2.3, and still fail here if the systems do not actually implement it. The wording covers individuals, applications and systems, so the enforcement has to reach service accounts too, which is a common gap: user access is managed through a directory with roles while application accounts are granted directly on each system. The procedure examines vendor documentation and system settings, so it is answered by configuration rather than by policy.
What to prepare
- The list of access control systems in use across the environment.
- Configuration showing permissions enforced by job classification and function.
- How application and system accounts are covered by the same enforcement.
- Vendor documentation for the mechanisms relied on.
How to implement it
1. Enforce through roles, not individual grants. Job classification and function is the wording, and per-person permissions drift away from it immediately.
2. Cover the systems with their own access model. Anything not integrated with the central directory enforces its own permissions and needs checking separately.
3. Include application and system accounts. They are named in the requirement and are usually the population managed least systematically.
4. Compare enforcement against the model. The point of this control is that the two agree, and nothing checks that unless someone does.
Where this commonly fails
- A documented role model that no system actually enforces.
- Roles used for users and direct grants used for service accounts.
- Standalone applications with their own permissions outside the access control system.
- Permissions assigned per person, so job classification exists only on paper.
Related controls
Others in section 7.3:
| Control | What it requires |
|---|---|
| 7.3.1 | An access control system(s) is in place that restricts access based on a user’s need to know… |
| 7.3.3 | The access control system(s) is set to “deny all” by default |
← 7.3.1 · All controls · 7.3.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.