PCI DSS 1.4.4: System components that store cardholder data are not directly accessible from untrusted networks

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.

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 storing cardholder data is reachable directly from an untrusted network.

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 the requirement is about reachability rather than about filtering. 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 configuration standards, 1.4.4.b examines the 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; a rule blocking it is a control on top of an architecture that should not exist.

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.
  • Reachability confused with filtering, so a firewall rule is offered as evidence of inaccessibility.

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…

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.