PCI DSS 1.3.2: Outbound traffic from the CDE is restricted
PCI DSS v4.0.1 control 1.3.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.3.
Requirement 1: Install and Maintain Network Security Controls › Section 1.3
Outbound traffic from the CDE is restricted as follows:
- To only traffic that is necessary.
- All other traffic is specifically denied.
Summary
Traffic leaving the cardholder data environment is restricted to what is necessary, and everything else is denied.
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 | |
|---|---|
| 1.3.2.a | Examine configuration standards for NSCs to verify that they define restricting outbound traffic from the CDE in accordance with all elements specified in this requirement. |
| 1.3.2.b | Examine configurations of NSCs to verify that outbound traffic from the CDE is restricted in accordance with all elements specified in this requirement. |
The mirror of 1.3.1 and the one entities skip, because inbound restriction feels like security and outbound feels like an obstacle. It is the control that matters most after a compromise: an attacker inside the CDE needs a path out to send data anywhere, and unrestricted egress gives them one. The same two words do the work: necessary means each allowance has a justification, specifically denied means an explicit default-deny rather than an absence of matching rules. 1.3.2.a examines the configuration standards, 1.3.2.b the actual configurations.
What to prepare
- The outbound ruleset for each NSC at a CDE boundary.
- A justification per outbound allowance, naming what needs it.
- Evidence of the explicit deny, not merely the absence of a permit.
How to implement it
1. Enumerate what genuinely needs to leave. Payment provider endpoints, update and package repositories, time servers, log shipping and monitoring. That list is usually short, and everything not on it is the finding.
2. Use a proxy or an allowlist for updates. Package and OS updates are the honest reason egress rules get widened to "any", and an internal mirror or an explicit destination list removes that argument.
3. Deny DNS to the internet. Direct outbound DNS from CDE hosts is both a common allowance and a well-known exfiltration channel; forcing resolution through an internal resolver closes it and improves logging.
4. Log the denies. An outbound deny that fires is one of the highest-signal events you can feed the daily review at 10.4.1.
Where this commonly fails
- Inbound tightly controlled and outbound left as allow-any, which is the usual shape.
- Broad egress kept "for updates", where a mirror or an allowlist would do.
- Direct outbound DNS permitted from CDE systems.
- Rules that permit nothing relied on as a deny, so the next change silently opens a path.
Related controls
Others in section 1.3:
| Control | What it requires |
|---|---|
| 1.3.1 | Inbound traffic to the CDE is restricted… |
| 1.3.3 | NSCs are installed between all wireless networks and the CDE… |
← 1.3.1 · All controls · 1.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.