Architecting for DPDP. The XR Compliance Controls to Verify in the Stack, Not the Policy PDF.

Start Here: This Is the Engineering Audit, Not the Legal Brief

The legal substance of the DPDP Act — the data-fiduciary duties, consent, correction, erasure, and the full mandate-to-implementation mapping — is covered in QWR's DPDP Act & XR paper, in a healthcare context. This paper is deliberately the other half: what a security architect actually checks in the stack to know a device can uphold those duties. A datasheet that says "DPDP compliant" is a claim; the controls below are the evidence. Treat every one as a question you make the vendor answer with an artifact, not a sentence.

1. Where Is the Data Processed? Minimisation Is an Architecture, Not a Toggle

• On-device processing is the strongest minimisation control: The less sensitive data that ever leaves the headset, the smaller your compliance surface. Verify that spatial maps and biometrics can be processed at the edge, with only essential, anonymised metadata synced — not the raw point cloud or eye-tracking stream.
• Ask for the data-flow diagram, not the adjective: Require a documented map of every sensor stream — where it is computed, what is retained, what is transmitted, and what is discarded at capture. If a vendor cannot produce that diagram, they cannot substantiate a minimisation claim.
• On-device is also an availability control: Air-gapped or offline operation for sensitive sites means compliance doesn't depend on a network round-trip — useful where connectivity is unreliable or prohibited.

2. Audit the OS, Not the Promise: Clean AOSP, Signing Keys, No Hidden Telemetry

• A clean OS foundation is what makes "no foreign backdoors" checkable: QWR devices ship on a Clean AOSP base (Android 12/13) rather than a modified OS carrying undocumented telemetry hooks. The compliance value is that there is nothing hidden phoning home — but insist on proof, not assurance.
• Verified boot with your signing keys is the control that matters: Per the SDK, secure boot uses your unique signing keys, with a secure enclave for credential storage — so you, not the vendor, govern what runs on the device. That is the difference between trusting a claim and holding the key.
• Full source is what turns "trust us" into "audit us": QWR ships full kernel source (not binary blobs), the complete BSP, HAL, and hardware documentation — described as "no black boxes." For a CISO, source-level visibility is the only way to actually verify there is no undocumented data egress.

3. Residency Is a Configuration You Confirm — and Can Own

• Confirm where telemetry terminates: QWR's institutional analytics are stated to run DPDP- and GDPR-compliant, with data resident on AWS Mumbai and explicit data-residency options for partners on Indian government or defence contracts. Confirm the residency region is enforced in configuration, not aspirational.
• The strongest residency posture is your own infrastructure: The SDK exposes telemetry — session duration, crash reports, thermal and battery health — for export via REST API to your own analytics environment. That means sensitive fleet data need not sit in a vendor cloud at all, which is the cleanest answer to a residency question.
• Separate the vendor's compliance from yours: A vendor being DPDP-compliant does not make your deployment compliant. The controls that let you keep data in your jurisdiction and your systems are what transfer the assurance to you.

4. Erasure and Access Control Are Fleet Features, Not Paperwork

• Right-to-erasure has to be operational: Under DPDP, erasure is a duty you must be able to execute on demand. In practice that is an MDM capability — remote lock, wipe, and deletion across the fleet — not a manual process. Verify the platform's management layer can do it at scale.
• Access control is enforced through MDM: QWR's fleet layer provides remote lock/wipe, configuration management, and full app allowlisting, and integrates with Microsoft Intune and third-party MDM. Kiosk/single-app lockdown further shrinks what a device can do with data in the first place.
• Staged rollouts and rollback protect integrity: OTA with delta patches, staged cohort rollouts, and automatic rollback on anomaly keep the compliant configuration intact across thousands of devices — a control auditors increasingly expect to see.

5. The Manufacturing Half: IP Separation and ISO 27001

• DPDP-adjacent risk lives in the supply chain too: Your design files, firmware, and configuration are sensitive assets whose handling is part of your overall data-protection posture. This is where the Partner Infrastructure controls matter as much as the device OS.
• Verify the information-security backbone: QWR states ISO 27001 data-residency controls over all partner data, firmware, and design files, with mutual NDAs from the first requirement freeze and encrypted firmware delivery in transit and at rest.
• Zero cross-pollination is the isolation guarantee to get in writing: The stated commitment that your design is never shared or used in another partner's BOM, handled in isolated manufacturing cells, is the manufacturing analogue of on-device isolation — confirm it applies to your project specifically.

The CISO's Verification Checklist

Reduced to the artifacts to demand: a sensor-by-sensor data-flow diagram proving on-device minimisation; secure boot under your signing keys plus a secure enclave; full kernel/BSP source for independent audit; an enforced residency configuration (AWS Mumbai) and REST-API telemetry export to your own infrastructure; an MDM layer that can execute remote wipe and allowlisting at fleet scale; and ISO 27001-backed IP separation with encrypted firmware and zero cross-pollination. Each is a control you can test — which is exactly what makes it worth more than the words "DPDP compliant."

Strategic Conclusion: Compliance Is Something You Verify, Not Something You're Told

The DPDP Act turned data residency and control from a preference into a duty, and for XR that duty is discharged in the architecture. The right question to a hardware partner is never "are you DPDP compliant?" — every vendor says yes. It is "show me where the data is processed, prove the OS has no hidden egress, let me hold the signing keys, export the telemetry to my cloud, wipe a device from my console, and audit your IP-handling under ISO 27001." A partner whose stack answers all six with evidence has built compliance into the product. One that answers with a policy PDF has built it into a sentence.