Smart device supplier data flow checklist
Obtain a model-specific data map covering identifiers, sensor readings, app permissions, named recipients and inferred profiles. Ask what stays on the device, what leaves it, why it is used and how deletion works. Match the map to a working sample before choosing a supplier. Cambridge China Bridge can obtain supplier answers through its staff in China.
Ask for a map of the actual product
Request a data-flow diagram and field list for the proposed device, firmware, app and cloud service. Trace collection, local storage, transmission, further processing and deletion. Include account registration, normal use, background activity, support access and ownership changes. Ask the factory to involve its app and cloud providers where it cannot answer directly.
ICO guidance explains that someone may be identifiable indirectly even when the information does not identify them directly. Ask what links device records to accounts, households or other databases. Our connectable products guide covers security documentation; this checklist adds the information needed to understand data use.
List identifiers, readings and derived information
Ask for actual field names and example values using test accounts. Distinguish raw readings from calculated results and linked records. For every field, record its source, purpose, collection trigger, destination, retention rule and deletion route. Ask whose information is captured, including household members, visitors and people appearing in recordings.
| Data group | Examples to ask about | Question to resolve |
|---|---|---|
| Identifiers | Device serial number, account identifier, network address, advertising identifier | Which identifiers persist, and what records can they be linked to? |
| Sensor readings | Audio, images, movement, temperature, location | What triggers collection, and what stays local or leaves the device? |
| User and usage records | Registration details, account linking, commands, feature use, diagnostic logs | Which fields support the requested feature, and which serve another purpose? |
| Inferred information | Occupancy patterns, routines, preferences, wellness predictions | What inputs produce each inference, who receives it, and can it be disabled? |
Check permissions against real behaviour
Obtain a permission list for each supported phone platform, with the feature needing it, when the request appears and what happens after refusal or withdrawal. Ask about microphone, camera, location, contacts, photos and nearby-device access. Separate permission to use a phone capability from the subsequent storage, sharing and use of the information.
Test a sample with optional permissions refused, then enabled and withdrawn. Check background behaviour and whether basic features still work. Ask the supplier to explain any difference between the permission screens, privacy notice and technical map. Keep screenshots and test logs with the approved configuration; use our firmware and software approval guide to record that configuration.
Name recipients and explain inferences
Ask for named organisations behind the app, cloud hosting, analytics, advertising, voice processing and remote support. For each, record the fields received, purpose, storage country, remote-access countries and any onward sharing. Ask who decides how information is used and who acts on another organisation's instructions. A server location alone does not answer who can access the data.
Ask whether raw readings are combined with account details or outside information to predict health, routines or preferences. Request an explanation of each output and whether it affects recommendations or other decisions. Flag health predictions and identity-matching features for specialist privacy review before selection. For camera purchases, also use our CCTV sourcing guide.
Working out your own order? Send us the product on WhatsApp and we reply the same working day: WhatsApp us
Make unanswered questions a selection condition
Request a demonstration of account deletion, device reset and transfer to a new owner. Ask separately what happens to cloud records, derived profiles, backups and support logs. Obtain the retention periods the supplier actually uses and who handles deletion requests. Do not accept a reset demonstration as evidence that remote copies have been removed.
Compare suppliers against the same checklist. Hold selection where recipients are unnamed, permissions are unexplained or the factory cannot obtain answers from its software provider. Attach the agreed map to the purchasing specification and require notification before changes to data fields, recipients or purposes. Cambridge China Bridge can coordinate these questions with the factory through its own staff in China.
Frequently asked questions
What data documents should I ask a smart device supplier for?
Request a model-specific data-flow diagram, field list, permission list, named recipient list, privacy notice and retention and deletion explanation. Check them against the proposed app and firmware.
Are device identifiers anonymous?
Do not assume so. Ask whether identifiers can be linked to accounts or other records. ICO guidance explains that indirect identification may be possible even without direct identification.
Is an app permission list enough?
Use it alongside the data map. A permission list does not explain every destination, recipient or later use. Test refusal and withdrawal, and ask what happens to information already collected.
What if the factory uses an outside app provider?
Ask the factory to obtain written answers from that provider. Keep unresolved data flows as a selection condition rather than accepting a general assurance from the hardware sales team.