Network Routing Control

To meet the HITRUST network routing control requirement, you must implement network routing rules that prevent connections and data flows from violating your applications’ access control policy, and you must verify allowed traffic by checking both source and destination addresses before it is routed. This is enforced through explicit allow-list routing and filtering, not implicit trust. ¹

Key takeaways:

• Tie routing decisions to application access control policy, not “network convenience.” ¹
• Use positive source and destination address verification (allow-lists, anti-spoofing, route filtering) to block unauthorized flows. ¹
• Keep evidence that rules exist, are reviewed, and work as designed (configs, diagrams, test results, and change records). ¹

Network routing control is one of those requirements that looks “network-only” until you are in an assessment and the auditor asks a simple question: “How do you know traffic can’t reach an application in a way that bypasses the application’s access control policy?” HITRUST CSF v11 01.o expects you to answer that with concrete routing and filtering controls, plus proof they are implemented and maintained. ¹

Operationally, this requirement lands in the seams between teams: network engineering owns routers and firewalls; cloud teams own VPC/VNet routing and security groups; application owners define access control needs; IAM defines identity boundaries; GRC must map all of it to policy and evidence. If any seam is weak, routing becomes the backdoor: workloads can “talk around” intended segmentation, spoofed source addresses can be accepted, or overly broad routes can allow lateral movement.

This page translates the requirement into a buildable checklist: what systems it applies to, the routing patterns that pass audits, what to document, and how to stand up a review-and-test rhythm that survives staff turnover and infrastructure change.

Regulatory text

Requirement (HITRUST CSF v11 01.o): “Routing controls shall be implemented for networks to ensure that computer connections and information flows do not breach the access control policy of the business applications. Routing controls shall be based on positive source and destination address verification mechanisms.” ¹

Operator meaning: You must design routing so that (1) only authorized network paths exist to your applications and data stores, and (2) network devices validate that traffic is coming from and going to expected addresses before forwarding it. “Positive verification” means explicit allow rules and anti-spoofing checks, not just a default route and a hope that other layers catch it. ¹

Plain-English interpretation (what an assessor expects)

An assessor will look for three outcomes:

1. No policy bypass paths. If the access control policy says “only the app tier can reach the database,” routing and filtering must make any other path fail. That includes paths through peering, VPN, third-party connections, shared services networks, and cloud routing tables. ¹

2. Traffic is constrained by explicit rules. You should be able to point to explicit permitted flows (sources, destinations, ports/protocols) aligned to business needs, with “deny by default” behavior at key boundaries. ¹

3. Source/destination address verification exists. Controls must prevent spoofed or unexpected source/destination addresses from being routed (examples: ingress/egress filtering, uRPF, route filtering/prefix lists, security group allow-lists, firewall policies that match specific source subnets). ¹

Who it applies to

Entity scope: All organizations implementing HITRUST controls. ¹

Operational scope (where this shows up in real environments):

• On-prem networks: core/edge routers, internal routers, firewalls, segmentation gateways, VPN concentrators.
• Cloud networks: AWS route tables + security groups + NACLs; Azure route tables (UDRs) + NSGs; GCP routes + firewall rules; cloud transit hubs.
• Hybrid connectivity: site-to-site VPNs, direct connectivity circuits, cloud interconnects, SD-WAN overlays.
• Third-party connectivity: EDI links, partner VPNs, managed service provider access paths, SaaS private connections, payment processors, clearinghouses.
• High-risk zones: ePHI networks, production application subnets, administrative networks, logging/monitoring networks, backup networks.

If it can route packets to or from a business application handling sensitive data, it is in scope for routing control design and evidence. ¹

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

1) Map your “allowed flows” to application access control policy

• Identify each in-scope application and its required network dependencies (app-to-db, app-to-queue, admin-to-bastion, outbound to specific third parties).
• Convert that into a flow matrix: source zone/subnet → destination zone/subnet, ports/protocols, purpose, owner, and approval basis.
• Tie each flow back to the application’s access control policy statement (even if that policy is captured in standards or architecture documents). ¹

Deliverable: Approved network/data flow matrix for in-scope apps.

2) Enforce segmentation at routing boundaries (don’t rely on “flat network” assumptions)

• Define trust zones (examples: internet, DMZ, app tier, data tier, management, third-party, user networks).
• Ensure routes between zones are controlled by a device or control plane that can enforce allow/deny (firewall, cloud firewall policies, segmentation gateway, security groups/NSGs combined with routes).
• Avoid uncontrolled transitive routing (A peers with B, B peers with C, and now A can reach C without intended inspection). Document and control transit. ¹

Practical check: If you removed all firewall rules, could routing alone still move packets between sensitive zones? If yes, you probably have a bypass risk.

3) Implement positive source and destination verification

“Positive verification” should be visible in config and testable:

On-prem patterns

• Ingress/egress filtering at zone boundaries: only allow expected source prefixes from each interface/zone.
• Anti-spoofing controls such as uRPF (where appropriate) or strict ACLs on ingress interfaces.
• Route filtering using prefix lists/route-maps so only approved prefixes are advertised/accepted across routing domains.
• Default-deny ACLs with explicit allow entries for required flows. ¹

Cloud patterns

• Route tables that do not create broad reachability across all subnets by default.
• Security groups/NSGs written as allow-lists (source subnet/security group → destination, limited ports).
• NACLs/network firewall policies at subnet boundaries for additional source/destination constraints where needed.
• Peering/transit restrictions (limit propagated routes; avoid “all-to-all” route propagation). ¹

4) Validate “no breach” with testing you can show

• Run controlled tests from representative source networks (user subnet, third-party VPN subnet, workload subnet) attempting to reach protected destinations.
• Validate that only approved flows succeed and all others fail (connection refused/timeouts at the expected enforcement point).
• Capture evidence: test scripts/commands, timestamps, source/destination IPs, and logs from the enforcing control (firewall logs, VPC flow logs, router ACL hits). ¹

5) Put routing under change control with periodic review

Auditors often fail teams here because the controls exist, but nobody can show they remain correct.

Minimum operating loop:

• Change management: ticketed changes for routing tables, ACLs, firewall rules, security groups, peering routes, BGP announcements.
• Review cadence: scheduled review of the flow matrix vs. actual rules (especially after app releases, network redesign, mergers, and new third-party links).
• Exception handling: time-bound exceptions with explicit risk acceptance and compensating controls. ¹

6) Assign ownership and escalation paths

Document who owns:

• Flow approvals (app owner + security)
• Implementation (network/cloud engineering)
• Monitoring and alerting (SecOps/NetOps)
• Evidence collection (GRC with technical contributors)

This prevents “everyone thought someone else owned it” during an assessment.

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and ongoing operation:

Design and scope

• Network diagrams showing zones, routing boundaries, and enforcement points
• Data flow diagrams for in-scope applications
• Approved flow matrix tied to application access control expectations ¹

Configuration evidence

• Router configs (sanitized) showing route filtering/prefix lists and anti-spoofing controls
• Firewall rule exports/policies and change history
• Cloud route table exports and security group/NSG policy exports
• Third-party connection configs (VPN/peering) showing constrained routes ¹

Operational proof

• Change tickets with approvals and implementation notes
• Review meeting notes or attestations (who reviewed, what changed)
• Test results and relevant logs (flow logs, firewall logs, ACL hit counts)
• Exception register with expiration and compensating controls ¹

Common exam/audit questions and hangups

“Show me how routing aligns to application access control policy.”
Hangup: teams show a firewall rulebase but cannot show the policy mapping. Fix: maintain a flow matrix with app owner sign-off. ¹

“How do you prevent spoofed source addresses?”
Hangup: “we have a firewall” without ingress interface controls or cloud anti-spoofing story. Fix: document and demonstrate positive source validation at the boundary. ¹

“Do you have any paths that bypass inspection?”
Hangup: cloud peering/transit route propagation creates unintended reachability. Fix: restrict propagated routes and validate with reachability testing. ¹

“How do you know rules remain correct after changes?”
Hangup: no review cadence or no evidence of reviews. Fix: calendar-based review plus evidence pack export. ¹

Frequent implementation mistakes (and how to avoid them)

1. Relying on implicit deny without proving it.
   Avoidance: produce explicit boundary policies and test evidence that unauthorized flows fail at the right control point. ¹

2. Allowing broad “any-to-any” inside a trusted network.
   Avoidance: segment by tier and sensitivity; enforce least-privilege east-west rules, especially to data stores and admin services. ¹

3. Treating cloud routing as “handled by the provider.”
   Avoidance: cloud gives primitives; you must configure routes and security policies and show exports/logs as evidence. ¹

4. Third-party network links with oversized routes.
   Avoidance: restrict advertised/accepted prefixes; require documented route scope in third-party onboarding, and retest after changes. ¹

5. No single source of truth for allowed flows.
   Avoidance: flow matrix owned by security/GRC with app owner approvals; engineering configs must trace back to it.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so you should treat it as an auditability and breach-path control rather than a “case law” topic. The practical risk is straightforward: weak routing controls create unauthorized paths that bypass intended access restrictions, increase lateral movement options, and complicate incident containment because “who can talk to what” is not predictable. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and visibility)

• Define in-scope applications and network zones that support them. ¹
• Build the initial flow matrix from architecture docs and interviews; get app owner sign-off.
• Export current routing tables, firewall policies, and cloud security policies for a baseline evidence set.

Days 31–60 (close the biggest bypass paths)

• Identify routes/peerings/VPNs that create transitive connectivity across zones; restrict or add enforcement points. ¹
• Implement positive source/destination verification at key boundaries (on-prem ingress filters; cloud security group/NSG allow-lists aligned to the flow matrix).
• Run targeted reachability tests for the highest-risk flows (user/third-party/admin to data tier) and store results.

Days 61–90 (make it repeatable and auditable)

• Put routing-related changes under consistent change control with required approvals and documented rollbacks. ¹
• Establish a standing review rhythm: flow matrix vs. actual rules, plus exception review.
• Automate evidence pulls where possible (config exports, flow logs). If you use Daydream, set it up as the system of record for the flow matrix, exceptions, and evidence packages so audits become a repeatable export instead of a scramble.

Frequently Asked Questions

What does “positive source and destination address verification” mean in practice?

It means your routing and filtering rules explicitly confirm that traffic comes from approved source address ranges and is going only to approved destination ranges before it is forwarded. Allow-lists, anti-spoofing ingress filters, and route/prefix filtering are common ways to show this. ¹

Do security groups/NSGs count as routing controls?

They can support the requirement if they enforce the same outcome: only approved sources can reach approved destinations for approved services, aligned to application access control policy. You still need to show how cloud routes and peerings don’t create bypass paths around those controls. ¹

How do I prove “information flows do not breach access control policy” without over-documenting?

Keep one approved flow matrix per in-scope application (or per platform) and show that configs implement it, then add a small set of tests and logs that demonstrate blocked and allowed flows. Auditors want traceability and proof, not a novel. ¹

What’s the most common cloud failure mode for this requirement?

Overly permissive connectivity via transit/peering combined with broad security group rules, which creates unintended east-west reachability. Fix it by restricting propagated routes and tightening allow-lists to known source groups/subnets. ¹

Are NAT and load balancers “routing controls” I need to document?

Document them when they affect source/destination validation or create alternative paths to an application. If NAT hides original source addresses, you need compensating controls (logging, boundary enforcement) so you can still demonstrate positive verification and policy alignment. ¹

How should third-party network connections be handled?

Treat every third-party connection as a controlled routing domain boundary: restrict routes/prefixes, enforce allow-list flows, and keep evidence of approved connectivity scope plus test results. This is a frequent audit focus because third-party links often start broad and stay broad. ¹

Footnotes

1. HITRUST CSF v11 Control Reference