Novedades del nuevo GDPR en Cloud Computing: ¿más sombras que luces?
- Lorena P. Campillo
Debido a nuevos fenómenos como Cloud Computing, la UE se preguntó si la legislación actual en materia de protección de datos, es decir, la Directiva de hace 15 años, era suficiente para hacer frente a la era digital.
Y, como fruto de esa preocupación, surgió el nuevo Reglamento que no será vigente hasta 2018. Mar España, directora de la AEPD, hace unas semanas, nos anunciaba que a primeros del 2017 se podría ver el anteproyecto de la LOPD, y, además, adelantó dos principios básicos: la concienciación y la prevención en esta nueva etapa. Principios que se extenderán al ámbito de la privacidad en Cloud Computing.
El vicepresidente para el mercado único digital, ya sostuvo hace unos años que la protección de datos estaría en el centro del mercado único digital y que construía una base sólida para ayudar a Europa a hacer un mejor uso de la tecnología digital innovadora en servicios como Big Data y Cloud Computing.
Todo bien hasta aquí, pero, vayamos al grano; ¿cómo ha resultado el texto de cara a Cloud Computing? A priori, advertimos desde un primer momento, la ausencia acusada de alusión expresa por parte del legislador europeo respecto a la figura del encargado cloud –o proveedor cloud-, alusión totalmente necesaria. No se dice nada cuando debería, más aún, después de todo el bombo que se ha dado este tiempo atrás. Pero, aunque no haya referencia expresa veamos cuáles serán los elementos de esta nueva fórmula que aplicaríamos.
La rendición de cuentas “Accountability”
Se trata de una novedad muy bien recibida. ¿En qué consiste? Se ejecuta por ejemplo a través de la designación del DPO (delegado de protección de datos), de la evaluación de impacto, o los códigos de conducta y certificaciones. Implicarán auditorías y dirigirse a las autoridades de control europeas. El proveedor cloud será responsable “obligatoriamente” y solidario respecto a las brechas de seguridad o tratamientos ilegales de datos personales. Quien elige los medios, por regla general, es decir, el objeto o la duración son los proveedores cloud; en cambio es el cliente el que elige qué datos se ponen en cloud. El problema es que los conceptos de responsabilidad, de riesgo y de los sujetos obligados (según sean SaaS o Iaas) no quedan delimitados ni distinguidos. No todos los proveedores cloud son iguales, y, por tanto, sus servicios e implicación en el tratamiento de los datos y privacidad (en ciclo de vida del dato) serán diferentes. Hay proveedores IaaS que no procesan datos personales, solo ponen el “alquiler” de la infraestructura, pero para el RGPD serían “encargados de tratamiento” y, por tanto, adquirirían todas las nuevas obligaciones, mientras que el cliente es quien toma las medidas como cifrado o realización de backups. El artículo 26.2, les obligaría a incluir estas medidas como suyas en los contratos. Kuan Hon (University Mary Queen, Londres) considera acertadamente que puede convertirse en un “sacacuartos” para los titulares de derechos que reclamen “solidariamente” a los proveedores gigantes y adinerados, más que una verdadera protección. No parece muy lógico.
Tampoco queda claro qué aspectos comprende la responsabilidad objetiva por incumplimiento. ¿Se requiere la toma de medidas adecuadas a la situación individual o bastan las medidas razonables para los estándares del sector Cloud Computing? ¿Cómo se cuantifica y divide la responsabilidad solidaria entre encargado y responsable? Se necesitaría definición del riesgo en función del grado y probabilidad.
Por otro lado, no es clara la definición del “riesgo”, y es peligroso no poder diferenciar los conceptos de “riesgo” y el “alto riesgo”. Este enfoque sería útil porque ayudaría a las organizaciones y a los reguladores a “priorizar”.
Códigos de conductas, certificaciones y sellos
Supondrán mejores prácticas para operaciones como las transferencias internacionales (art. 46). Además, también, supondrán una importante ventaja competitiva para clientes y proveedores, ya que transmitirán transparencia y confianza. Pero, ¿cuál es el “pero”?
No se desarrollan en el reglamento lo suficiente las instrucciones expresas y concretas incentivadoras. Tampoco se estableció qué certificadores externos lo realizarían. Que las agencias europeas sean certificadoras y, a la vez, sancionadoras, no es buena idea.
“Privacy by desing” o privacidad desde el diseño
La creadora de este concepto, Ann Cavoukian, en los años noventa, ya decía que sería cuestión de tiempo que la legislación y regulación fuera insuficiente para poder proteger la privacidad en un contexto de creciente complejidad e interconectividad de las Tecnologías de la Información. Así que desarrolló el concepto de privacidad por diseño o privacidad por defecto. El concepto de privacidad por diseño sugiere que las organizaciones creen sistemas que desde sus etapas iniciales de concepción consideren la privacidad. Y ofrezcan, de esta forma, una respuesta proactiva y prescriptiva que esté integrada en el tejido propio de la organización. Así, por ejemplo, el proveedor Microsoft usa herramientas que ayudan a minimizar vulnerabilidades en el código de software, protege los datos contra infracciones, y ayuda a asegurar “desde el principio” que los desarrolladores consideren el factor de la privacidad en todos los productos y servicios cloud. Para ello, tal y como declaran en su web, cuentan con más de 40 trabajadores para este ámbito.
Evaluaciones de impacto y notificaciones en brechas de seguridad
Además, de ser de obligado cumplimiento por el RGPD (art. 35), es un excelente ejercicio de transparencia, que ayudará a planificar las respuestas a posibles impactos en la protección de datos de los afectados, a gestionar las relaciones con terceras partes implicadas en el proyecto…
El cifrado
He aquí la palabra mágica: el cifrado. Cifrar la información personal EXCLUYE la obligación de notificar a los afectados que se ha producido una brecha de seguridad en la que se han visto comprometidos sus datos personales. Ahora bien, existen varios tipos de cifrado ya que no todos los modos métodos de anonimización de la información son iguales. Algunos tendrán dificultades para demostrar cumplimiento normativo. El legislador no parece mojarse mucho y no los especifica todo lo que debería.
Mitigación de riesgos por GRC
Entre líneas del reglamento podemos ver como el legislador lo que en definitiva pretende es buscar mecanismos (generales) que mitiguen el riesgo y las vulnerabilidades en los derechos de protección de datos de los titulares en las nuevas tecnologías. Poner vallas al campo no es tarea fácil, por lo que, las actividades PREVENTIVAS son las que podrían dar mejor respuesta. En definitiva, el cifrado, los códigos de conducta y certificaciones o evaluaciones de impacto no dejan de ser eso.
Ahora bien, si esto es así, ¿por qué no trasladarlo en el futuro a las relaciones responsable (empresa cliente cloud) – encargado de tratamiento (empresa proveedora/subproveedora cloud) mediante gobernance, risk and compliance? Nos referimos a homologación por medio de checklist o la adhesión de códigos de conducta sectoriales privados (CISPE) o públicos (AEPD). Todo ello de la mano, por supuesto, de un contrato completo (level agreement privacy) -siempre y cuando ambas partes “estén de acuerdo”- donde se incluyan las medidas técnicas y organizativas (cifrado, tokenización, de-identificación…) con penalizaciones ante incumplimiento en materia de privacidad que pudieran repercutir a las partes.
Como conclusión, señalo los siguientes aspectos a considerar:
Los grandes proveedores serán los ganadores y los perdedores los titulares de datos y proveedores cloud PYME. La innovación puede verse acotada por culpa del GDPR sino se toman medidas complementarias y se aclaran las lagunas. Ya que podrán tener cobertura económica para los certificados, e incluso, las propias sanciones, e incluso los proveedores de IaaS, quizá, aumenten sus costes para asumir los riesgos. Lo mismo ocurrirá con la nube pública. ¿Cómo especificar medidas de seguridad concretas en función de qué cliente se trate? ¿O al final optarán por unas medidas comunes elevando el coste? No parece que el GPRD sea del todo neutral, tecnológicamente. Donde mayores problemas nos encontraremos será con la externalización de los servicios preconstruidos de consumo masivo y en la nube estandarizada de autoservicio púbico.
Resulta evidente que no se ha tenido muy en cuenta a los expertos tecnólogos a la hora de legislar y a partir de ahora, será necesario el trabajo conjunto. Los legisladores, inevitablemente, a partir de ahora, se deberán apoyar en el sector privado (asociaciones profesionales de expertos: ENISA, CSA, Eurocloud, ISMS Forum…). El intercambio de información entre gobierno y organizaciones será esencial.
Las organizaciones deberán aplicar no solo las medidas técnicas de cifrado, acceso… sino también las medidas de organización como políticas preventivas GRC, homologaciones y concienciación.
Lorena P. Campillo. Abogada especialista en Derecho de las Nuevas Tecnologías