Resumen: Cuando se llevan al Cloud, para ser
tratados allí, datos personales especialmente protegidos es cuando deben contemplarse
más que nunca, si caben, los aspectos
jurídicos y las medidas de seguridad exigibles acordes con el nivel de sensibilidad
de esos datos. La mayoría de las veces el análisis de la situación, en este
tipo de entornos externalizados, no resulta sencillo.
Autor del artículo
|
Colaboración
|
|
José
Luis Colom Planas
|
||
Actualizado
|
6 de octubre de 2015
|
|
ÍNDICE
2. POSICIONES JURÍDICAS DE CLIENTE Y PRESTADOR DEL SERVICIO
3. CONTRATO ENTRE RESPONSABLE Y ENCARGADO
4. TRANSFERENCIAS INTERNACIONALES DE DATOS
5. PRINCIPIOS DE “PUERTO SEGURO” (SAFE HARBOR)
6. EXIGENCIAS DE CUMPLIMIENTO
7. MEDIDAS DE SEGURIDAD
7.1. Introducción
7.2. Obligación de auditar
7.3. La Norma ISO 27001 y el programa STAR
8. LEGISLACIÓN APLICABLE
8.1. Introducción
8.2. Legislación europea
9. BIBLIOGRAFÍA CONSULTADA
10. CONTROL DE CAMBIOS DEL ARTÍCULO
11. DERECHOS DE AUTOR
1. INTRODUCCIÓN
Es ya una realidad el avance imparable de la entrega de
servicios TIC basados en el modelo externalizado de Cloud Computing, al posibilitar
éste:
- Precio ajustado: Permite ajustar el precio a la demanda real (pago por uso).
- Elasticidad: Permite crecer y decrecer, en relación a los recursos contratados, según las necesidades del momento.
- Entorno ubicuo: Acceso simultáneo desde cualquier lugar, a cualquier hora, mediante cualquier dispositivo y cuántas personas estén autorizadas para ello…
Todas estas son suficientes ventajas que le hacen ganar
adeptos (clientes y usuarios) cada día.
Pero, ¿Qué ocurre cuando queremos tratar mediante este modelo
datos sensibles? ¿Y si además se tratan datos personales especialmente
protegidos por la regulación aplicable en España?
2. POSICIONES JURÍDICAS DE CLIENTE Y PRESTADOR DEL SERVICIO
Como regla general, la posición jurídica de quién contrata
los servicios de Cloud Computing es la de responsable del fichero o tratamiento,
ya sea empresa o profesional autónomo, mientras que quién presta el servicio
tendrá una posición de encargado del tratamiento.
En algunos casos, sin embargo, no resulta tan sencillo
identificar a los responsables del tratamiento, ya que los prestadores del
servicio pueden llegar a determinar unilateralmente los medios y, a veces,
incluso algunos de los fines de los tratamientos. Esta circunstancia suele
darse, a menudo, en plataformas “gratuitas” donde simplemente se acuerda un
pago en especies sustituyendo la transacción dineraria por la propia información.
Esta realidad choca de frente con el tipo de datos personales
especialmente protegidos, cuya naturaleza exige que no puedan ser tratados como
moneda de cambio.
3. CONTRATO
ENTRE RESPONSABLE Y ENCARGADO
- Que el encargado del tratamiento ha de tratar los datos de acuerdo con las instrucciones del responsable del tratamiento.
- Que el encargado no puede utilizar los datos con una finalidad diferente de la que figure en el contrato, ni comunicarlos a otras personas, ni siquiera para su conservación.
- Las medidas de seguridad que el encargado está obligado a implementar (en este caso, y de forma acumulativa, las de nivel alto, medio y básico).
- La devolución o la destrucción de los datos, una vez finalizada la prestación contractual.
Tratándose de datos sensibles, lo evidente es que el
prestador de servicios de Cloud no puede saber de su existencia, a no ser que
nosotros se lo comuniquemos de alguna manera, como puede ser en el propio
contrato de encargado del tratamiento. Pensemos que las medidas de seguridad asociadas deberán
corresponderse con el tipo de datos, siendo el modo de justificar éstas.
También deberán cumplirse las previsiones que se establecen
en los artículos 20, 21 y 22 RLOPD.
En este sentido, el artículo 20.2. RLOPD dispone: “Cuando el responsable del tratamiento
contrate la prestación de un servicio que comporte un tratamiento de datos
personales sometido a lo dispuesto en este capítulo deberá velar por que el
encargado del tratamiento reúna las garantías para el cumplimiento de lo
dispuesto en este Reglamento”.
Otras veces el contrato de encargado del tratamiento no
está redactado de común acuerdo, y se apoya en las condiciones generales en las
que el proveedor de Cloud presta su servicio, siendo el cliente el que debe
adscribirse a la mayoría de ellas. En consecuencia, un buen consejo es negociar
el contrato siempre que sea posible, o en su defecto estudiar cuidadosamente
cada una de las cláusulas propuestas por los diferentes proveedores, hasta
encontrar el contrato que mejor satisfaga las necesidades y la seguridad
jurídica del cliente que contrata.
Debe tenerse en cuenta que a menudo las condiciones de
uso, la política de privacidad o las medidas de seguridad aplicadas, pueden ser
modificadas en cualquier momento sin necesidad de notificarlo previamente a sus
clientes. Eso obliga a la “debida diligencia”, como hemos visto antes, no
solo en la fase de pre-contratación (Artículo 20.2 RLOPD), sino durante todo el
ciclo de vida del servicio externalizado en el Cloud.
Si el proveedor de Cloud trata nuestros datos en un tercer
país que no esté considerado como un país con nivel adecuado de protección será
necesario suscribir también, caso de que al final se autorice la TID, unas cláusulas
contractuales tipo según se especifican en la Decisión de la Comisión 2010/87/UE.
[5]
4. TRANSFERENCIAS
INTERNACIONALES DE DATOS
Como norma general, las TID deben contar con la autorización
del Director de la Agencia Española de Protección de Datos (AEPD) (Artículos 33
LOPD y 70 RLOPD), a no ser que se dé la excepción de que el prestador de
servicios de Cloud Computing se encuentre en un país de los considerados que
ofrecen un nivel adecuado de protección (Artículos 34.k LOPD y 67-68 RLOPD).
En ese caso deberá seguir informándose a la AEPD de la TID, pero la
autorización está pre-concedida.
Los países considerados con nivel adecuado de protección para
la UE son:
- Suiza. Decisión 2000/518/CE de la Comisión, de 26 de julio de 2000.
- EE.UU. (Puerto Seguro). Decisión de la Comisión, de 26 de julio de 2000 (Anulada por STJUE de 6 de octubre de 2015)
- Canadá. Decisión 2002/2/CE de la Comisión, de 20 de diciembre de 2001, respecto de las entidades sujetas al ámbito de aplicación de la ley canadiense de protección de datos.
- Argentina. Decisión 2003/490/CE de la Comisión, de 30 de junio de 2003.
- Guernsey. Decisión 2003/821/CE de la Comisión, de 21 de noviembre de 2003.
- Isla de Man. Decisión 2004/411/CE de la Comisión, de 28 de abril de 2004.
- Jersey. Decisión 2008/393/CE de la Comisión, de 8 de mayo 2008.
- Islas Feroe. Decisión 2010/146/UE de la Comisión, de 5 de marzo de 2010.
- Andorra. Decisión 2010/625/UE de la Comisión, de 19 de octubre de 2010.
- Israel. Decisión 2011/61/UE de la Comisión, de 31 de enero de 2011.
- Uruguay. Decisión 2012/484/UE de la Comisión, de 21 de agosto de 2012.
- Nueva Zelanda. Decisión 2013/65/UE de la Comisión, de 19 de diciembre de 2012.
Sin embargo es importante resaltar que, en relación a los
prestadores de servicios de Cloud Computing, una cosa es la empresa matriz o
el centro empresarial dónde se toman las decisiones sobre cómo tratar los datos
y otra distinta es dónde se almacenan los datos y se tratarán de forma efectiva.
Tal casuística debe contemplarse cuando el proveedor es una multinacional con
representación y centros de proceso repartidos por diferentes países del mundo,
algunos dentro del EEE, otros con nivel adecuado de protección, y otros en
terceros países sin las suficientes garantías.
5. PRINCIPIOS DE “PUERTO SEGURO” (SAFE HARBOR)
Mediante la Decisión
2000/520/CE de la Comisión [6] de 26
de julio de 2000, se creó el acuerdo denominado Safe Harbour por el que se establecía una serie de principios en
materia de protección de datos de carácter personal.
Hay que decir que ha durado
15 años ya que, el 6 de octubre de 2015, una
STJUE en el asunto C-362/14 [8] [9] declara inválida
la Decisión 2000/520 y, en consecuencia,
los acuerdos de Safe Harbor (Puerto Seguro).
Se trataba de un programa de
adscripción voluntaria, basada en la
autorregulación, sin ningún control por parte del estado. En otras
palabras, se trataba de una presunción de adecuación a la protección
exigida en el ámbito de la UE.
Los principios de puerto
seguro eran los siguientes:
- Notice principle (Notificación): Las entidades adheridas tenían la obligación de informar de la utilización y finalidad de los datos de carácter personal.
- Choice principle (Opción): Las entidades adheridas tenían la obligación de ofrecer la posibilidad de decidir si los datos de carácter personal podían ser o no cedidos a un tercero.
- Onward transfer principle (Transferencia ulterior): Las entidades adheridas, antes de revelar información a terceros que no participaran en el programa de puerto seguro, debían aplicar los dos principios anteriores (Notificación y opción).
- Security principle (Seguridad): Las entidades adheridas, que se encarhaban de recoger y almacenar datos de carácter personal, debían adoptar todas las precauciones que consideraran oportunas con el fin de evitar su pérdida, modificación o destrucción.
- Data integrity principle (Integridad de los datos): Las entidades adheridas debían recoger únicamente datos pertinentes respecto a los fines previstos.
- Access principle (Acceso): Las entidades adheridas reconocían el derecho de los interesados al conocimiento de los datos de carácter personal que tenían sobre ellos y pudieran así corregirlos, modificarlos o suprimirlos en caso de ser inexactos.
- Enforcement principle (Aplicación): Las entidades adheridas incluían una vía de recurso para los interesados que se vean afectados por el incumplimiento de la normativa sobre TID de carácter personal entre EE.UU. y UE.
A priori puede parecer que
los tres primeros principios (Notificación, opción y transferencia ulterior) eran
garantía suficiente para que la exportación de datos personales desde España a
cualquier prestador de servicios de Cloud, con matriz en EE.UU. y adherida a
los principios de Safe Harbour, pudiera
realizarse sin necesidad de autorización del Director de la AEPD.
El problema surge cuando la
misma empresa, o grupo multinacional, dispone de CPDs distribuidos en
diferentes países, algunos de ellos sin proporcionar un nivel adecuado o
equiparable de protección. Si el prestador de servicios transfiere
nuestros datos personales a esas otras ubicaciones puede no sentirse obligado
por el tercer principio de Puerto Seguro (transferencia
ulterior), que parece más orientado a terceras empresas que a diferentes
ubicaciones del mismo grupo empresarial, pudiendo ir a parar los datos, sin
saberlo, a un tercer país.
Mientras que la mayoría de
proveedores de Cloud Computing informan por medio de sus políticas de
privacidad de su adhesión a los principios de Puerto Seguro, no todos suelen informar de la ubicación
geográfica de los diferentes CPDs que disponen. Esta forma sigilosa de
incumplir el deber de informar, siempre que se traten datos personales, es más
común en los prestadores que proveen un modelo de entrega de servicios de Cloud
basado en SaaS (Software como servicio).
En consecuencia podríamos
decir que esta indeterminación podía producir, especialmente en los
tratamientos de información sensible, una cierta indefensión jurídica
motivada por la obligación del responsable del tratamiento de cumplir con el
resto de previsiones establecidas en la normativa española de protección de
datos.
Aprovecho para recordar la
disposición adicional única [justo después del artículo 158] del RD 1720/2007,
de 21 de diciembre (RLOPD), que hablando de productos de software dispone:
“Los productos de software destinados al tratamiento automatizado de
datos personales deberán incluir en su descripción técnica el nivel de
seguridad, básico, medio o alto, que permitan alcanzar de acuerdo con lo
establecido en el título VIII de este reglamento”.
Hablando en este
estudio de tratamientos de datos de nivel alto, no sería desdeñable, y
facilitaría mucho la labor auditora, que los proveedores de SaaS (Software como Servicio) en Cloud lo indicaran.
6. EXIGENCIAS
DE CUMPLIMIENTO
Una solución a esta indeterminación recién planteada sería la
suscripción por parte del prestador de servicios de Cloud Computing de las
conocidas como Binding Corporate Rules
(BCR), vinculantes para TODAS las empresas del grupo prestador de servicios de
Cloud (Artículo 137 RLOPD), según las previsiones del documento, elaborado por
el GT29, adoptado el 3 de junio de 2003: 11639/02/EN - WP 74. [4]
Debe tenerse en cuenta que, como regla general, el encargado
del tratamiento (prestador de servicios de Cloud) no puede subcontratar, de
forma unilateral con un tercero, la realización de un tratamiento que le ha
sido encomendado por el responsable (Artículo 21 RLOPD). Solo será posible
efectuar la subcontratación cuando concurran los siguientes requisitos:
- Que este nuevo tratamiento esté especificado en el contrato suscrito entre la entidad contratante y el contratista.
- Que el tratamiento de datos de carácter personal se ajuste a las instrucciones del responsable del tratamiento.
- Que el contratista encargado del tratamiento y el tercero formalicen un contrato en los términos previstos en el artículo 12.2 LOPD.
Así mismo, el Dictamen 5/2012, de 1 de julio, [3] sobre Cloud Computing del GT29, dictamina: “En
opinión del GT 29, el encargado del tratamiento podrá subcontratar sus
actividades únicamente sobre la base del consentimiento del responsable del
tratamiento, que suele darse al inicio del servicio, con la inequívoca obligación
para el encargado de informar al responsable sobre cualquier cambio previsto en
lo que respecta a la adición o sustitución de subcontratistas, teniendo el
responsable del tratamiento en todo momento la posibilidad de oponerse a tales
cambios o de rescindir el contrato. Debe existir la clara obligación del proveedor
de nombrar a todos los subcontratistas. Además, debería firmarse un contrato
entre el proveedor y el subcontratista que refleje las disposiciones del
contrato entre el cliente y el proveedor. El responsable del tratamiento
debería poder hacer uso de las posibilidades contractuales de recurso en caso
de incumplimiento de los contratos causado por los subcontratistas. Esto
podría organizarse garantizando que el encargado responda directamente ante el
responsable por los incumplimientos causados por cualquier subcontratista que
haya contratado, o mediante la creación de un derecho de tercero
beneficiario en beneficio del responsable del tratamiento en los contratos
firmados entre el encargado del tratamiento y los subcontratistas o por el
hecho de que tales contratos se firmen en nombre del responsable del
tratamiento, haciendo a este último parte del contrato”.
En cuanto a las garantías contractuales entre responsable y
encargado, el GT29 dictamina: “El contrato deberá establecer expresamente
que el proveedor no podrá comunicar los datos a terceros, ni siquiera con fines
de conservación, a menos que el contrato prevea la existencia de
subcontratistas. El contrato deberá especificar que sólo podrá contratarse
sub-encargados del tratamiento previa autorización que puede otorgar en general
el responsable del tratamiento, en consonancia con la inequívoca obligación
del encargado del tratamiento de informar al responsable del tratamiento acerca
de cualquier cambio previsto a este respecto, teniendo el responsable del
tratamiento en todo momento la posibilidad de oponerse a tales alteraciones o
de rescindir el contrato.
Deberá existir una clara obligación para el proveedor de
nombrar a todos los subcontratistas contratados (por ejemplo, en un registro
digital público).
Deberá garantizarse que los contratos suscritos entre proveedores y
subcontratistas reflejen las condiciones del contrato entre el cliente y el
proveedor (esto es, que los sub-encargados del tratamiento están sujetos a
los mismos derechos contractuales que el proveedor).
En particular, deberá garantizarse que tanto el
proveedor como todos los subcontratistas sólo actuarán siguiendo instrucciones
del cliente. Tal como se explica en el capítulo sobre el sub-tratamiento,
la cadena de responsabilidad deberá exponerse claramente en el contrato. Deberá
fijarse la obligación por parte del encargado del tratamiento de definir las
transferencias internacionales, por ejemplo firmando contratos con
subcontratistas, basándose en las cláusulas contractuales tipo 2010/87/UE”.
En el Informe 0157/2012 [2] de la
AEPD sobre determinadas cuestiones relacionadas con Transferencias
Internacionales de Datos, se indica: “De este modo, siempre que el
cliente del servicio de computación en nube pueda tener claro conocimiento de
la identidad de los terceros subcontratistas del servicio, así como de las
actividades desplegadas por cada uno de ellos, nada obsta a que la citada
subcontratación se realice mediante la firma de un único contrato con dichos
subcontratistas en que se especifiquen los servicios a prestar.
Ello debería acompañarse de un procedimiento que
permitiera a los clientes acceder a los citados datos de identificación y, en
el caso de transferencias internacionales de datos o de subcontrataciones
posteriores a la citada transferencia, toda vez que se prevé la firma de un
contrato directamente entre el cliente y la empresa estadounidense del Grupo,
la ubicación geográfica en que se prestará el servicio.
En consecuencia, sería suficiente a efectos de acreditar
la existencia de garantías adecuadas que los clientes pudieran acceder, por
ejemplo a través de un sitio web al que se hiciera expresa referencia en el
contrato firmado con la consultante, a los datos de identificación de los
subcontratistas, ubicación de los mismos y servicios de tratamiento que
aquéllos desarrollarán,
bastando la celebración de un contrato único con tales subcontratistas que,
lógicamente cumpliese con los requisitos necesarios para que cupiera atribuir a
los mismos la condición de sub-encargados del tratamiento o para adoptar
garantías suficientes en caso de transferencia ulterior de los datos”
En el contrato entre el encargado del tratamiento y el posible
subcontratista, deben constar las medidas de seguridad necesarias, acorde con
el nivel de los datos personales a tratar. En el caso de datos especialmente
protegidos, esa notificación es fundamental para que el subcontratista sepa
cómo debe proteger adecuadamente esos datos.
7.
MEDIDAS DE SEGURIDAD
7.1.
Introducción
En el contrato entre responsable y encargado han de quedar
fijadas que medidas de seguridad del título VIII del RLOPD se adaptarán en
concreto (Artículo 12.2 LOPD).
7.2.
Obligación de auditar
Esta obligación de auditar por parte del responsable hacia el
encargado puede ser materializada por una entidad tercera acreditada de
confianza, como establece también el Dictamen 05/2012 del GT29 [3]
en su apartado 4.2 Certificaciones de
protección de datos de terceros:
- La verificación independiente o la certificación por terceros que gocen de reconocido prestigio puede ser un medio creíble para que los proveedores demuestren el cumplimiento de sus obligaciones según lo especificado en el presente dictamen. Dicha certificación indicaría, como mínimo, que los controles de protección de datos han sido objeto de una auditoría o revisión con respecto a una norma reconocida que cumple los requisitos expuestos en el presente dictamen, por una organización tercera que goce de reconocido prestigio. En el contexto de la computación en nube, los clientes potenciales deben examinar si los proveedores de servicios en la nube pueden presentar una copia de este certificado de auditoría realizado por un tercero o una copia del informe de auditoría que verifique la certificación, incluso con respecto a los requisitos que figuran en el presente dictamen.
- La realización de auditorías individuales de datos alojados en un medio de servidores virtualizados con múltiples operadores puede ser poco práctica desde el punto de vista técnico y puede en algunos casos puede aumentar los riesgos para los controles físicos y lógicos de seguridad de las redes. En tales casos, podrá considerarse que la auditoría por un tercero de reconocido prestigio elegido por el responsable del tratamiento puede sustituir al derecho de un responsable del tratamiento de realizar una auditoría.
- La adopción de normas y certificaciones específicas sobre protección de la intimidad es esencial para establecer una relación de confianza entre los proveedores, los responsables del tratamiento y los interesados. Estas normas y certificaciones deben cubrir las medidas técnicas (como la localización de los datos o la codificación), así como los procesos seguidos por los proveedores de servicios de computación en nube para garantizar la protección de los datos (tales como políticas de control del acceso, controles de acceso o copias de seguridad).
La propia AEPD en su Informe 0157/2012 [2] indica
al respecto: “De este modo, tomando en cuenta los criterios
sustentados por el Grupo de Trabajo del artículo 29 sería posible considerar
que la auditoría a la que se refiere la consultante, en los términos en los que
la misma se señala en la consulta podría ser considerada una garantía adecuada
para la transferencia de los datos derivada de la contratación del servicio de
computación en nube prestada por la misma siempre y cuando dicho
servicio fuera prestado por una entidad enteramente independiente de la
consultante y que se encontrase debidamente certificada o acreditada,
tanto en lo que se refiere a su independencia como en lo que atañe a sus
procedimientos de actuación.
Además, sería necesario que las partes conviniesen que la
elección de esa tercera parte de confianza se llevase a cabo por parte de la
consultante [responsable del tratamiento], permitiendo en todo caso al cliente
manifestar su opinión así como acceder a los resultados del informe de
auditoría que se llevase a cabo, que necesariamente debería reunir los
requisitos de contenido a los que acaba de hacerse referencia, en los términos
manifestados en el documento WP196 ya citado”.
7.3. La
Norma ISO 27001 y el programa STAR
Una certificación en esta Norma es un acto voluntario (no
legislativo) que sirve para acreditar que la empresa dispone de un SGSI
(Sistema de Gestión de la Seguridad de la Información) basado en la mejora
continua que está sometido regularmente a auditorías de control por parte de una
tercera entidad acreditada y reconocida internacionalmente.
En consecuencia, podría servir para evidenciar que dicha
empresa cumple con las medidas
organizativas y técnicas necesarias, demostrando que posee un adecuado
nivel de protección de datos en general (incluidos los de naturaleza
personal). Todo ello suponiendo que el alcance de la certificación, que
puede definirse a voluntad por quién se certifica, cubra todos los ficheros y
tratamientos que afectan a nuestras necesidades.
Lo que no garantiza nunca una Norma ISO 27001 es que se
cumpla con el tercer paquete de medidas que faltan: Las jurídicas. Si bien existe
un objetivo de control y un control jurídico específico en el apéndice A de la Norma:
A.18 CUMPLIMIENTO LEGAL
A.18.1 Cumplimiento con los requisitos legales y
contractuales
A.18.1.4 Privacidad y protección de la información identificable
personal: La Privacidad y la protección de la información identificable
personal debe ser asegurada como se requiere en la legislación y la regulación
que le es aplicable.
Si en el país donde un encargado del tratamiento se certifica
de la Norma no existe legislación aplicable sobre protección de datos, ésta
se limitará a constatar que dicho control NO APLICA y quedará excluido de la
declaración de aplicabilidad (SOA en inglés), sin afectar al proceso de certificación.
En consecuencia no se podrá acreditar en base a la ISO27001:2013 la existencia
de medidas jurídicas sobre legislación en materia de protección de datos.
Lo mismo podría ocurrir con las medidas organizativas y técnicas
pese a que toda exclusión, de cualquiera de los 114 controles posibles en la
declaración de aplicabilidad que exige la Norma, debe estar plenamente
justificada.
NOTA DEL EDITOR: La evaluación del cumplimiento en materia de protección de
datos personales en entornos de Cloud Computing no es baladí. Se requieren
sólidos conocimientos jurídicos en la materia, conocimiento de la legislación
aplicable en cada caso, dominio como leader auditor de la Norma ISO 27001 de
gestión de la seguridad de la información y ahora también como auditor del esquema
de certificación STAR de seguridad en proveedores de Cloud. En otras palabras,
o se es un profesional de amplio espectro o se requiere un conjuntado equipo
multidisciplinar.
En el reciente y muy completo Informe CNS-57/2013 [1] de la Autoritat Catalana de Protecció de Dades (APDCAT) sobre prestadores de “Cloud
Storage” y despachos de abogados [puede
accederse a la traducción en el apartado de bibliografía], se admite que
esos 114 controles podrían en cierta manera concordar con diferentes preceptos
del RLOPD relativos a las medidas de seguridad (Artículos 89 a 104),
facilitando la normativa de protección de datos en este sentido.
No obstante, también apunta a que no existe una relación
directa entre éstas medidas establecidas por la Norma y las medidas previstas
en el RLOPD. En otras palabras, el Informe de la APDCAT concluye que “la Norma ISO 27001:2013 no garantiza la existencia de un documento de
seguridad con los contenidos mínimos previstos en la legislación española de
protección de datos, (…), de un registro de acceso a los datos o de un registro
de incidencias que cumpla con todos los requisitos previstos en la normativa
vigente”.
Hemos de pensar que este temor de la APDCAT debe
circunscribirse especialmente dentro
del caso que nos ocupa, que no es otro
que el tratamiento de datos especialmente protegidos.
Muy recientemente, para las empresas de Cloud Computing, dentro
del OCF (Esquema abierto de certificaciones), de la mano de British Standards Institution (BSI) y
de la Cloud Security Alliance (CSA), existe la denominada certificación
STAR. Se trata de un esquema de certificación basado en tres niveles y adecuado
al prestador de servicios de Cloud Computing. La certificación STAR de nivel
2 comprende una auditoría independiente “de tercera parte” sobre la base de la
CCM (Cloud Control Matrix) - Matriz de Controles de Cloud - que complementan a los definidos en el anexo
A de la ISO 27001.
Los 136 controles que componen el CCM V3.0 están agrupados en
16 dominios. Antiguamente, en el CCM V1.x existía el dominio Legal (LG). Actualmente
en el CCM V3.0 los controles correspondientes a la parte legal han quedado repartidos
entre dos dominios diferentes: Human Resources Security (HRS) y Supply chain
management, transparency & accountability (STA).
8.
LEGISLACIÓN APLICABLE
8.1.
Introducción
Una percepción clara del Derecho aplicable sobre protección
de datos, tanto en el EEE como en un contexto internacional más amplio, contribuirá a garantizar la seguridad jurídica
a los responsables del tratamiento, a sus clientes y demás partes interesadas.
Como se dispone en el dictamen 8/2010 del GT29, sobre el
Derecho aplicable, [7] la determinación
del Derecho aplicable está estrechamente vinculada a la identificación del
responsable del tratamiento y de su(s) establecimiento(s): la principal
consecuencia de esta vinculación es la reafirmación de las responsabilidades
del responsable del tratamiento, y de su representante si aquel está
establecido en un tercer país.
8.2. Legislación
europea
En el referido dictamen se indica:
“II.2.b) Ámbito del
Derecho de la UE dentro de la UE/del EEE. Los principales criterios a la hora de determinar el
Derecho aplicable son la ubicación del establecimiento del responsable del
tratamiento y la ubicación de los medios o del equipo que se esté
utilizando cuando el responsable del tratamiento esté establecido fuera del
EEE. Esto significa que ni la nacionalidad o el lugar de residencia habitual
de los interesados, ni la ubicación física de los datos personales son
decisivos a tal efecto”.
Evidentemente el Dictamen concuerda con el artículo 4
“Derecho aplicable” de la Directiva 95/46/CE.
En consecuencia, y para el estudio que nos ocupa suponemos que el responsable del
tratamiento, que es la empresa que contrata los servicios a un proveedor de
Cloud, está en España (dentro de la UE) por lo que el Derecho aplicable debería
ser el español.
9. BIBLIOGRAFÍA
CONSULTADA
- [2] AEPD. Informe 0157/2012. “Determinadas cuestiones relacionadas con Transferencias Internacionales de Datos”.
Informe 0157/2012
- [3]
GRUPO DE PROTECCIÓN DE DATOS DEL ARTÍCULO 29. “Dictamen 05/2012 sobre la computación en nube”. 1 de
Julio de 2012. WP196. 01037/12/ES. Dirección
General de Justicia de la Comisión
Europea.
WP 196
- [4] ARTICLE 29 - DATA PROTECTION
WORKING PARTY. “Working Document: Transfers of personal data to
third countries: Applying Article 26(2) of the EU Data Protection Directive to
Binding Corporate Rules for International Data Transfers”. Adopted on 3 June 2003.
11639/02/EN.WP 74.
Working Document
- [5] Decisión 2010/87/UE
de la Comisión. “Relativa a las cláusulas contractuales tipo para la
transferencia de datos personales a los encargados del tratamiento establecidos
en terceros países”. De conformidad con la Directiva 95/46/CE del Parlamento
Europeo y del Consejo. 5 de febrero de 2010.
Decisión 2010/87/UE
- [6] Decisión 2000/520/CE de la Comisión. “sobre la adecuación conferida por los
principios de puerto seguro para la protección de la vida privada y las correspondientes
preguntas más frecuentes, publicadas por el Departamento de Comercio de Estados
Unidos de América. 26 de julio de 2000.
Decisión 2000/520/CE
- [7] GRUPO DE
PROTECCION DE DATOS DEL ARTICULO 29. “Dictamen 8/2010 sobre el Derecho
aplicable”. 16 de diciembre de 2010. WP
179.
Dictamen 8/2010
- [8] SENTENCIA DEL TRIBUNAL DE JUSTICIA (Gran Sala). “En
el asunto C‑362/14,
que tiene por objeto una petición de decisión prejudicial planteada, con
arreglo al artículo 267 TFUE, por la High Court (Irlanda)”. 6 de octubre de
2015.
- [9] TJUE. “COMUNICADO DE PRENSA
nº 117/15”. Luxemburgo, 6 de octubre de 2015. Sentencia en el asunto C-362/14. Maximillian
Schrems / Data Protection Commissioner.
Comunicado TJUE
Comunicado TJUE
10. CONTROL DE CAMBIOS DEL ARTÍCULO
Siguiendo voluntariamente
las disposiciones de la cláusula 7.5.3 del “Anexo SL” en las normas ISO, se
incorpora el control de cambios a los artículos de este Blog permitiendo
conocer la trazabilidad de los mismos una vez han sido publicados por primera
vez. Todo ello en concordancia con el último párrafo de la cláusula general de
exclusión de responsabilidad del Blog.
Fecha
|
Cambio
|
Responsable
|
15/05/2014
|
Redacción
inicial del artículo
|
Autor
|
06/10/2015
|
-
Se actualizan los apartados “4. Transferencias Internacionales de Datos” y “5.
Principios de “puerto seguro” (Safe Harbor)” del artículo como consecuencia
de la STJUE de fecha 6 de octubre de 2015, en el asunto C-362/14.
-
También se actualizan las referencias [8]
y [9] de la bibliografía
consultada.
|
Autor
|
11. DERECHOS DE AUTOR
Tablas creadas por el autor.
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:
Posee un doble perfil, jurídico y técnico, que le facilita el desempeño profesional en el ámbito de los diferentes marcos normativos, especialmente del Derecho de las nuevas tecnologías y las normas ISO de adscripción voluntaria. A partir de su dilatada experiencia, edita el Blog temático “Aspectos Profesionales”.
A
nivel de especialización jurídica, ha realizado el postgrado
de Especialista Universitario en Protección de Datos y Privacidad en la
Facultad de Derecho de la Universidad de Murcia, disponiendo de la
certificación CDPP (Certified Data
Privacy Professional) del ISMS Fórum Spain. También ha cursado el programa
superior de Compliance Officer (Controller jurídico) en la Escuela Legal WKE y
se ha especializado respecto a los delitos de blanqueo de capitales en la UOC,
en colaboración con el Ilustre Colegio de Abogados de Barcelona (ICAB). Es
experto externo en prevención de blanqueo de capitales, certificado por INBLAC.
A
nivel de especialización técnica, 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). Es
Auditor e Implantador de SGSI (Gestión de la Seguridad de la Información) por
AENOR (Asociación Española de Certificación y Normalización). Leader Auditor & Implanter ISO 27001 e 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).
Desempeña su labor
profesional en la entidad de certificación AUDERTIS como Director de
Auditoría y Cumplimiento Normativo. También colabora con la entidad
certificadora British Standards Institution (BSI) como auditor jefe de
certificación e impartiendo formación para la obtención de la acreditación como
lead auditor, en diferentes marcos normativos, incluidas las especificaciones
del IRCA. Ha trabajado en Govertis Advisory Services cómo Compliance, Management
& IT Advisor, incidiendo en Compliance Penal, PBC/FT, asesoramiento
respecto a cumplimiento normativo, privacidad y gestión de la seguridad
de la información. Ha participado como lead implementer y lead auditor de
diferentes sistemas de gestión basados en Normas ISO, individuales o
integrados, y en la optimización de sus procesos. Ha realizado diferentes
niveles de auditorías de cumplimiento legal ya sea para organizaciones sujetas
a Derecho público o privado. Anteriormente ha ostentado la posición de Director
de Consultoría en ANTARA, asesorando respecto a Privacidad, seguridad de la
información y PBC/FT.
Convencido del valor que
aportan las organizaciones profesionales, 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), ENATIC (Asociación de expertos nacionales
de la abogacía TIC), CUMPLEN (Asociación de Profesionales de
Cumplimiento Normativo) y asociado de INBLAC (Instituto
de expertos en prevención del Blanqueo de Capitales), habiendo sido
ponente o colaborado en casi todas las referidas organizaciones. También lo es
de la iniciativa del Observatorio Iberoamericano de Protección de Datos (OIPRODAT)
habiendo obtenido, junto a algunos colaboradores del mismo, un premio
compartido otorgado por la AEPD.
Twittear
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.