What is the difference between direct-routed and cloud-routed ZTNA for compliance?

How the routing model changes the compliance boundary

Direct-routed ZTNA and cloud-routed ZTNA can both enforce application-level access, but they do not create the same compliance footprint. The routing choice determines where traffic is terminated, inspected, and brokered, which can affect data residency, cross-border transfer analysis, and which party is acting as a processor or service provider for regulated traffic.

For compliance teams, the key question is not just whether the connection is “zero trust,” but where the control plane and data path sit. A direct-routed design usually makes the customer’s own environment the dominant control boundary, while a cloud-routed design can add vendor-operated transit and logging paths that need to be reviewed under privacy, sector, and vendor-risk obligations.

That distinction is why routing can matter even when the security policy outcome looks similar. If the service path crosses extra jurisdictions or stores telemetry outside the customer’s chosen region, the same access decision may carry a different compliance burden.

What direct-routed and cloud-routed ZTNA each imply for evidence and accountability

Direct-routed ZTNA is easier to align with a “keep the traffic on paths we control” compliance story, because the organisation can more clearly document the location of gateways, inspection points, and logs. That can simplify data-flow diagrams and contractual review, especially when the regulated concern is not only access control but also where personal data or metadata moves during enforcement.

Cloud-routed ZTNA can still be compliant, but it often requires more explicit proof around vendor scope, region selection, retention settings, subprocessor handling, and transfer safeguards. In practice, the cloud broker becomes part of the compliance chain, so the assessment shifts from “is access controlled?” to “who operates each hop, and what obligations attach to those hops?”

For organisations already mapping zero trust to architecture, the most useful lens is to treat the routing layer as part of the control design, not as a transport detail. NIST SP 800-207 Zero Trust Architecture helps frame that distinction by focusing on explicit policy enforcement rather than implicit network trust.

When the use case involves remote staff, third parties, or mixed trust zones, routing choice also affects how clearly you can prove that access is constrained at the right boundary. NHIMG’s Remote Access Identity Guide is useful here because it ties ZTNA decisions to remote-access governance, controller placement, and retirement of older VPN-style assumptions.

What compliance teams should check before treating ZTNA as “done”

Compliance review should start with the data path, not the product label. If the provider brokers sessions through shared cloud infrastructure, verify where traffic is terminated, where logs are written, whether inspection metadata is retained, and whether the service introduces transfers you must disclose or justify. If traffic stays direct-routed, verify that the customer-controlled components really are the only enforcement points and that fallback paths do not quietly reintroduce vendor transit.

For GDPR-driven assessments, routing is especially important because a design can change the transfer picture even when no new application is added. If personal data, identifiers, or session metadata traverse a vendor-operated path, your record of processing and your vendor terms need to reflect that reality, not the marketing diagram. EU General Data Protection Regulation (GDPR) is the governing reference when the traffic contains EU personal data and the routing design changes how that data is processed.

Cloud-routed deployments also deserve a tighter vendor-risk review than many buyers initially expect. CSA Cloud Controls Matrix is a practical cloud control reference for checking IAM, audit, and data-handling responsibilities, while EU NIS2 Directive is relevant where the organisation needs to evidence supply-chain and access-control governance across critical services.

Practitioner Guidance

What to verify: Ask whether the ZTNA architecture changes the jurisdiction, retention, or subcontractor chain for traffic metadata as well as for payload traffic. If yes, treat the routing choice as a compliance decision, not a deployment preference.

Decision rule: If the organisation must minimise third-party transit for regulated data, direct-routed is usually the simpler posture to defend. If cloud-routed is preferred for operational reasons, require documented region controls, transfer analysis, and vendor contract coverage before approval.

What good looks like: Your architecture diagram, data-flow record, and vendor terms should all describe the same routing reality. The control is working when auditors can trace where traffic is terminated, where logs are kept, and which party can access the relevant telemetry without relying on assumptions.

Practitioner takeaway: The compliance difference is not about “better security” in the abstract, it is about whether the routing layer expands the set of places, parties, and legal obligations that touch the session.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?