Skip to main content

How do we ensure accountability in IoT products?

Contents

What is accountability?

Accountability is a principle of data protection law. It means you are responsible for complying with the data protection principles, and that you are able to demonstrate that compliance.

Getting accountability right when you start developing your IoT product or service will help you take an approach that includes data protection issues from the beginning. 

You should think about some things at the earliest stages. These include:

  • correctly allocating roles and responsibilities regarding any organisation(s) you work with;
  • identifying and assessing the risks in your processing;
  • considering any specific needs or requirements if your IoT products and services are likely to be accessed by children; and
  • adopting a data protection by design approach. 

How should we understand controller/processor relationships in IoT?

It is common for multiple organisations to be involved in the processing activities of IoT products and services. In these cases, a crucial aspect of accountability is properly allocating roles and responsibilities. 

Any one organisation may be:

  • a controller – if it has overall control over the purposes and means of the processing;
  • a joint controller – if it jointly makes decisions about the purposes and means with other organisations; or
  • a processor – if it acts only on another organisation’s behalf under its instructions. 

Which role an organisation plays depends on: 

  • the specific processing of personal information taking place;
  • the circumstances in which this happens; and
  • who has genuine, real-life influence and control over the purposes and means of the processing.

A first step to working out your role is to identify the distinct sets of processing operations and their purposes. Whoever makes the overarching decisions about the ‘how’ and the ‘why’ of the processing is a controller.

As IoT products process personal information for several purposes, you may be a controller or joint controller for some phases of the processing and a processor for others.

What types of decision do controllers take?

Controllers make decisions about:

  • whether to collect personal information in the first place;
  • what types of personal information to collect;
  • the purpose or purposes for which the personal information is to be used;
  • which people to collect the personal information about;
  • how long to retain the personal information; and
  • how to respond to requests from people about their rights.

Organisations that, as a matter of fact, determine the purposes and means of processing are controllers regardless of any description of their role in a contract.

When could we be a joint controller?

Joint controllers jointly decide the purposes and means of processing. Organisations are not joint controllers if they are processing the same information for different purposes.

If your processing involves multiple organisations, you should take the time to assess and document the status of each organisation you work with covering all your personal information processing activities.

If you and another organisation process for the same or for shared purposes, you are joint controllers. 

What types of decision do processors take?

If you don’t have any purpose of your own for processing the personal information and you only act on a client’s instructions, you are likely to be a processor – even if you make some technical decisions about how you process the personal information.

For example, where allowed in the contract, processors can make decisions about:

  • the IT systems and methods to process personal information;
  • how to store the personal information;
  • the security measures that will protect it; and
  • how to retrieve, transfer, delete or dispose of it.

How do these roles apply to IoT?

There are likely to be multiple parties who process personal information in the IoT ecosystem contributing to the creation and functioning of IoT products. For example:

  • device manufacturers;
  • application developers;
  • software development kit providers;
  • operating system providers;
  • app stores;
  • IoT platform and cloud providers; and
  • organisations producing or providing other IoT products and online services. 

In some instances, only one organisation make decisions about the design and delivery of an IoT product or service. If so, only that organisation is the controller for the personal information the product or service processes. 

However, in practice the IoT ecosystem can be complex. Most processing by IoT products and services is likely to involve more than one organisation.

So if your IoT processing involves different types of commercial and technical arrangement with different entities, you must establish the respective responsibilities of each, taking into account:

  • the specific circumstances of the processing involved; and
  • the processing activities for which each party determines the purposes and means (whether alone or in combination).

In practice, this probably requires a case-by-case assessment depending on the processing activities. 

Example

Manufacturers design and develop the IoT product’s hardware or software. They may play a role in determining its overall functionality. They may also collect personal information that the device generates for their own purposes. These sorts of activity may make them controllers.

Application developers build mobile apps or other software and services to allow people to interact with the IoT product. They may have made decisions about how the app works, what data it collects and how information is stored or accessed. 

The manufacturer and the app developer may be the same organisation. If so, it is responsible for the overarching decisions about the processing but:

  • a manufacturer might build the product, but engage a specialist app developer to design the associated mobile app;
  • an app developer might outsource some of the processing to another organisation; or
  • an app developer might enable data access by other organisations, eg ad networks or other third parties via an SDK.

Example 

An IoT manufacturer works with an SDK provider that provides services requested by the IoT manufacturer. The SDK provider is therefore a processor in this relationship. 

The SDK provider only processes personal information for the purposes defined by the IoT manufacturer. The SDK provider acts on the IoT manufacturer’s behalf. 

Example

An IoT manufacturer works with an SDK provider that provides services requested by the manufacturer. 

The SDK provider also processes personal information about the manufacturer’s IoT product for its own purposes. It produces statistics about how its SDK works with the manufacturer’s IoT product to improve its own service. 

The SDK provider and IoT manufacturer have a data-sharing agreement so the SDK provider can use the information for its own purposes. The SDK provider also needs to identify an appropriate lawful basis for its processing.

In this instance, the SDK provider and the IoT manufacturer need to determine whether they are separate controllers or joint controllers.

What do we need to do if children are likely to use our IoT products or services?

If your IoT products (and associated services) process children’s information, you should take into account that children merit specific protection because they may be less aware of their rights and of the risks involved in the processing. 

You must also consider whether you need to conform to the Children’s code. The code applies to relevant ‘information society services’, which broadly cover any service normally provided for remuneration, at a distance, by electronic means and at the individual request of a recipient of services. 

If your IoT product is likely to be accessed by a child and you are a relevant ISS, you should conform with our Children’s code. You should read the code alongside the UK GDPR. The code supports compliance with the general data protection principles by setting out specific standards for the design of online services likely to be accessed by children. 

You should conform to the standards in this code if you provide an IoT product or service likely to be accessed by a child. 

Examples include products or services:

  • specifically aimed at children such as a smart toy, a children’s fitness tracker, a children’s virtual reality headset or a children’s smart speaker; and
  • not specifically aimed at children but likely to be accessed by them, like a smart home hub, smart speaker (aimed at the general population) or a smart doorbell. 

If you provide electronic toys or products that do not connect to the internet, and only store personal information within the product itself, you may not need to conform to the code – for example, if any personal information they process is only stored on the product itself. However, even in cases where you don’t collect information from the devices, you must still follow a data protection by design approach when you make them.

Refer to the Children's code for the complete list of its standards and assess how they apply to your processing. 

What risks do we need to manage?

Consumer IoT products are often designed for use in the home, where people have the biggest expectation of privacy. For example, they can be used to monitor people’s activities and behaviours, as well as those of their households, friends and family. So, IoT products can reveal information about people continuously and at a large scale. 

You should assess whether you need to process personal information to your IoT product. You must also decide how long it is necessary to keep people’s personal information. If you decide to collect and store it, you must ensure you protect it with appropriate measures.

This is not meant to be a comprehensive guide to all the risks to people’s rights and freedoms associated with the processing of personal information by IoT products and services. However, potential risks may arise from:

  • extensive and intrusive tracking and profiling, eg of people’s locations and behaviours;
  • lack of control and information asymmetry;
  • use of IoT products by multiple users with limited controls available for all all of them;
  • inadequate security and the possibility of personal data breaches; and
  • unclear roles in the IoT supply chain, meaning different organisations don’t assign responsibilities correctly.  

Many IoT products process special category health and biometric data as well as data about users’ location. They may also be designed to create personalised experiences for their users, giving them many benefits. However, if you don’t follow a data protection by design and by default approach, your processing can lead to harms. 

The harms can include people feeling they’ve lost control over their personal information. In some cases, this can lead to psychological distress (such as anxiety). Children may be especially susceptible to psychological harms from information revealing details about their preferences and personalities. People may lose trust in how their IoT products process personal information. This can lead to a chilling effect when people don’ turn on the smart features. 

The feeling of losing control may be accentuated when multiple users use an IoT product but they don’t have the same level of control over how it processes their personal information. Users who don’t have an account for the IoT product or are not the main user may find it difficult to get the relevant privacy information about the processing of their information, or to make choices or exercise their rights. If people don’t know how to exercise their rights, products may be sold on the secondary market or passed to others with the original owner’s personal information.

Personal data breaches relating to IoT products can often lead to financial or even physical harms. For example, people may become victims of fraud if their IoT product is hacked, or their home may be burgled if their smart lock’s security is breached. 

Personal information from IoT products is shared with many third parties because of the complex supply chain that is involved in creating and running IoT products. This complexity increases the risk that people will lose control over their personal information and experience unwarranted intrusion into their lives. 

Do we need to do a data protection impact assessment (DPIA)?

A DPIA is a tool you can use to identify and reduce the data protection risks of your processing activities. It can also help you design more efficient and effective processes for handling personal information.

DPIAs can determine the type of technical and organisational measures you need to ensure your processing complies with the data protection principles.

You must do a DPIA before you begin any type of processing that is “likely to result in a high risk”. You must screen for factors that point to the potential for widespread or serious effects on people.

Three types of processing always require a DPIA:

  • systematic and extensive profiling on which significant decisions are based;
  • large-scale use of special category data; and
  • large-scale monitoring of publicly accessible areas. 

We have published a list of processing operations where we have assessed there is likely to be a high risk and you must do a DPIA. You can find the full list in the DPIA guidance.

Most processing involving IoT products is likely to result in a high risk. This is because IoT products are often part of people’s private lives, processing information of a highly personal nature – for example, about their households, location, health, physiology, daily habits and relationships. This means that in most cases you must do a DPIA.  

Also, if you offer your IoT product or service to children, you must do a DPIA. Processing children’s information in this context is likely to result in a high risk, so is included on our list of processing operations that require a DPIA. If children are likely to access the product or service, you should refer to the Children’s code for information about conducting a DPIA. 

Read our guidance on DPIAs for more detail on when and how you should write one. 

The severity of harms that may arise may be greater than in other processing contexts. This is because of the volume and sensitivity of the personal information IoT products can process. 

How do we apply a data protection by design and default approach?

You must adopt a data protection by design and default approach. This means you must consider data protection and privacy issues upfront at the design stage and throughout the lifecycle of your IoT product and any associated service.

Data protection by design means you must put appropriate technical and organisational measures in place to implement the data protection principles effectively and safeguard people’s rights.

To do this, you should address each stage of your product’s lifecycle and ask yourself the following questions.

Planning, research and design of an IoT product

  • Do you need to use personal information?
  • What is the minimum personal information you need for your product to function?
  • Have you identified the most appropriate lawful basis for your processing?
  • Do you need to use special category information? What alternatives have you considered? Can you achieve your purpose in a less intrusive way?
  • Do you need to use profiling or automated decision-making?
  • Have you considered if children are likely to use your product? Have you considered what is in the best interest of a child? Have you made arrangements to process only the minimum personal information about children? Are you able to comply with the Children’s code?
  • Are multiple users likely to use your product? How will you give them choices about their personal information?
  • Have you considered what controls you may need in place if your product is sold on the secondary market or passed on?
  • Will your product involve working with any partner organisations? Have you established their roles (eg controllers, joint controllers or processors)? What do you know about their own compliance and what due-diligence checks will you make?
  • Are there any privacy-enhancing technologies (PETs) that could help you comply with your data protection by design obligations?
  • What risks could your users face from using your IoT product? What steps will you take to prevent your product harming people?
  • How will you embed data protection into your business model?
  • What security measures will provide appropriate protection for the information your product processes?
  • How will you enable people to exercise their rights? How can you do this for multiple users?
  • Have you consulted all relevant internal stakeholders, such as your legal team, designers, cybersecurity specialists, software developers and your DPO before launching the product? 

Launch of an IoT product 

  • Does your product offer strong privacy defaults, user-friendly options and controls, and respect user preferences?
  • Do you give people tools so they have meaningful control over how you use their personal information?
  • Do your communications use clear and plain language so your users can understand what you intend to do with their personal information?
  • Have you planned what to do if the launch leads to the processing of personal information you didn’t intend?
  • Is your customer support team able to respond to customer feedback after the launch? 

Post-launch of an IoT product

  • Are you monitoring for any potential privacy issues? Do you have policies in place for remedial action, and sufficient resources to carry it out?
  • Are you regularly updating your product with security patches to respond to new threats and vulnerabilities?
  • Are you aware of people using your product after launch in ways you didn’t expect? Have you planned how you’ll manage any emerging privacy implications?
  • Are you planning to release any updates for the product that may change how people’s information is used? Have you assessed if people’s expectations for privacy would change because of the update before doing so? Do you need to reconsider your lawful basis?

Our guidance on privacy in the product design lifecycle includes more detail on considerations for each phase of a product lifecycle. 

If your product is aimed at children or likely to be accessed by them, your IoT product’s settings must be set to ‘high privacy’ by default. You should collect and retain only the minimum personal information you need to provide the elements of your IoT product. You should refer to the Children’s code for a full list of what to consider

Further reading – ICO guidance

Data protection by design and default