6a Píldora Tecnológica ICAB: 'La evaluación de impacto en protección de datos'

Resumen: Desarrollo del PowerPoint  presentado en la ponencia organizada por la Sección de Derecho de las Tecnologías de la Información y la Comunicación del Ilustre Colegio de Abogados de Barcelona (ICAB), en colaboración con el capítulo de Barcelona de ISACA.

La evaluación de impacto en protección de datos (o mejor aún, en privacidad) más conocida por su denominación inglesa: Privacy Impact Assessment o PIA, es una metodología para evaluar el impacto en la privacidad de un proyecto ya sea éste para diseñar un proceso de negocio, servicio, producto, dispositivo, App o cualquier iniciativa que implique tratamiento de datos personales, de forma que se puedan adoptar las medidas necesarias para evitar o minimizar posibles riesgos que pudieran afectar a esos datos. Es la consecuencia de aplicar el concepto de Privacidad en el Diseño (Privacy by Design) e incorpora instrumentos que hasta hace poco se utilizaban más en el entorno tecnológico, como el análisis y gestión de riesgos.

 ÍNDICE

1. Introducción
2. Concepto de privacidad
3. Introducción a la PbD
4. Factores de calidad en el diseño de un servicio
5. Evaluación de impacto en la privacidad
6. Bibliografía consultada

1. Introducción

La humanidad avanza cada vez más rápido. El progreso es un fenómeno imparable que viene propiciado por un efecto multiplicador, una interacción cruzada,  entre todos los estudios e investigaciones que tienen, y han tenido, lugar en el mundo.  E Internet, con su inmediata visibilidad global, actúa como un catalizador.

 

 

En este contexto, debemos evitar que el progreso vaya exclusivamente en favor del beneficio económico. No podemos ignorar a la humanidad que, a la postre, somos todos.

Precisamente evitar que esta finalidad económica, pese a ser licita y la razón de ser para la creación de la mayoría de empresas, se persiga a cualquier precio, es que aparece un binomio indivisible: Innovación y derechos humanos.

Debe buscarse una relación de equilibrio que no sea un freno para los avances tecnológicos, pero tampoco sea una violación continuada del largo camino que se ha necesitado para consolidar y proteger los derechos de las personas.

2. Concepto de Privacidad

 

Para ir entrando en materia, vamos a ver qué derechos fundamentales intervienen en el concepto de privacidad, circunscrito en la era digital:

 

• El derecho a la intimidad: Es el que protege todos aquellos aspectos concernientes a la vida privada de un individuo, los cuales tiene derecho a que no trasciendan a terceros.
• El derecho a la protección de datos: Es el que garantiza a los individuos el control y la libre disposición de sus datos personales, sean íntimos o no.

 

En el mundo actual, al estar nuestra intimidad  cada vez más digitalizada, la esfera íntima de las personas comprende cada vez un mayor número de datos personales. No es de extrañar, en este contexto, que se diluyan los límites entre el derecho a la intimidad y el derecho a la protección de los datos de carácter personal, siendo cada vez más los que designamos por “privacidad” a la conjunción de ambos derechos fundamentales.

3. Introducción a la PbD

 

Ann Cavoukian ha sido hasta julio de 2014 Comisionada de información y privacidad de Ontario (una de las 10 provincias del Canadá). Es Doctora en psicología, con especialización de postgrado en criminología y Derecho. Introdujo el concepto que se conoce como Privacy by Design – Privacidad desde el Diseño (PbD), que busca una relación win-win (ganar-ganar) en los nuevos proyectos que sean susceptibles de incorporar datos personales.

Esta relación win-win está en la línea del binomio (innovación, derechos de las personas) que hemos visto al principio.

 

 

En el ciclo de vida de los servicios (y los procesos, sistemas telemáticos, Apps… que los soporten) se puede actuar de dos formas:

 

• Antes: actuar de forma proactiva respecto a la privacidad permitirá integrar ésta en el proceso de diseño evitando costosas rectificaciones posteriores (en la misma fase de aceptación del proyecto o posteriormente, mediante RFC, en la gestión de cambios) debido a no haberla tenido en cuenta.
• Después: se corre el riesgo de propiciar un rechazo por parte de los actuales y futuros clientes y/o usuarios, dañando de forma irremediable la imagen de la empresa.

En consecuencia, el enfoque basado en la PbD aumenta la eficacia y la eficiencia del proyecto.

NOTA DEL EDITOR: En esta ponencia cuando hablo de diseñar un Servicio o Producto, me estoy refiriendo en sentido amplio a diseñar cualquier iniciativa susceptible de tratar datos de carácter personal. Puede ser un Servicio, un Proceso de Negocio (B.P.), software (App), un dispositivo telemático inteligente, un sistema de telecomunicaciones…

De los 7 principios hay dos que destacan, considerándose como el techo y los cimientos de la construcción en la que se encuentran los demás:

 

• Respeto por el individuo: El interés del individuo (normalmente en calidad de usuario) siempre ha de estar presente en el diseño de servicios, por ejemplo mediante previsión de medidas de seguridad, mensajes informativos, opciones “user-friendly”, privacidad por defecto…
• Suma positiva (sostenibilidad del proyecto): “Funcionalidad” y  “privacidad” no han de ser necesariamente características excluyentes sino que ambas han de estar garantizadas e integradas en cualquier servicio desde la fase del diseño. Pensemos que los usuarios no usarán aquellos servicios en los que no confían y a la larga desaparecerán. Los servicios que atentan a los derechos fundamentales de las personas, no pueden considerarse sostenibles.

Los cinco principios restantes, consecuencia de los anteriores, son:

 

• Proactivo no reactivo / preventivo no correctivo: La privacidad por diseño se anticipa a los riesgos sobre los datos personales, identificándolos, evaluándolos y tratándolos mediante la adopción de medidas encaminadas a evitar que se materialicen durante la transición y operación del servicio.
• Privacidad por defecto: Cualquier sistema ha de estar configurado de forma que por defecto otorgue una mayor protección a la privacidad de las personas. Un ejemplo es evitar que se comparta la información del usuario salvo que éste realice una acción voluntaria claramente identificada (Consentimiento informado: “Qué, con quién y cuándo”).
• Privacidad embebida en el diseño: La protección de la privacidad ha de estar integrada en el servicio desde el momento en que se diseña, sin que ello disminuya su plena funcionalidad. No se trata de una opción que se añade a posteriori sino que, al contrario, es uno de sus componentes integrales.
• Visibilidad y transparencia: La entidad que gestiona el servicio que trate datos personales ha de estar sujeta a los “términos y condiciones” y “políticas de privacidad” informados desde un principio y que no deberían modificarse sin el previo consentimiento del usuario afectado. También debería estar sujeta a una verificación independiente.
• Seguridad “end to end”: La protección de la información se ha de configurar desde el momento en que se recaban los datos, y durante todo el ciclo de vida del servicio que los trata, hasta que éste es retirado y éstos sean utilizados para un nuevo servicio o destruidos. En este último caso se garantizará también que se eliminen de forma segura y confidencial, respetando los periodos de retención establecidos.

 

En una organización, existen diferentes actores involucrados con diferentes responsabilidades en privacidad:

 

• El DPO (Data Protection Officer) establece las políticas de privacidad, generales y orientadas a los tratamientos de datos personales consecuencia de determinados servicios.
• La Alta Dirección crea y avala la cultura de privacidad en la empresa mediante la ratificación y promulgación de políticas.
• Los propietarios de los servicios (o los responsables de los productos) definen los requisitos de privacidad. Para ello se dirigen al DPO para orientarse y éste les informa de cuánto les afecta a su servicio concreto. Periódicamente, y como requerimiento legal, el DPO auditará el cumplimiento de los principios de privacidad en los diferentes servicios.
• El equipo de proyecto redacta las especificaciones necesarias para poder implementar o producir el servicio o producto diseñado. Integrará los requisitos de privacidad facilitados por el propietario del servicio o producto quién, periódicamente  revisará, y aprobará si  procede,   la conformidad de las especificaciones.

4. Factores de calidad en el diseño de un servicio

 

En las diapositivas que siguen concretaré un poco más los considerandos que intervienen en el diseño, a través de los factores que afectan a su calidad, intentando ver donde encaja la privacidad.

Los factores que afectan a la calidad en el diseño de un servicio, App o sistema telemático, podemos contemplarlos desde dos puntos de vista diferentes:

 

• La calidad que percibe el usuario
• La calidad interna  

 

A simple vista da la sensación que relacionados con la privacidad (derecho a la intimidad y derecho a la protección de datos) hay un único factor en cada grupo.

 

• A nivel de usuario: Por un lado la “privacidad” tal como la percibe el usuario del servicio (recabado de datos personales a partir del consentimiento informado, información clara y explícita de la finalidad de los tratamientos que se aplicarán sobre los datos personales recabados…).
• A nivel interno: Los atributos de la seguridad de la información tratada por el servicio (confidencialidad, integridad y disponibilidad).

Ambos factores están relacionados ya que la privacidad se apoya, entre otras, en la gestión de la seguridad de la información, como se dispone en el Título VIII del RD 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la LO 15/1999, de 13 de diciembre, de protección de datos de carácter personal

Si lo analizamos con detenimiento, aparecen más relaciones:

 

• El factor de calidad interna “configurabilidad” afecta también a la privacidad en cuánto permite ajustarla a los requerimientos de cada usuario, dando cumplimiento así a uno de los siete principios de la PbD, concretamente a la  privacidad por defecto en el diseño de servicios que se ha visto antes.
• El factor de calidad interna “seguridad de la información” afecta a la confiabilidad, en tanto ningún usuario confía en un servicio que no es confidencial respecto a sus datos personales, no garantiza su integridad y no asegura la disponibilidad de los mismos cuando se necesitan.
• El factor de calidad interna “portabilidad” afecta a la privacidad como se recoge en el artículo 18 del borrador del nuevo Reglamento General de Protección de Datos de la UE (RGPDUE). Concretando un poco más, la ratio legis de ese artículo es garantizar que se pueda seguir dando cumplimiento a los derechos ARCO en el nuevo entorno operativo.

5. Evaluación de impacto en la privacidad

Para poder integrar la privacidad en el diseño del servicio, es necesario poder evaluar el impacto detallado de todos los elementos que lo constituyen, los procesos en que se organiza, las infraestructuras que le dan soporte, etc.

Para ello existe, no una herramienta, sino un completo proceso conocido como Privacy Impact Assessment (PIA), que será obligatorio a partir de la entrada en vigor del nuevo Reglamento General Europeo de Protección de Datos (RGEPD).

Dividiremos el proceso de elaborar un PIA en cinco fases, cada una de ellas constituida por diferentes actividades:

 

Fase 1 (Preliminar)

Ésta fase está constituida por tres actividades:

 

• Elaborar el Plan de Proyecto: En el constarán claramente especificados los objetivos generales del proyecto y su alineación con los de la organización, el alcance y la magnitud del proyecto, los vínculos con otros proyectos y algunos elementos clave de privacidad.
• Cumplimentar el PTA: Un  Privacy Threshold Analysis – Análisis de Umbral de Privacidad (PTA) consiste  en un análisis previo basado en un sencillo documento de pocas hojas y pensado para profanos, que se utiliza a modo de “check-list”. Son pocas preguntas que solo admiten SI o NO como respuesta. A partir de un 10% afirmativo debe efectuarse un PIA.  Si el umbral es mucho mayor, entonces se aconseja el PIA  completo.
• Recopilar documentación del proyecto: En ésta fase temprana se inicia la recopilación y gestión documental de toda la información relacionada con la privacidad en el servicio  la cual ayudará a desarrollar el PIA con éxito.

Fase 2 (Preparación)

El propósito de ésta fase es fijar la estrategia y la táctica para que la crítica “fase 3 (consultas y análisis)” pueda llevarse a cabo sin problemas. Está constituida por tres actividades:

• Diagrama de los flujos de información: Se describen y dibujan en esta actividad los flujos de información de naturaleza personal que se tratarán durante la operativa del servicio o producto.
• Estrategia y plan de consultoría: Se definen las diferentes “partes interesadas” del proyecto y se elabora un plan de consultoría para poder recabarles toda la información necesaria. Debe entenderse por partes interesadas a las internas de la propia organización: Accionistas, Comité de Dirección, empleados en general…, y a las externas: Clientes, distribuidores, proveedores, aseguradoras, reguladores, grupos gremiales, asociaciones profesionales, grupos de opinión…
• Constitución del PCG: En función de la magnitud del proyecto, se constituirá un PIA Consulting Group – Grupo consultor del PIA (PCG), normalmente multidisciplinario que se encargará de apoyar y colaborar en el desarrollo del PIA.

Fase 3 (Consultas y análisis)

A partir del marco de trabajo definido en la “fase 2”, conviene centrarse en las diferentes consultas a las partes interesadas, analizar el posible impacto del proyecto de servicio en la privacidad y modularlo mediante un análisis de riesgos. Esta fase nos dará los recursos para poder encontrar y aplicar soluciones que permitan mitigar los problemas para la privacidad que hayan podido aflorar.

Está constituida por tres actividades:

 

• Consultas y auditorías: En base a entrevistas y auditorías, siguiendo el plan definido en la “fase 2”, se recopila toda la información de detalle en el proyecto desde diferentes puntos de vista en el ámbito de la privacidad. Se acaban de perfilar, confirmándolos con evidencias, los diagramas de flujo de información que hemos dibujado en la fase anterior.
• Identificación y análisis de impacto en la privacidad: Se identifican las amenazas que pueden aprovechar vulnerabilidades del servicio proyectado y se analiza y evalúa su impacto en la privacidad (Algo parecido al catálogo de amenazas de Magerit 3.0, pero orientándolas a los IPP (Information Privacy Principles). Se evalúa también la probabilidad de que las amenazas sobre la privacidad se materialicen.
• Evaluación y tratamiento de riesgos: Partiendo del impacto y probabilidad de ocurrencia de las amenazas se calcula el valor de los diferentes riesgos y, una vez obtenidos, se decide cómo van a tratarse.

Fase 4 (Documentación)

Si bien la documentación se genera y mantiene a lo largo de todas las fases del PIA, es en ésta donde se elabora el informe final.

Está constituida por una actividad:

• Elaboración del informe PIA: Se trata de un informe resumen que abarca todas las etapas anteriores y finaliza con un apartado de recomendaciones. Una opción adicional, motivada por el delicado equilibrio entre seguridad y transparencia, consiste en editar una versión simplificada del informe PIA (tipo informe ejecutivo) que, sin desvirtuarlo, permita hacerlo público. Esta actitud de transparencia  aporta beneficios a la imagen de la organización y confianza a todas las partes interesadas.

Fase 5 (Revisión y auditoría)

El propósito de esta fase es asegurar que las nuevas características de diseño que surgen del PIA se implementen y sean efectivas.

Está constituida por dos actividades:

 

• Auditoría post-PIA: Se trata de revisar el proyecto para asegurar que se incorporen en el diseño las recomendaciones del PIA, basadas en no conformidades con los principios de privacidad de la regulación vigente en materia de protección de datos y demás leyes asociadas.
• Seguimiento periódico: Se tendrá en cuenta el Ciclo de Vida del proyecto, ajustando el PIA a las futuras variaciones del mismo. Como dispondremos de toda la documentación concerniente al efecto del diseño en la privacidad, mantenerlo no debería representar mayor dificultad.

 

Para poder elaborar el análisis de impacto en la privacidad, necesitaremos apoyarnos en los diagramas de flujo, que previamente habremos elaborado, sobre la información personal tratada en los servicios, procesos, Apps o dispositivos.

Una posible técnica puede ser descomponerlos en actividades o tareas. Se trata de algo sustancial que debe desarrollarse con sumo rigor ya que los “olvidos” podrían ocultar vulnerabilidades importantes que desvirtuaran los resultados finales obtenidos.

Para cada uno de estos elementos, evaluaremos más adelante que impacto puede llegar a representar para cada uno de los diferentes principios de la privacidad.

En el análisis de riesgos del PIA, manejaremos unos cuantos conceptos que es importante comprender y relacionar entre ellos previamente.

Para una mejor claridad, trazaremos una relación ontológica entre ellos:

Las amenazas aprovecharán vulnerabilidades de nuestro diseño de proceso de negocio, servicio, sistema o dispositivo, para producir un impacto en la privacidad. Afortunadamente la ocurrencia del impacto no es segura, sino que dependerá de la probabilidad de que suceda. La combinación de ambos factores, probabilidad e impacto es lo que nos dará el riesgo.

Este riesgo, en el caso de evaluaciones de privacidad, se entiende referido a la vulneración de los diferentes IPP (Principios de Privacidad de la Información).

Para obtener resultados comparables, se debe fijar un sistema de medición con escalas armonizadas entre todas las variables que intervienen.

 

En este caso por simplicidad, y como suele hacerse habitualmente en la práctica, utilizaremos escalas cualitativas, que son más intuitivas, frente a las cuantitativas.

Primero obtendremos el impacto que podría llegar a producirse en los principios de privacidad de la información (IPP), para cada una de los elementos en que se ha descompuesto antes el flujograma. En consecuencia, dibujaremos una tabla donde en un eje estén los IPP y en el otro los diferentes elementos (E1, E2, E3… En).

Para cada principio, según el elemento considerado, analizaremos el impacto que se produciría, como consecuencia de materializarse las posibles amenazas relacionadas. Podría considerarse  bajo, medio, alto, muy alto o simplemente “no aplica”.

A continuación haremos lo mismo pero en vez de evaluar el impacto, evaluaremos la probabilidad de ocurrencia.

Obtendremos una tabla distinta. A partir de ambas, se podrá obtener el riesgo.

Para hacerlo intuitivamente utilizaremos una tabla que propone la metodología MAGERIT, que es un método formal para analizar los riesgos que soportan los Sistemas de Información y para recomendar las medidas apropiadas que deberían adoptarse para tratar y controlar esos riesgos, muy extendida en las AAPP, especialmente en la adecuación al Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica (ENS).

 

 

Se trata de una tabla de doble entrada en la que, eligiendo el valor obtenido en la estimación del impacto por la parte izquierda, y eligiendo el valor obtenido en la estimación de la probabilidad de ocurrencia en su parte superior, en su intersección se  encuentra el valor del riesgo.

Se repetirá el método de cálculo para cada una de las casillas de la tabla. Ya se intuye que, en esta parte de naturaleza mecánica y repetitiva, es una buena idea ayudarse de una herramienta o plataforma telemática especializada en riesgos.

Cuando tengamos la tabla completa, deberíamos ordenar todos los riesgos obtenidos por su valor (de mayor a menor) dándonos una idea clara del orden por el que hemos de empezar a controlarlos.

 

Un concepto muy utilizado en gestión de riesgos es el apetito de riesgo. No es otra cosa que el umbral de riesgo que la organización está en condiciones de asumir. Así las cosas, como precisa el grupo de trabajo del artículo 29 en su Declaración wp218, nunca debería asumirse un nivel de riesgo que conculcara principios fundamentales de la privacidad.

Para cada riesgo por encima del umbral definido, por ejemplo “muy bajo”, debe decidirse si se evita (se elimina la funcionalidad), se trata aplicando controles o medidas que lo mitiguen (rediseño) o bien se ignora (se deja como está). Ésta última opción debe justificarse claramente.

Como el tratamiento del riesgo será lo habitual, remito a la Guía de la AEPD sobre la “Evaluación de Impacto en la Protección de Datos”, donde se indican para los diferentes Principios de Privacidad de la Información (IPP), los riesgos más frecuentes y las medidas para mitigarlos.

6. Bibliografía consultada

- AEPD (Agencia Española de Protección de Datos). “Guía para una Evaluación del Impacto en la Protección de Datos Personales (EIPD)”. Octubre de 2014.

Guía para EIPD

- ICO (Information Commissioner’s Office). “Privacy Impact Assessment Handbook version 2.0”. June 2009.

PIA handbook

- ICO (Information Commissioner’s Office).  “Conducting privacy impact assessments code of practice”. Based about UK Data Protection Act.

Conducting PIA

- Varios autores (entre los que me incluyo). “Reflexiones sobre el futuro de la privacidad en Europa – Capítulo 2: Privacy Impact Assessment y Privacy by Design”. Noviembre de 2013. DPI-ISMS Forum Spain.

Capítulo 2 – PIA y PbD

- José Luis Colom Planas. “Consideraciones teórico-prácticas sobre el proceso de elaborar un PIA”. Blog “Aspectos Profesionales”. 13 de abril de 2014.

Consideraciones PIA
 

- José Luis Colom Planas. “Modelos de cumplimiento legal y apreciación del riesgo”. Blog del Consejo General de la Abogacía Española, gestionado por ENATIC. 22 de diciembre de 2014.

Blog CGAE/ENATIC

 

 

Twittear