Smart device and app privacy settings to specify

Make privacy part of the purchase specification

ICO guidance says you must adopt data protection by design and default. Add a privacy schedule to your product specification, covering the device, firmware, app and cloud service. The settings below are proposed purchasing requirements to adapt to your product, rather than a universal list of legally required switches.

Ask the factory to identify the app developer, cloud operator and embedded software providers. Record who can change settings, access user information and implement deletion. Get written confirmation from the relevant providers, rather than accepting a factory assurance about software it cannot control. For connectable-product security documentation, use our PSTI guide.

Specify the minimum data for each function

Ask for a data map showing each function, the information collected, its purpose, destination, retention rule and deletion trigger. Include identifiers, recordings, location, usage logs and diagnostic reports. Challenge fields collected for unspecified future use. Separate information needed to operate the product from optional analytics or product improvement.

Specify app permissions by function. Request microphone, camera or location access when the user starts the relevant feature, with an explanation of its purpose. Define what still works when access is refused. Avoid collecting contacts or continuous location merely because the supplier's standard app supports them.

Define what stays on the device

Ask whether detection, scheduling and basic control can run on the device or within the home network. Where feasible, specify local processing and send only the result needed for a requested remote feature. For example, a movement alert may be sufficient without uploading a continuous video stream.

Write down the boundary of local operation. Identify any cloud account, remote notification, diagnostic upload or backup that still sends information elsewhere. Specify what happens when the internet connection fails and when it returns, including whether buffered information uploads automatically. Protect stored information and define how local records are erased.

Set defaults and controls before approving the app

Use the following as a starting point for the supplier brief. Ask for a settings screen that explains the effect of each choice and allows users to change it later. Keep optional data uses separate from controls needed for the requested function.

Include controls for shared households and visiting users. Specify who can view recordings, invite another user or enable remote access, and how those permissions are removed. Ask for visible recording indicators and a physical microphone or camera disable control where appropriate.

Test the supplied build and preserve the settings

Test a clean installation using the proposed defaults. Record permissions, outgoing connections and server-side activity during setup, normal use and refusal of optional features. Use test accounts and dummy recordings. A screenshot of an off switch does not show whether collection has stopped.

Test changing settings, signing out, deleting an account and transferring the device to another owner. Specify that a factory reset clears local personal information and access credentials; test cloud deletion separately. Record any backup deletion process and explain it in the app.

Keep the approved firmware, app build, cloud configuration and test results together. Require approval before changes introduce new data fields, recipients or defaults. Repeat affected privacy checks after updates. Our firmware and software approval guide helps you identify which build the factory will supply. For lost features, see our guide to smart device update and cloud failures.