Questions to ask about smart glasses data handling before purchase

Time needed about four hours, spread over two days

The steps

1. Assemble legal and IT stakeholdersBring legal counsel, the IT security lead and the line manager running the pilot together and share this checklist plus your DPA template.You should see: A meeting record listing attendees and an action list assigning DPA review to legal and technical verification to IT.
2. Send your DPA and request the vendor roleSend the vendor your DPA template and ask them to state and sign whether they act as processor or co‑controller for the pilot.You should see: A returned DPA draft with vendor signature blocks filled and a clear statement of their role.
3. Request an annotated data flow diagramAsk the vendor for a current diagram or spreadsheet listing every data type, destination, frequency and third‑party SDK access.You should see: A document that shows raw frames/audio destinations, derived metadata endpoints, timestamps and sampling rates.
4. Request subprocessors and transfer mechanismRequest a current list of subprocessors, their roles and data access and the legal mechanism for cross‑border transfers (SCCs or adequacy).You should see: A signed subprocessor list and a document reference for transfer mechanisms you can review.
5. Request security evidence and SLA termsAsk for recent penetration test summaries, SOC/ISO attestations and the security incident SLA with response and remediation windows.You should see: Receipt of pen test summaries or full reports under NDA, certificate references, and SLA text in the contract draft.
6. Require a live demo of SSO and MDM policy pushRequire a recorded demo where an admin completes SSO login and applies an MDM policy to an enrolled device.You should see: Demo recording or logs showing successful SSO and a pushed MDM policy with confirmation on the device.
7. Verify sensor disable and network egress in demoDuring the demo, have an admin disable camera and microphone and observe outbound connections and logs to confirm no frames leave the device.You should see: Logs or network capture showing the sensor disable event and empty outbound connections during the test.
8. Start a constrained pilotBegin a pilot under the agreed DPA with devices enrolled in MDM and network constraints; if checks failed, run a synthetic-data pilot with isolation instead.You should see: Devices enrolled in MDM, monitoring logs flowing to your systems, and no unexpected outbound traffic recorded.
9. Audit and sign off or terminateAfter the pilot, review logs, DPA compliance, subprocessors and any incidents and either sign off to move to production or terminate the agreement.You should see: A written sign-off from legal and IT or a termination notice listing reasons and required remediations.

Questions to ask about smart glasses data handling that you must get in writing

Before any pilot hardware ships, require written vendor commitments: a DPA naming roles, an annotated data flow diagram, encryption details, MDM/SSO support and indemnities. Put these items into the RFP so technical and legal teams must answer them before devices enter your network.

If those commitments are missing or vague, you inherit operational and GDPR exposure when the pilot runs with live data.

• Signed Data Processing Agreement with named processor or co‑controller role
• Annotated data flow diagrams showing what leaves the device
• Encryption in transit and at rest plus enterprise key options
• MDM/SSO support and ability to disable cameras/mics or run local‑only
• Named subprocessors, transfer mechanism (SCCs/adequacy) and audit rights
• Indemnity language and a security incident SLA

Who is the controller and who is the processor — demand a DPA and named roles

Get the vendor to state in writing whether they act as processor or co‑controller and sign a DPA that reflects that role. The DPA must name your organisation, list processing purposes, and set responsibility for subject access requests and breach notification.

Insist on contractual timelines for breach notification and clear allocation of who keeps records of processing and who responds to data subject requests.

• Request a DPA template and require insertion of your organisation's name where relevant
• Require explicit breach-notification timelines in hours, not vague language
• Include DPIA support and a commitment to provide technical details on request

Exactly what data leaves the device — insist on precise data flows

Ask for an up‑to‑date annotated data flow diagram showing every data element that leaves the device, its destination, frequency and any third‑party SDK access. You must know if raw camera frames or raw audio are uploaded, or only derived metadata such as object IDs or transcriptions.

If the vendor says they upload ‘minimal data’, require specifics you can verify: file names, frame sizes, sampling rates, endpoints and timestamps.

• Demand answers for raw frames, compressed frames, audio streams, transcriptions, telemetry and derived metadata
• Ask for frequency: continuous stream, event-driven, or batch upload
• Require disclosure of third‑party SDKs and their data access

Mandatory technical controls to require before you deploy

Require mutual TLS for device-to-cloud connections and encryption at rest with customer-managed key options or hardware-backed storage. Insist on enterprise SSO, corporate MDM integration and admin controls to disable cameras and microphones.

Demand a demo or test report that proves an admin can disable sensors remotely and that no frames leave the device when disabled.

• Mutual TLS for device connections and strong encryption for data at rest
• Support for enterprise SSO (SAML/OIDC) and corporate MDM with policy enforcement
• Customer-managed key option or hardware-backed key storage (HSM/TPM)
• Admin controls to disable sensors and an explicit local‑only mode

Data lifecycle and user rights: retention, deletion and forensics

Contractually set retention limits per data class and require secure deletion procedures that cover caches, backups and third parties. The vendor must support data portability, subject access requests and provide immutable logs that show who accessed which data and when.

Require SLA timers for deletion actions and proof mechanisms such as audit records showing deletion across systems.

• Retention periods stated per data class and automated deletion workflows
• Secure wipe procedures for returned devices and factory resets verified by audit
• Immutable access logs retained long enough for investigations and exportable for eDiscovery

Subprocessors, cross‑border transfers and audit rights you must negotiate

Get a current list of subprocessors with their roles and data access, and a contractual commitment to notify you before adding new ones. Require a transfer mechanism for cross‑border processing — Standard Contractual Clauses or adequacy — and explicit audit and inspection rights.

Audit rights should allow you to request certificates, review pen test reports under NDA and run on‑site or remote technical audits where necessary.

• Named subprocessors with roles and data access descriptions
• Cross‑border transfer mechanism stated (SCCs or adequacy) and notification commitment
• Contractual audit rights and acceptance of third‑party assessments under NDA

Liability, SLAs and proof of security you must insist on

Require indemnities for breaches caused by the vendor or its subprocessors and an SLA that covers security incident response and availability. Ask for recent penetration test reports and evidence of a responsible disclosure or bug disclosure channel.

Treat certificates and attestations as supporting evidence, not a replacement for contractual obligations.

• Indemnity clauses tied to data breaches where permitted by law
• Security incident SLA with measurable response and remediation windows
• Recent penetration test reports, remediation evidence and disclosure channels

What goes wrong in practice and the sequence that sinks pilots

Pilots commonly fail because procurement approves hardware on demos, legal signs standard terms and the pilot runs with production data before technical controls are verified. You then discover raw frames uploading or an undisclosed analytics SDK and removing devices becomes painful.

Prevent this by enforcing the checks here before shipment: DPA, data flows, MDM and demonstrable sensor controls.

• Early skip: accepting a vendor whitepaper instead of a signed DPA
• Late discovery: third‑party SDKs sending raw sensor data that are hard to remove mid‑pilot
• Operational cost: no MDM prevents remote revocation when a device is lost

If the vendor refuses key clauses — fallback options and negotiation priorities

If a vendor refuses a DPA or named role, do not proceed to production. Negotiate a constrained pilot: synthetic or anonymised data, network isolation, a short revocable period, escrowed logs and a termination right if undisclosed flows are found.

Prioritise clauses in this order when negotiating: DPA, sensor controls proof, subprocessor transparency, then key management options.

• Fallback: limited pilot using synthetic scans or masked audio
• Fallback: network egress filtering to only allow vendor endpoints
• Negotiation priority: DPA > sensor-disable proof > subprocessor list > key management

Next step: update your RFP and compare compliant vendors

Add these contract and technical verification steps to your RFP and score vendors on evidence, not claims. Require a live demo, signed DPA, demonstrable sensor controls, enterprise MDM support and a named subprocessor list before you approve a pilot.

Use our directory to compare compatible apps and devices and to check workplace-ready hardware such as /devices/vuzix-shield and platform notes for /devices/android-xr and /devices/ray-ban-meta.

• Add specific contract clauses to the RFP and score vendors on them
• Require a live demo proving camera/mic can be disabled and no data egress occurs
• Compare vendor security evidence and subprocessors before pilot approval

Where this usually goes wrong

• You discover raw camera frames are stored in a third‑party cloud after the pilot startedThe vendor's SDK or analytics pipeline was not disclosed and uploads were not blocked in the pilot networkStop the pilot, isolate devices, require deletion of captured data, demand an audit trail proving deletion and refuse production until the vendor signs the DPA and removes or limits the SDK
• Employees report that cameras cannot be disabled centrallyThe vendor's management console lacks enterprise MDM features or the shipped firmware does not support remote sensor disableQuarantine the device with MDM rules, demand an engineering fix and require a remediation SLA before further rollout
• A legal review flags unknown subprocessors in a transfer chainThe vendor provided an outdated or incomplete subprocessor list during procurementInvoke audit rights, require immediate disclosure, and add a contract clause allowing suspension of data flows until you approve new subprocessors
• Vendor cannot provide penetration test reports or refuses an auditLack of a mature security programme or unwillingness to expose weaknessesRequire a third‑party assessment under NDA or proceed only with a constrained pilot using synthetic data and contractual indemnity for security incidents

The checklist

• Assemble legal and IT stakeholders
• Send your DPA and request the vendor role
• Request an annotated data flow diagram
• Request subprocessors and transfer mechanism
• Request security evidence and SLA terms
• Require a live demo of SSO and MDM policy push
• Verify sensor disable and network egress in demo
• Start a constrained pilot
• Audit and sign off or terminate

Frequently asked questions