martes, 16 de diciembre de 2014

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, 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 inteligente, un sistema…


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 o producto, 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. Se trata de una actividad sustancial que debe desarrollarse con sumo rigor ya que los “olvidos” podrían ocultar vulnerabilidades importantes que desvirtuaran los resultados finales obtenidos.
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 la propia organización (Accionistas, Comité de Dirección, empleados en general…), 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.
  • Análisis de impacto en la privacidad: Se identifican las vulnerabilidades del servicio o producto proyectado y se analiza su impacto en la privacidad. Algo parecido a los controles del anexo 1 de la norma ISO 27001. Un primer y sencillo filtro pueden ser los IPP (Information Privacy Principles), que si bien el borrador del RGPDUE no los recoge específicamente en un anexo como otras legislaciones de protección de datos  (Inglaterra -Data Protection Act 1998-, Victoria, Nueva Zelanda…) que vienen utilizando PIAs en la actualidad, pueden servir como una primera aproximación como veremos más adelante.
  • Análisis y Gestión de riesgos: Partiendo del anterior análisis de impacto, se evalúa la probabilidad de que las amenazas sobre la privacidad se materialicen.

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.
  • 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 si el impacto que se produciría, como consecuencia de materializarse los posibles riesgos relacionados, 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 informá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

 


 

sábado, 6 de diciembre de 2014

Comentarios a la SAN que resuelve como lícita la inspección del móvil de un alumno por parte del director de un centro escolar


Resumen: Se analiza jurídicamente la Sentencia de la Audiencia Nacional,  de 26 de septiembre de 2013, desde el punto de vista de la protección de datos y como colisión de derechos fundamentales.


Autor del artículo
Colaboración
José Luis Colom Planas
 
Actualizado
 
6 de diciembre de 2014
 

ÍNDICE
1. Introducción
2. Resumen de los antecedentes de hecho
3. Valoración basada en la legislación en materia de protección de datos
4. Valoración basada en la colisión de derechos fundamentales
5. Conclusiones
6. Bibliografía consultada
7. Derechos de autor
 
1. Introducción

La Sentencia de la Audiencia Nacional, objeto de este estudio, presenta una serie de peculiaridades que la hacen muy atractiva desde un punto de vista jurídico:
 
  • En primer lugar resuelve la legitimación del “tratamiento” de los datos personales en el Smartphone del alumno, por parte del director del colegio, basándose en la anulación del artículo 10.b del RD 1720/2007. En consecuencia resulta de aplicación directa el artículo 7.f de la Directiva 95/46/CE.
  • Se trata también de un caso de colisión entre derechos fundamentales de las personas, que exige discernir cuál de ellos debe prevalecer. Si bien la SAN no entra directamente en éstas valoraciones, yo sí que lo haré aquí.

2. Resumen de los antecedentes de hecho

Como resumen de lo acaecido en el colegio diré que a partir de la denuncia de una alumna de la misma clase que alegaba que el compañero le mostraba, sirviéndose de un Smartphone, vídeos “de mayores” que la importunaban, el director del centro junto a un informático de plantilla exigieron al alumno el pin y accedieron a los vídeos e histórico de navegación, inspección que corroboró las afirmaciones de la niña.

Pese a ser mi área de especialización, considero muy pobre  valorar esta Sentencia exclusivamente en relación a la protección de datos personales. Como he manifestado en la introducción debería de valorarse también como una colisión de derechos fundamentales. Pasemos a analizar ambos planteamientos:

3. Valoración basada en la legislación en materia de protección de datos

La justificación de la Sala de lo Contencioso-Administrativo (Sección primera) de la Audiencia Nacional, se basa en el artículo 10 “Supuestos que legitiman el tratamiento o cesión de datos” del RD 1720/2007, de 21 de diciembre, que es el reglamento de aplicación de la LOPD.

El tribunal recuerda la divergencias de traducción o interpretación en el proceso de transposición  de la Directiva europea 95/46/CE sobre el artículo 10.2.b del RD 1720/2007. Como consecuencia de la STJUE de 24 de noviembre de 2011, en España la STS de la sala 3ª de 8 de febrero de 2012 lo anuló por no ser conforme al artículo 7.f de la Directiva europea. Desde entonces, el referido artículo de la Directiva pasa a tener aplicación directa al ordenamiento jurídico español.

Para aquellos que no estén al corriente del efecto de tal anulación, a partir de ese momento ya no es posible afirmar que para que el tratamiento de datos personales sea lícito es necesario, cuando no conste el consentimiento del titular (ni concurran otros supuestos de excepción previstos en los artículos 6.2 y 11.2 de la LO 15/1999), que los datos consten en fuentes accesibles al público.

Dicho artículo 7.f de la Directiva establece dos únicos requisitos acumulativos para legitimar un tratamiento:
 
  • La necesidad de satisfacer un interés legítimo. En éste caso se satisface un interés legítimo como lo es el de preservar a una menor, y quién sabe si a los demás compañeros, de los efectos de una agresión moral.
  • Que no prevalezcan derechos y libertades fundamentales del interesado. Para analizar la prevalencia de derechos cabría decir que el ataque a la moral pública mediante pornografía, especialmente si tiene como destinatario a la infancia, cobra una intensidad superior según STC de 15 de octubre de 1982. 

4. Valoración basada en la colisión de derechos fundamentales

Otra forma de estudiar este procedimiento es basándose en el conflicto de derechos fundamentales. Sabemos que los derechos no son absolutos y tienen límites que al colisionar deben ponderarse eludiendo reglas generales. Se evaluará cada caso en función de sus circunstancias concretas.

Los derechos en conflicto son por un lado el derecho a la protección de datos y a la intimidad personal, y por otro el derecho a la educación y a la integridad moral. Todos derechos fundamentales recogidos en la Parte Dogmática de la Constitución o de creación jurisprudencial. Deberemos discernir cuales deben prevalecer.

Si los analizamos con detalle:
 
  • El derecho a la protección de datos es el que garantiza a un individuo el control y la libre disposición de sus datos personales.
  • 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 educación Es el que garantiza el pleno desarrollo de la personalidad humana en el respeto a los principios democráticos de convivencia y a los derechos y libertades fundamentales.
  • El derecho a la integridad moral junto al derecho a la integridad física, son consecuencia del derecho a la vida plena, como se deduce del artículo 15 de la CE.

A la luz de amplia jurisprudencia constitucional y de variada doctrina sobre el carácter no ilimitado del derecho a la intimidad y el derecho a la protección de datos en su colisión con otros derechos fundamentales un criterio, que ha aplicado varias veces el TS para comprobar si una medida restrictiva de un derecho fundamental supera el juicio de proporcionalidad, es constatar que cumpla los tres siguientes requisitos o condiciones:
 
  • Juicio de idoneidad: Si tal medida es susceptible de conseguir el objetivo propuesto.
  • Juicio de necesidad: Si, además, es necesaria en el sentido de que no exista otra medida más moderada para la consecución de tal propósito con igual eficacia.
  • Juicio de proporcionalidad en sentido estricto: Y, finalmente, si la misma es ponderada o equilibrada, por derivarse de ella más beneficios o ventajas para el interés general que perjuicios sobre otros bienes o valores en conflicto.

Aplicando el juicio de proporcionalidad al caso que nos ocupa, obtenemos:
 
  • La medida fue idónea ya que su visualización sirvió para comprobar el contenido inadecuado de las imágenes y evidenciar que efectivamente fueron visionadas.
  • La medida fue necesaria, ya que no existía otra posibilidad más moderada para evidenciar los hechos. Recordemos que se hizo en presencia de un técnico informático que, si bien no era un perito, de forma dirigida solo buscó el material concreto objeto del conflicto. Está claro que no sirve como prueba pericial porque no se hizo en presencia de un secretario judicial o notario que certificara la preservación de la cadena de custodia, pero pensemos que se trataba de un menor en el centro educativo y a mi juicio los acontecimientos nunca deberían haber llegado tan lejos.
  • La medida fue proporcional en sentido estricto ya que si bien el acceso a datos personales puso en evidencia una faceta concreta del niño, hemos de recordar que la función del centro educativo es educar, es decir, corregir conductas inapropiadas a la edad, a la vez que preservar los valores y la afectación moral de los compañeros menores de edad. Quizá, dado que no existía el apremio de la urgencia, se hubiera podido retener el móvil al alumno y avisado a los padres para inspeccionarlo en su presencia contando con su consentimiento expreso (recordemos el artículo 13.1 del RD 1720/2007 tratándose de un menor), aunque vista a posteriori la actuación de éstos, podría presumirse que se negaran a su visionado.

5. Conclusiones

Mediante ambos planteamientos vemos que se llega a la misma legitimación de las actuaciones. En consecuencia, podemos concluir que la sentencia de la AN está bien fundada.

Ya que en esencia se trata de un conflicto entre derechos fundamentales  sería posible, una vez agotada la vía judicial previa,  solicitar sea admitido a trámite un hipotético recurso de amparo ante el TC.

No es aventurado afirmar sin embargo que  según lo analizado aquí, basado en mi personalísima opinión, aún en el supuesto de que efectivamente fuera admitido a trámite el recurso ante el alto tribunal el fallo de la sentencia sería, con toda probabilidad, acorde al de la AN y, en consecuencia, se desestimaría el amparo.

6. Bibliografía consultada

- Audiencia Nacional. Sala de lo Contencioso-Administrativo. Sección Primera. “Sentencia del recurso 481/2012”. 26 de septiembre de 2013.
SAN a 26 de septiembre de 2013







7. Derechos de autor

Imágenes bajo licencia 123RF internacional.

 

La presente obra y su título están protegidos por el derecho de autor. Las denominadas obras derivadas, es decir, aquellas que son el resultado de la transformación de ésta para generar otras basadas en ella, también se ven afectadas por dicho derecho.

 

Sobre el autor:

 

José Luis Colom Planas Posee un doble perfil, jurídico y tecnológico, que le facilita el desempeño profesional en el ámbito de la privacidad: Ha cursado Ingeniería técnica de Telecomunicaciones en “la Salle BCN” estando adscrito a la AEGITT (Asociación Española de Graduados e Ingenieros Técnicos de Telecomunicación). También ha realizado el postgrado de Especialista Universitario en Protección de Datos y Privacidad en la Facultad de Derecho de la Universidad de Murcia.

Ha estudiado “El delito de blanqueo de capitales en nuestro Código Penal” en la UOC, en colaboración con el Ilustre Colegio de Abogados de Barcelona (ICAB). Ha participado en la I Jornada internacional sobre blanqueo de capitales organizada por la Escuela de Postgrado; Facultad de Derecho de la UB. Realizando el programa ejecutivo de Controller Jurídico (Compliance Officer), en la escuela legal de Wolters Kluwer Formación.

Es auditor y consultor empresarial especializado en cumplimiento, protección de datos,  y gestión de la seguridad de la información.  A partir de su dilatada experiencia, edita el Blog temático “Aspectos Profesionales”.

Dispone de la certificación CDPP (Certified Data Privacy Professional) del ISMS Fórum Spain. Es Auditor e Implantador SGSI (Gestión de la Seguridad de la Información) por AENOR (Asociación Española de Certificación y Normalización). Leader Auditor ISO 27001& implanter ISO 22301 by BSI (British Standards Institution). Auditor del esquema de certificación STAR para prestadores de servicios de Cloud Computing (BSI + Cloud Security Alliance). Ha obtenido la certificación internacional CISA (Certified Information Systems Auditor) by ISACA (Information Systems Audit and Control Association). Dispone de las certificaciones ISO 20000 PMI (Process Management Improvement) e ITIL Service Management by EXIN (Examination Institute for Information Science).
Es asociado sénior de la APEP (Asociación Profesional Española de Privacidad), miembro de ISACA (Information Systems Audit and Control Association), miembro de ISMS Forum Spain (Asociación Española para el Fomento de la Seguridad de la Información), miembro de itSMF (IT Service Management Forum), ATI (Asociación de Técnicos de Informática) y ENATIC Abogacía 2.0 (Asociación de expertos nacionales de la abogacía TIC), habiendo sido ponente o colaborado en casi todas ellas. También es colaborador de la iniciativa del Observatorio Iberoamericano de Protección de Datos.
 
 
NOTA DEL EDITOR: Este artículo ha sido publicado por primera vez en el boletín nº 10 (Abril 2014) de APEP Informa y en el blog desarrollado por ENATIC en el Consejo General de la Abogacía Española.