Why data is a sourcing question
In an audio-only pair of glasses, data handling is modest: pairing records, settings and firmware version. Add translation, an AI assistant or a camera and the picture changes. Speech is sent to cloud services, photos and videos are stored and synced, transcripts and request histories accumulate, and the app may ask for wide permissions on the phone. When those glasses are sold under your brand, customers, retailers and regulators look to you for answers, even though the hardware came from a partner plant and the app from a solution provider.
That is why data belongs in the sourcing brief, not in a late legal review. The choices that decide data handling - which app, which cloud services, which permissions, who operates the servers - are made when a catalog model or solution provider is selected. Changing them after launch is slow and expensive. A short, specific checklist at the sampling stage avoids most surprises.
What data the glasses and app handle
Start by mapping the data. The table lists the common data types for each feature, where they usually go and the question to ask. Exact behaviour is per app and per program, and should be confirmed in the app's documentation.
| Data type | Where it usually goes | Buyer question |
|---|---|---|
| Pairing and device data | Phone app, sometimes the provider's server | Is a user account required, and what device identifiers are collected? |
| Voice for translation | Cloud translation engine via the app; offline packs on the phone for a few languages | Where is audio processed, and is it stored or used to improve services? |
| Assistant requests | Assistant service in the cloud after activation | Is the wake word detected locally, and can users review and delete history? |
| Photos and videos | Glasses storage, then the phone app, optionally a cloud account | Is cloud sync opt-in, and where are synced files hosted? |
| Transcripts | Phone app, sometimes synced | How long are they kept, and can they be exported or deleted? |
| Usage and crash analytics | App provider's analytics service | What is collected, is it optional, and who receives it? |
| Firmware update records | Update server | Who operates the server, and are updates signed? |
Phone permissions the app requests
Companion apps ask the phone for permissions, and each one should have a clear reason. Common requests include Bluetooth access to connect to the glasses; microphone access for calls, translation and the assistant; storage or photo library access for camera models; notification access to read messages aloud; and contacts or call access for calling features. Some phone platforms also tie Bluetooth scanning to location permission. Ask the app provider for the full list, the reason for each permission and whether the app still works if a non-essential permission is refused.
Over-broad permissions are a common source of poor reviews and store rejections. An app that asks for location, contacts and full storage on first launch, before explaining why, loses trust. A better pattern requests permissions when the feature that needs them is first used, with a one-line explanation. Write the expected permission set into the spec sheet, and recheck it after each app update, because new versions sometimes add permissions without notice.
Regulation: EN 18031, the CRA and data protection
In the EU, Delegated Regulation (EU) 2022/30 activates RED Article 3(3)(d), (e) and (f) for internet-connected radio equipment and explicitly lists glasses among wearable radio equipment. These cybersecurity requirements have applied since 1 August 2025, with the EN 18031 series as harmonised standards: EN 18031-1 covers network protection, EN 18031-2 covers personal data protection and EN 18031-3 covers devices that process financial transactions. From 11 December 2027 the Cyber Resilience Act is due to take over this role. The detail is in RED cybersecurity and EN 18031.
Data protection law applies alongside product rules. The app and services that process voice, images and transcripts must meet GDPR in Europe and equivalent rules elsewhere. For camera glasses, the EDPB statement adopted on 13 October 2026 - guidance, not law - sets out expectations for recording indicators and places the transparency duty on manufacturers; see camera glasses privacy. Templora collects the cybersecurity file and app documentation from partner plants and solution providers and verifies it per project, but it does not give legal conclusions: confirm obligations with counsel for each market.
White-label apps and who is responsible
Many brands sell glasses with a white-label version of the solution provider's app. That is efficient, but it splits responsibilities in ways that must be written down. The program documents should state who publishes the app in each store, who operates the servers and in which regions, who acts as data controller and processor, who answers user data requests, who handles security incidents, and how long the app will be maintained after the last batch ships. Brand options for apps are covered on OEM and private label; assistant-specific questions are in AI assistants on smart glasses.
The buyer checklist
- Data map. A list of data types per feature, where each is processed and stored, and for how long.
- Account model. Whether a user account is required and which features work without one.
- Permission set. Every phone permission with its reason, and behaviour if refused.
- Local versus cloud. Wake word detection, offline translation and any other local processing, stated in the app documentation.
- User controls. Mute, history review and deletion, cloud sync opt-in, account deletion.
- Camera rules. Recording indicator behaviour per firmware, including assistant captures.
- Security. Signed firmware updates, closed debug ports on production units, update support period.
- Compliance file. EN 18031 documentation for the EU, privacy policy, and the responsibility split for white-label apps.
Send this checklist with your brief through the quote form; Templora includes the answers in the sample comparison so data handling is weighed alongside sound, fit and runtime.
Keep the checklist alive after launch. App updates, new cloud services and firmware releases can change data flows and permissions, so recheck the answers at each release and before every reorder. Record the app and firmware versions that were reviewed, and ask the solution provider to notify you in writing before changes that affect data handling. Reorder timing and sample windows are listed on MOQ and lead time.