PCI DSS 1.4.4: Nothing that stores cardholder data, including a RAM disk used as persistent storage, is directly reachable from an untrusted network. Data held briefly in volatile memory for a transaction is outside it.
PCI DSS v4.0.1 control 1.4.4: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.4.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
Requirement 1: Install and Maintain Network Security Controls › Section 1.4
System components that store cardholder data are not directly accessible from untrusted networks.
Summary
Nothing that stores cardholder data, including a RAM disk used as persistent storage, is directly reachable from an untrusted network. Data held briefly in volatile memory for a transaction is outside it.
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.4.4.a | Examine the data-flow diagram and network diagram to verify that it is documented that system components storing cardholder data are not directly accessible from the untrusted networks. |
| 1.4.4.b | Examine configurations of NSCs to verify that controls are implemented such that system components storing cardholder data are not directly accessible from untrusted networks. |
The structural consequence of everything else in Requirement 1: not "protected from" but not directly accessible. A database on the CDE segment that is also bound to a public interface fails this even with a firewall in front of it filtering by source address, because any untrusted source the rule lets through can reach the store directly. In practice this is the control that forces a tier between the internet and the data: a web or application layer that talks to the store, with the store on a segment with no route from outside. 1.4.4.a examines the data-flow and network diagrams for a record that these components are not directly accessible, and 1.4.4.b examines the NSC configurations themselves.
What to prepare
- The list of components that store cardholder data, from 3.2.1.
- Network evidence that no route exists from an untrusted network to any of them.
- The NSC configurations enforcing it, per 1.4.1.
How to implement it
1. Check the interfaces, not just the rules. A datastore listening on a public interface is directly accessible unless an NSC blocks every untrusted source. A private interface removes the dependence on that one rule.
2. Look at the cloud defaults. Managed databases frequently offer public endpoints, and they are often left enabled because a private endpoint takes more setup. That toggle is this control.
3. Include the management paths. An administrative port reachable from outside makes the component directly accessible even if the data port is not.
4. Test from outside. The ASV scan at 11.3.2 already looks from there; reconcile its host list against your storage inventory and anything appearing in both is this finding.
Where this commonly fails
- A managed database with a public endpoint enabled and access restricted only by source IP.
- Backups or replicas in storage that is publicly addressable, while production is private.
- Administrative interfaces reachable from the internet.
- A firewall rule offered as evidence while the same store is still reachable another way, such as a public endpoint or a management port.
Related controls
Others in section 1.4:
| Control | What it requires |
|---|---|
| 1.4.1 | NSCs are implemented between trusted and untrusted networks |
| 1.4.2 | Inbound traffic from untrusted networks to trusted networks is restricted… |
| 1.4.3 | Anti-spoofing measures are implemented to detect and block forged source IP addresses… |
| 1.4.5 | The disclosure of internal IP addresses and routing information is limited to only authorized… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 1.4.3 · All controls · 1.4.5 →
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.