NSCs Between Trusted and Untrusted Networks

PCI DSS requires you to place network security controls (NSCs), such as firewalls, cloud security groups, or equivalent controls, at every boundary where a trusted network connects to an untrusted network, so traffic is explicitly controlled and monitored. To operationalize Requirement 1.4.1, you must identify all trust boundaries, implement NSCs at each boundary, and keep audit-ready evidence that the controls exist, are configured correctly, and are in scope. (PCI DSS v4.0.1 Requirement 1.4.1)

Key takeaways:

• Define and document “trusted vs. untrusted” for your environment, then map every boundary where they meet. (PCI DSS v4.0.1 Requirement 1.4.1)
• Implement NSCs at each boundary and enforce deny-by-default with explicitly approved inbound and outbound flows. (PCI DSS v4.0.1 Requirement 1.4.1)
• Retain evidence that proves placement, configuration intent, and operational state (diagrams, rulesets, change records, and reviews). (PCI DSS v4.0.1 Requirement 1.4.1)

“NSCs between trusted and untrusted networks” is a boundary control requirement. Auditors and QSAs tend to treat it as foundational because it determines whether your cardholder data environment (CDE) and connected systems are meaningfully segmented from the internet and other higher-risk networks.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate the sentence into three operational questions: (1) What do we call “trusted” and “untrusted” in our environment, including cloud and third-party connectivity? (2) Where are the boundaries, including overlooked paths like VPNs, remote admin tooling, and SaaS integrations? (3) What evidence proves the control is implemented at each boundary, not “in principle”?

This page focuses on PCI DSS v4.0.1 Requirement 1.4.1 and is written for teams that need to execute quickly: inventory boundaries, implement controls, and produce evidence that survives sampling. The goal is not a perfect network redesign; it’s an auditable, risk-reducing set of boundary controls with clear ownership, change discipline, and proof. (PCI DSS v4.0.1 Requirement 1.4.1)

Regulatory text

Requirement (excerpt): “NSCs are implemented between trusted and untrusted networks.” (PCI DSS v4.0.1 Requirement 1.4.1)

What the operator must do:
You must ensure that any connection point where a trusted network connects to an untrusted network is protected by network security controls that control traffic flow. In practice, that means you identify the boundary, place an NSC at that boundary (or implement an equivalent enforced control at that boundary), and configure it so only explicitly authorized traffic is permitted. Then you maintain evidence proving the boundary exists, the NSC is in place, and it is operating as intended. (PCI DSS v4.0.1 Requirement 1.4.1)

Plain-English interpretation

• Trusted network: network zones you treat as “inside” your security perimeter (for example, corporate LAN segments, CDE segments, internal VPCs/VNETs). Your definitions must be explicit and consistent in diagrams and scoping.
• Untrusted network: networks outside your control or with materially higher risk, most commonly the public internet, but also guest Wi‑Fi, partner networks, and some third-party connections depending on your model.
• NSCs: controls that enforce network traffic rules at the boundary. Depending on architecture, this can include firewalls, cloud security groups/NACLs, WAFs for relevant paths, routing controls with enforcement, or other mechanisms that actually restrict flows (not just observe them). The key is enforcement at the boundary. (PCI DSS v4.0.1 Requirement 1.4.1)

Who it applies to (entity and operational context)

Applies to any organization in PCI DSS scope, including:

• Merchants that store, process, or transmit cardholder data, or that have CDE-connected systems. (PCI DSS v4.0.1 Requirement 1.4.1)
• Service providers offering services that can impact the security of cardholder data environments. (PCI DSS v4.0.1 Requirement 1.4.1)

Operational contexts where this requirement becomes “exam-critical”:

• Internet-facing e-commerce and payment pages (CDE adjacency often hides in “supporting systems”).
• Hybrid networks (on-prem + cloud) with multiple ingress/egress paths.
• Remote access patterns (VPN, ZTNA, bastions) where the “untrusted” side is the user’s network.
• Third-party connectivity (MPLS, site-to-site VPN, partner API tunnels) that bypasses your normal internet edge.

What you actually need to do (step-by-step)

Step 1: Declare trust zones and criteria (write it down)

1. Define what qualifies a network as trusted (ownership, authentication requirements, endpoint posture, monitoring expectations).
2. Define what qualifies as untrusted (internet, unknown endpoints, external networks, guest segments).
3. Record these definitions in your network security standard or scoping methodology so diagrams and control narratives align. (PCI DSS v4.0.1 Requirement 1.4.1)

Deliverable: “Trusted/Untrusted Network Classification” section in a security standard, plus owner and approval.

Step 2: Map every boundary where trusted meets untrusted

Build (or refresh) a boundary inventory. Include:

• Internet ingress/egress for on-prem and cloud.
• Cloud: VPC/VNET internet gateways, NAT gateways, load balancers, public IPs.
• Remote access entry points: VPN concentrators, ZTNA gateways, bastion hosts.
• Third-party tunnels: site-to-site VPNs, direct connections, partner network peering.
• “Shadow” paths: temporary firewall rules, emergency access paths, vendor support tunnels.

Use a table so you can prove completeness during an assessment.

Boundary inventory template (minimum columns):

• Boundary ID / name
• Trusted zone(s)
• Untrusted zone(s)
• NSC control point (device/service name)
• Enforcement mechanism (ruleset/policy)
• Traffic allowed (high-level)
• Owner (team + individual)
• Evidence location (config export, screenshot set, repo path)
• Change control reference (ticketing system/process) (PCI DSS v4.0.1 Requirement 1.4.1)

Step 3: Implement NSCs at each boundary (or prove equivalence)

For each boundary, confirm you have an enforcing control in-line (or functionally equivalent at the boundary). Practical patterns:

• On-prem edge: perimeter firewall pair with explicit inbound/outbound rules.
• Cloud edge: security groups/NACLs plus centralized firewall service where required by architecture; ensure rules are attached to the correct subnets/ENIs and not just defined.
• DMZ model: NSC between internet and DMZ, and separate NSC between DMZ and trusted internal networks if both boundaries exist.
• Remote admin: NSC gating admin networks from untrusted origin, then restrict admin-to-CDE flows separately.

Implementation expectations you can operationalize:

• Start from deny-by-default at the boundary and add exceptions through change control.
• Explicitly control outbound as well as inbound where feasible; outbound gaps are a common path for data exfiltration and C2 traffic.
• Avoid “any/any” rules; if unavoidable temporarily, time-box them and track them as exceptions with compensating monitoring and approval. (PCI DSS v4.0.1 Requirement 1.4.1)

Step 4: Validate the control works (don’t rely on diagrams)

You need evidence the NSC actually enforces the boundary policy.

• Perform rule review with the system owner and application owner.
• Test representative flows: allowed traffic succeeds; disallowed traffic fails.
• Confirm logging/telemetry exists for boundary decisions (accept/deny) to support investigations and audit sampling. (PCI DSS v4.0.1 Requirement 1.4.1)

Step 5: Put the boundary under operational governance

Make the control sustainable:

• Assign ownership for each boundary NSC (primary and backup).
• Require change tickets for ruleset modifications, with business justification and approval.
• Maintain a periodic review cadence for boundary rules and boundary inventory (set a cadence your team can meet consistently). (PCI DSS v4.0.1 Requirement 1.4.1)

Step 6: Make it audit-ready (package evidence by boundary)

QSAs test by sampling. Your job is to make any sample easy. For each boundary, create an “evidence packet” that contains:

• Diagram snippet showing the boundary and NSC placement
• Current ruleset export/screenshot
• Standard/strategy explaining trust model
• Recent change records
• Review evidence (attestation, meeting notes, or ticket approvals)
• Test evidence (connectivity test results or monitoring evidence) (PCI DSS v4.0.1 Requirement 1.4.1)

Where Daydream fits: Daydream is useful as the system of record to track each boundary as an auditable control object, link owners, attach configuration exports/screenshots, and keep a consistent evidence packet for sampling across on-prem, cloud, and third-party connections.

Required evidence and artifacts to retain

Keep artifacts that prove existence, placement, and operation:

Design and scope

• Network diagrams showing trusted zones, untrusted zones, and boundary control points
• Data flow diagrams for cardholder data and admin access paths
• Written definitions of trusted vs. untrusted for your environment (PCI DSS v4.0.1 Requirement 1.4.1)

Configuration and operation

• Firewall / security group / policy exports and the effective rules in force
• Object/group definitions referenced by rules (so “POS-SUBNETS” is not ambiguous)
• Logging configuration and example logs demonstrating allow/deny events
• Change management tickets and approvals for rule changes
• Evidence of periodic review of boundary rules and exceptions (PCI DSS v4.0.1 Requirement 1.4.1)

Validation

• Test plans and results for representative allowed/blocked flows
• Exception register entries for any temporary broad rules, with expiration and compensating controls (PCI DSS v4.0.1 Requirement 1.4.1)

Common exam/audit questions and hangups

Auditors/QSAs frequently press on:

• “Show me every internet connection from the CDE and connected systems.” If your boundary inventory is incomplete, you will spend the audit rebuilding it.
• “Where is the enforcement point?” A diagram that implies control is not enough; they will ask for effective rules and attachments/associations in cloud.
• “What do you mean by trusted?” If different teams define it differently, sampling will expose inconsistency.
• “How do you control outbound?” Many teams focus only on inbound; expect scrutiny of unrestricted egress from sensitive zones.
• “How do you prevent alternate paths?” VPNs, peering, or third-party tunnels that bypass the main edge often become findings. (PCI DSS v4.0.1 Requirement 1.4.1)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in practice	How to avoid it
Treating “internet edge firewall exists” as sufficient	Your environment may have multiple edges (cloud IGW, SaaS tunnels, remote access)	Maintain a boundary inventory and map controls per boundary, not per site. (PCI DSS v4.0.1 Requirement 1.4.1)
Ruleset sprawl with “any/any” and stale objects	Auditors can’t verify intent; attackers love broad rules	Enforce naming standards, expiration for temporary rules, and periodic rule review with owners. (PCI DSS v4.0.1 Requirement 1.4.1)
Cloud rules defined but not attached/effective	Existence of a policy artifact is not enforcement	Capture evidence of association (to ENIs/subnets/LBs) and effective rule evaluation. (PCI DSS v4.0.1 Requirement 1.4.1)
Ignoring outbound (egress)	Creates simple exfiltration paths	Require explicit egress allow lists from sensitive zones and document business justification. (PCI DSS v4.0.1 Requirement 1.4.1)
Missing third-party and remote access boundaries	Non-internet “untrusted” paths still count	Include site-to-site VPNs, partner networks, vendor support access, and admin tooling in the boundary inventory. (PCI DSS v4.0.1 Requirement 1.4.1)

Risk implications (why assessors care)

If NSCs are missing or poorly implemented at a trust boundary, you lose your ability to:

• Prevent direct access from untrusted networks into trusted zones.
• Constrain lateral movement from less trusted segments into sensitive environments.
• Prove segmentation and scope boundaries during PCI assessments.
• Detect and investigate suspicious traffic patterns with reliable boundary logs. (PCI DSS v4.0.1 Requirement 1.4.1)

This requirement is “medium severity” in many internal risk models because the control is foundational. A weakness here can turn a limited incident into an environment-wide compromise because the boundary is where containment starts. (PCI DSS v4.0.1 Requirement 1.4.1)

Practical execution plan (30/60/90-day)

Use these phases as an operator’s plan; adjust sequencing based on architecture and change windows.

First 30 days: Get complete and get explicit

• Publish your trusted/untrusted definitions and get sign-off from Security and Network/Cloud owners. (PCI DSS v4.0.1 Requirement 1.4.1)
• Build the boundary inventory and confirm it covers on-prem, cloud, remote access, and third-party tunnels.
• Identify “known bads” for immediate remediation: public exposure where it shouldn’t exist, overly permissive inbound, and unmanaged egress.
• Stand up a central evidence folder structure (or Daydream workspace) per boundary.

Days 31–60: Fix the highest-risk boundaries and stabilize change

• Implement or tighten NSCs for the most exposed boundaries first (internet-facing, remote access into admin networks, any CDE-adjacent connectivity). (PCI DSS v4.0.1 Requirement 1.4.1)
• Convert broad rules into explicit rules with owners and ticket references.
• Turn on or standardize boundary logging and confirm logs are retrievable for audit sampling.
• Run validation tests and store results with each boundary’s evidence packet.

Days 61–90: Make it repeatable and auditable

• Establish a recurring review for boundary rules and exceptions; document outcomes and actions taken. (PCI DSS v4.0.1 Requirement 1.4.1)
• Add a pre-change checklist for NSC modifications (business justification, scope impact, rollback, testing plan).
• Perform an internal “mock sampling” exercise: pick boundaries at random and verify the evidence packet can answer an assessor’s questions in one sitting.
• Close documentation gaps in diagrams and data flows so the story matches the configs. (PCI DSS v4.0.1 Requirement 1.4.1)

Frequently Asked Questions

Does “untrusted network” only mean the public internet?

No. The requirement is about boundaries between networks with different trust assumptions. The internet is the obvious example, but partner networks, guest networks, and some third-party connections can be “untrusted” depending on your model. (PCI DSS v4.0.1 Requirement 1.4.1)

Are cloud security groups considered NSCs?

They can be, if they are the enforcing control between trusted and untrusted networks and you can prove they are effective (attached to the right assets, deny-by-default, and managed under change control). Keep exports and association evidence. (PCI DSS v4.0.1 Requirement 1.4.1)

What evidence is most likely to be sampled by a QSA?

Expect network diagrams, current effective rulesets, and change/review records that show the rules are governed. If you cannot show the effective enforcement at the boundary, diagrams alone will not carry the control. (PCI DSS v4.0.1 Requirement 1.4.1)

We have a single perimeter firewall. Are we done?

Only if that firewall is actually between every trusted/untrusted boundary in your environment. Hybrid architectures often have additional edges (cloud gateways, VPNs, peering, third-party tunnels) that require their own boundary enforcement or a clearly documented equivalent. (PCI DSS v4.0.1 Requirement 1.4.1)

How do we handle temporary broad firewall rules during incidents?

Track them as exceptions with explicit approver, reason, and a defined expiration, then remove or narrow them through the normal change process. Store the exception record with the boundary evidence packet. (PCI DSS v4.0.1 Requirement 1.4.1)

What’s the fastest way to operationalize this across multiple teams?

Treat each boundary as a control “unit” with one named owner, one evidence packet, and one change process. A GRC system like Daydream helps you standardize the inventory and evidence so sampling doesn’t turn into a distributed scramble. (PCI DSS v4.0.1 Requirement 1.4.1)