PCI DSS 7.3.3: The access control system(s) is set to “deny all” by default
PCI DSS v4.0.1 control 7.3.3: 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 set to “deny all” by default.
Summary
The access control system denies by default, so anything not explicitly allowed is refused.
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.3 | Examine vendor documentation and system settings to verify that the access control system(s) is set to “deny all” by default. |
The fail-closed principle, stated in one sentence, and the same idea as the explicit deny in 1.3.1 applied to access rather than to traffic. Default-deny is what makes the rest of Requirement 7 meaningful: without it, a permission nobody thought to grant may still be available, so least privilege becomes a description of what was configured rather than a limit on what is possible. The procedure examines vendor documentation and system settings, which is worth noting because most access control systems deny by default already. The work is usually confirming it for each system rather than changing anything, and finding the one that does not.
What to prepare
- The list of access control systems, the same list as 7.3.2.
- Vendor documentation stating the default behaviour of each.
- Configuration evidence that the default has not been changed.
- Any system that permits by default, with what compensates for it.
How to implement it
1. Check each system rather than assuming the platform default. The claim is easy to make for the environment as a whole and is answered per system.
2. Watch for broad allow rules that recreate permit-by-default. A deny-all base with a rule granting everyone access to everything is deny-all in configuration only.
3. Look at the legacy applications. Older systems are the ones most likely to grant access on account creation and restrict afterwards.
4. Record the check. It is a quick confirmation per system, and having it written is the difference between evidence and an assertion.
Where this commonly fails
- Assumed rather than verified, because most systems do deny by default and one does not.
- Deny-all undermined by an overly broad allow rule.
- Legacy or standalone applications that grant access on creation.
- The default changed during troubleshooting and never restored.
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.2 | The access control system(s) is configured to enforce permissions assigned to individuals… |
← 7.3.2 · All controls · 8.1.1 →
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.