Perform a security risk analysis
Home » IoT » Integrity and confidentiality » Perform a security risk analysis

According to the confidentiality principle, controllers should minimize the risks to data subjects’ rights, interests, and freedoms. To this purpose, they should work on a risk-based approach (see the “Integrity and confidentiality” section in the “Principles”, Part II of these Guidelines). The risk-based approach of data protection law requires controllers to comply with their obligations and implement appropriate measures in the context of their particular circumstances – the nature, scope, context and purposes of the processing they intend to do, and the risks this poses to individuals’ rights and freedoms. Their compliance considerations therefore involve assessing the risks to the rights and freedoms of individuals and taking judgements as to what is appropriate in those circumstances. In all cases, controllers need to ensure that they comply with data protection requirements and are able to show how they comply e.g. through documentation (see “Accountability” within “Principles, Part II of these Guidelines).

To manage the risks to individuals that arise from the processing of personal data in IoT systems, it is important that controllers develop a mature understanding and articulation of fundamental rights, risks, and how to balance these and other interests. Ultimately, it is necessary for controllers to assess the risks to individuals’ rights that the use of IoT poses, and determine how they need to address these and establish the impact this has on their use of IoT.[1] To this purpose, two key factors must be considered:[2]

  • Risks arising from the processing itself, such as the emergence of biases associated with profiling or automated decision-making systems.
  • Risks arising from the processing in relation to the social context and the side effects indirectly related to the object of processing that may occur.
Box 9:

For example, if an IoT application does not guarantee the security of information by means of security measures such as data encryption in the different states that the information goes through, we will be putting security at risk. Additionally, the encryption techniques must use internationally recognized algorithms considered secure and with a sufficiently long key.

In order to minimize such risks, controllers must ensure that appropriate technical and organizational measures are implemented to eliminate, or at least mitigate the security risk, reducing the probability that the identified threats will materialize, or reducing their impact. It is necessary to take into account the security standards that already exist in the market, as well as the compliance standards in relation to data protection that will apply to the IoT solution, such as the GDPR for data protection or PCI-DSS for transactions using payment cards. Furthermore, IoT developers should always remember that Article 32(4) GDPR clarifies that an important element of security is to ensure that employees accessing the data act only on instruction and as instructed by the controller (see the “Integrity and confidentiality” section of the “Principles” in Part II of these Guidelines).

Box 10:

For example, if the application includes a module to manage banking or payment data using credit/debit cards, it is necessary to take into account the standard PCI DSS. Additionally, if it is going to handle and process personal data it must be adapted to the regulatory framework operating in the territory, such as the GDPR in the European Union.

Some risk assessment mythologies already available:

  • CNIL:
  • ISO: ISO/IEC 29134

The general description of the technical and organizational security measures must become a part of the records of processing, where possible (Article 30(1) (g) for controllers, and 30(2) (d) for processors) and all implemented measures are part of the DPIA, as supporting remediation measures to limit risk. Finally, once the selected measures are implemented, the remaining residual risks should be assessed and kept under control. Both the risk analysis and the DPIA are the tools that apply.

As stated in the requirements and acceptance tests for the purchase and/or development of the employed software, hardware, and infrastructure, the risk evaluation and the decisions taken “have to be documented in order to comply with the requirement of data protection by design” (of Article 25 of the GDPR) (see “Data Protection by Design and by Default” section in the “Main Concepts” section, Part II of these Guidelines).

Finally, the controllers should always be aware that, according to Article 32(1) (d) of the GDPR, data protection is a process. Therefore, they should test, assess, and evaluate the effectiveness of technical and organizational measures regularly. Procedures that serve controllers to identify changes that would trigger the revisit of the DPIA should be created at this moment. Whenever possible, controllers should try to impose a dynamic model of monitoring the measures at stake (see the “Integrity and confidentiality” section in the “Principles” Part II of these Guidelines)

1ICO (2020) IoT auditing framework – draft guidance for consultation. Information Commissioner’s Office, Wilmslow, p.13-14. Available at: (accessed 15 May 2020).

2AEPD (2020) Adecuación al RGPD de tratamientos que incorporan Inteligencia Artificial. Una introducción. Agencia Espanola Proteccion Datos, Madrid, p.30. Available at: (accessed 15 May 2020).

Skip to content