Because regulators care about where data is processed as well as who can reach it. If a cloud broker relays the session, the organisation may not be able to demonstrate that the data stayed inside the required legal boundary. That shifts ZTNA from a pure access problem into a governance and evidentiary one.
Why ZTNA routing changes the compliance conversation
ZTNA is not just about whether a user can connect, it also determines how the connection is brokered, inspected, and evidenced. If traffic is routed through a provider-controlled path, the organisation may be relying on a third-party control plane to prove where data travelled, which matters for legal boundary claims, regulated processing, and audit defensibility.
That is why routing design becomes part of governance. A “who can access” decision may be technically sound while still leaving the organisation unable to demonstrate that the session remained inside an approved jurisdiction or segregation zone.
What routing does to accountability and evidence
Routing affects accountability because it changes what the organisation can attest to after the fact. When the access path is direct and well instrumented, logs and policy decisions are easier to tie to a specific user, device, application, and network segment. When the path is abstracted through a broker, you need stronger evidence that the brokered path preserved the required data-handling boundary and that the provider’s telemetry is sufficient for audit and incident review.
For practitioners, the key issue is not whether ZTNA is “secure enough” in the abstract, but whether the routing model produces verifiable records. If the evidence chain stops at the vendor edge, accountability becomes harder to assign when a regulator, customer, or internal investigator asks where the traffic actually went.
How to evaluate ZTNA routing for regulated environments
Start by treating routing as a control boundary, not a transport detail. The routing model should be explicit about data residency, segmentation, egress, inspection points, and log availability. Where ZTNA is being used to replace or compress VPN-style access, the organisation should still confirm that the new path preserves the same compliance assertions or replaces them with better ones.
That is especially important for third-party access, cross-border users, and environments with contractual locality commitments. A design can satisfy least-privilege access while still failing an audit if it cannot show that regulated data never left the required region or processing boundary.
Risk and Threat Considerations
Routing risk appears when the organisation assumes the broker is only a connectivity layer and not a processing participant. In practice, the broker may terminate, inspect, relay, or log session data, which can create jurisdictional ambiguity and weaken accountability if the provider’s path is not contractually and technically bounded.
Failure mechanism: The access decision is validated, but the session path, logging location, or inspection point crosses an unapproved boundary, so the organisation cannot prove that processing stayed inside the required legal or contractual zone.
Impact: That can create audit findings, contractual breach exposure, weaker incident evidence, and unresolved questions about controller, processor, or operator responsibility when data handling is challenged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022, GDPR and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Network and Application Access Control | ZTNA routing is a Zero Trust access-path design issue that affects policy enforcement and boundary control. |
| Recommendation — Define and enforce explicit access paths that preserve segmentation and locality evidence. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Routing determines whether regulated data flows remain within approved processing boundaries. |
| Recommendation — Enforce approved information flows and verify that session routing matches boundary requirements. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | ZTNA routing influences how access is brokered, constrained, and evidenced for audit. |
| Recommendation — Document routing-dependent access boundaries and retain evidence that they are enforced. | ||
| GDPR | Article 32 — Security of processing | Routing and brokered processing can affect how personal data is protected and evidenced during transit. |
| Recommendation — Assess whether brokered access preserves security of processing and proof of boundary compliance. | ||
| NIS2 | Article 21 — Cybersecurity risk-management measures | Routing choices can alter access control, segmentation, and evidence obligations in ICT risk management. |
| Recommendation — Map ZTNA routing decisions into documented ICT risk-management and access-control measures. | ||
Practitioner Guidance
What to verify: Confirm the exact session path, the jurisdictions involved, where logs are stored, and whether the broker ever sees content that would count as processing under your policy or regulation. If the answer depends on vendor assurances alone, treat the control as incomplete.
Decision rule: If you must prove regional containment, choose a routing model that gives you evidence of path locality and logging locality, not just policy enforcement. If you cannot obtain that evidence, the design should be treated as a compliance risk even when access control is otherwise strong.
Practitioner takeaway: ZTNA routing is a governance control when auditability depends on the path as much as the permission, so design for demonstrable locality, not just successful authentication.