Notifications
Clear all
Topic starter
11/07/2026 8:30 pm
TL;DR: India’s Digital Personal Data Protection Act puts cross-border data movement, accountability, and jurisdictional control at the center of compliance, and cloud-routed ZTNA can create routing paths that undermine those obligations according to Appgate. Architecture, not policy language, becomes the deciding factor for keeping personal data within approved boundaries.
NHIMG editorial — based on content published by Appgate: DPDPA compliance and direct-routed ZTNA for India
Questions worth separating out
Q: How should security teams design ZTNA for data residency requirements?
A: Teams should design ZTNA so that control-plane functions, session routing, and logging stay inside the approved jurisdiction for the data class being handled.
Q: Why does encrypted traffic still create compliance risk under DPDPA?
A: Encryption protects confidentiality, but it does not remove the regulatory significance of where data and metadata travel.
Q: What breaks when ZTNA relies on vendor points of presence?
A: The main failure is jurisdictional control leakage.
Practitioner guidance
- Map every ZTNA route against approved jurisdictions Document where user traffic, control-plane functions, and logging infrastructure actually terminate.
- Localise access control components Deploy controllers, gateways, and policy services inside India or inside a jurisdiction that your legal team has explicitly approved for the relevant data class.
- Require session evidence for auditability Capture user identity, device posture, policy decision, route location, and resource accessed for each session so auditors can verify that data paths stayed within approved boundaries.
What's in the full article
Appgate's full article covers the operational detail this post intentionally leaves for the source:
- How direct-routed ZTNA is positioned to avoid vendor-owned points of presence in the access path.
- The deployment options Appgate describes for keeping controllers and gateways within India-based infrastructure.
- The compliance mapping the source makes between DPDPA requirements and access logging, auditability, and jurisdictional control.
- The architectural contrast it draws between cloud-routed and direct-routed access models for regulated environments.
👉 Read Appgate's analysis of DPDPA compliance and direct-routed ZTNA →
DPDPA and ZTNA: are your access paths staying inside India?
Explore further
11/07/2026 8:59 pm
Jurisdiction is now an access-control problem, not just a privacy policy problem. The DPDPA framing makes route selection, controller placement, and session handling part of compliance evidence. If access traffic can leave India through vendor-operated infrastructure, then the organisation has outsourced part of its regulatory boundary. Practitioners should treat jurisdictional integrity as a control objective, not a legal afterthought.
A question worth separating out:
Q: Who is accountable when access infrastructure crosses borders?
A: Accountability sits with the organisation that decides how personal data is processed and where access components are deployed, even when a third party provides the platform. Data fiduciaries and processors both need clear responsibility for routing, logging, retention, and local control. If the jurisdictional boundary is unclear, compliance becomes difficult to demonstrate.
👉 Read our full editorial: DPDPA compliance depends on jurisdiction-aware access architecture
