PCI DSS 7.3.1: An access control system(s) is in place that restricts access based on a user’s need to know
PCI DSS v4.0.1 control 7.3.1: 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
An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components.
Summary
A real access control system enforces need-to-know across every system component, rather than access being decided case by case.
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.1 | Examine vendor documentation and system settings to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components. |
Section 7.2 defines the model and the assignments; section 7.3 requires a system that enforces them. The distinction matters because an entity can have a correct model at 7.2.1 and correct assignments at 7.2.2 and still fail here, if enforcement depends on people remembering rather than on a mechanism. The phrase to plan around is covers all system components: one system that enforces access on the application while a database, a file share or a cloud console is governed separately is the shape this control is testing for.
What to prepare
- The access control mechanism per system component, and how each is administered.
- Evidence the mechanism enforces the model rather than merely recording it.
- Coverage evidence across every in-scope component, which is what the requirement names.
How to implement it
1. Centralise where you can. One identity provider enforcing across components is far easier to evidence than a dozen local mechanisms, and it makes 7.2.4 reviews tractable.
2. Find the components governed by convention. A shared drive, a reporting tool or a cloud storage bucket often has permissions nobody manages, and each is a system component.
3. Default to deny. An access control system that permits unless denied cannot demonstrate need-to-know, which is what section 7.3 continues into.
4. Check the administration path. A system that enforces access correctly while anyone can change its rules is enforcing nothing durable.
Where this commonly fails
- Application access controlled and database access shared among the engineering team.
- Cloud storage and file shares outside any managed access control.
- A mechanism that records permissions without enforcing them.
- Coverage claimed from the identity provider while local accounts bypass it.
Related controls
Others in section 7.3:
| Control | What it requires |
|---|---|
| 7.3.2 | The access control system(s) is configured to enforce permissions assigned to individuals… |
| 7.3.3 | The access control system(s) is set to “deny all” by default |
← 7.2.6 · All controls · 7.3.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.