martes, 28 de agosto de 2018

El Delegado de Protección de Datos (DPD) y su comparativa con el Corporate Compliance Officer (CCO)


Resumen: El Delegado de Protección de Datos (DPD) y el Corporate Compliance Officer (CCO) gozan de similitudes y diferencias. En este artículo, que escribí para European Compliance & News, analizo el paralelismo entre ambas figuras.


Autor del artículo
Colaboración
José Luis Colom Planas

Actualizado

28 de Agosto de 2018


Índice

1. Introducción al Compliance
1.1 Aparición del término Compliance Officer
1.2 Aparición del término Delegado de Protección de Datos
2. Funciones asignadas
2.1 Funciones asignadas al CCO
2.2 Funciones asignadas al DPD
2.3 Las tres líneas de defensa
3. Estatuto profesional
3.1 Estatuto profesional del Compliance Officer
3.2 Estatuto profesional del Delegado de Protección de Datos
4. Designación del CCO y del DPD
5. El deber de garante
5.1 El deber de garante originario en las organizaciones
5.2 Transferencia del deber de garante al CCO y/o al DPD
6. Coexistencia de ambos roles (CCO y DPD)
7. Responsabilidad y protección jurídica del CCO y el DPD
7.1 En relación al deber de garante del CCO
7.2 El CCO como testigo o como investigado en la instrucción penal
7.3 Responsabilidad del DPD
8. Bibliografía consultada
9. Control de cambios del artículo
10. Derechos de autor
1. Introducción al Compliance
1.1 Aparición del término Compliance Officer
Si desde un punto de vista simplista nos limitamos a traducir el término anglosajón Compliance por cumplimiento, vemos que conceptualmente no es ninguna novedad ya que desde tiempos pretéritos la sociedad en su conjunto se organiza alrededor de normas y obligaciones de todo tipo que deben cumplirse, siendo las más relevantes las jurídicas.

No obstante, en los últimos años, el término Compliance se ha puesto en valor en entornos corporativos, quizá coincidiendo en España con la Ley Orgánica 5/2010, de 22 de junio, por la que se modificaba el Código Penal de 1995, introduciendo en nuestro país la responsabilidad penal de la persona jurídica. Posteriormente, con la última reforma en 2015 mediante la Ley Orgánica 1/2015, de 30 de marzo, se continuaba reconociendo en el Código Penal dicha responsabilidad, a la vez que se determinaba con mayor detalle cómo podía una organización verse exonerada de la misma. A partir del redactado del artículo 31 bis 2 CP, apareció indirectamente la función de Compliance Officer, a la que nos referiremos a menudo en este artículo como Corporate Compliance Officer (CCO).

Un hecho reseñable es que, entre ambas reformas, apareció la norma ISO 19600:2014, sobre Sistemas de Gestión de Compliance, que define: “Compliance es el resultado de que una organización cumpla con sus obligaciones”. Esta definición de amplio recorrido no circunscribe las obligaciones únicamente al ámbito penal, ni siquiera jurídico, sino que incardina dentro de Compliance las normas internas, las normas de adscripción voluntaria – como pueden ser las normas ISO - e incluso los requisitos contractuales, laborales o aquellos que puedan estar obligando a la organización. Naturalmente en los sistemas de gestión de Compliance basados en la norma ISO 19600:2014, partiendo de un completo análisis del contexto en el que opera la organización, debe determinarse el alcance del propio sistema, en base a seleccionar de qué marcos normativos u obligaciones se gestionará el cumplimiento. Este alcance delimitará sin duda las competencias específicas del CCO.

1.2 Aparición del término Delegado de Protección de Datos

El año 2016 fue aprobado el Reglamento (UE) 2016/679, de 27 de abril, Reglamento del Parlamento Europeo y del Consejo relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE, conocido como Reglamento General de Protección de Datos (RGPD) que ha finalizado el 25 de mayo de 2018 su período de vacatio legis, siendo actualmente de aplicación en todos los Estados de la Unión y ampara, después del Corrigendum de fecha 19 de abril de 2018, al tratamiento de datos personales de interesados “que se encuentren en la Unión”, como acepción más amplia que la anterior de “residentes en la Unión”. En el RGPD se introduce una nueva figura de cumplimiento normativo respecto a la protección de datos: El Data Protection Officer (DPO) referido en España como Delegado de Protección de Datos (DPD).

Esta figura tiene mucho mayores atribuciones y exige mayor competencia que el rol de Responsable de Seguridad (DSO por sus siglas en inglés) que en España venía determinando por el derogado RD 1720/2007, Reglamento de aplicación de la anterior LOPD. Pensemos que las únicas competencias del DSO eran, según el artículo 5.2.l) RLOPD, coordinar y controlar las medidas de seguridad aplicables según se detallaban en el Documento de Seguridad. El DPD, en cambio, tiene una visión holística e integral de la protección de datos en la organización, para lo que se requieren conocimientos especializados del Derecho y práctica en protección de datos, que lo elevan a otro nivel profesional.

2. Funciones asignadas

2.1 Funciones asignadas al CCO

Si nos ceñimos al ámbito penal, la condición segunda del apartado 2 del art. 31 bis CP dispone: “2.ª la supervisión del funcionamiento y del cumplimiento del modelo de prevención implantado ha sido confiada a un órgano de la persona jurídica con poderes autónomos de iniciativa y de control o que tenga encomendada legalmente la función de supervisar la eficacia de los controles internos de la persona jurídica”. Luego únicamente se explicitan como funciones del CCO la supervisión del funcionamiento del modelo de prevención (en la práctica del Sistema de Gestión del Cumplimiento) y la de su cumplimiento por parte de quienes están sometidos a él, junto a la supervisión de la eficacia de los controles internos de la organización.

Está claro que, si ampliamos el alcance del Compliance más allá de la RPPJ, las funciones pueden aumentar.

La norma UNE 19601:2017 sobre Sistemas de gestión de Compliance penal, trata las responsabilidades del CCO, y de la función de Compliance, en el apartado 5.1.2 Órgano de Compliance penal. Por su parte, la norma ISO 19600:2014 sobre Sistemas de gestión de Compliance, trata en el apartado 5.3.4 las responsabilidades de la función de Compliance en general.

2.2 Funciones asignadas al DPD

Según dispone el art. 39 RGPD, el DPD tendrá como mínimo las siguientes funciones que paso a resumir: a) informar y asesorar a la organización y a los empleados que se ocupen del tratamiento de datos personales; b) supervisar el cumplimiento de lo dispuesto en el RGPD y en otras disposiciones de protección de datos que sean de aplicación y de las políticas de la organización en materia de protección de datos personales, incluida la asignación de responsabilidades, la concienciación y formación del personal que participa en las operaciones de tratamiento; c) ofrecer el asesoramiento que se le solicite acerca de la evaluación de impacto relativa a la protección de datos (EIPD) y supervisar su aplicación de conformidad con el artículo 35; d) cooperar con la autoridad de control; e) actuar como punto de contacto de la autoridad de control para cuestiones relativas al tratamiento, incluida la consulta previa a que se refiere el artículo 36, y realizar consultas, en su caso, sobre cualquier otro asunto.

También ser interlocutor válido para los interesados que quieran ejercer sus derechos frente a la organización donde presta sus servicios, pudiendo resumir que mantiene contactos a tres bandas: con la Autoridad de Control, con el Responsable del Tratamiento dónde ejerce y con los interesados o afectados por los tratamientos.

2.3 Las tres líneas de defensa

La función de Compliance, ya estemos hablando del CCO, o más especializada en protección de datos como es el caso del DPD, debe tener suficiente grado de autonomía e independencia en sus funciones para no verse condicionada por intereses departamentales en conflicto con la cultura de cumplimiento corporativa. Ahora bien, al ser sus funciones principales las de vigilancia y control, por un lado, y de asesoramiento sobre cumplimiento, por otro, el contacto con las diferentes áreas funcionales o departamentos de la empresa ha de ser máximo. Esto viene reforzado por cuánto conocemos respecto a la elaboración del mapa de riesgos penales, que se extiende por todos los procesos de negocio de la empresa y todas las áreas funcionales, sin excepción, y por la teoría ampliamente aceptada de las tres líneas de defensa.



Esta teoría diferencia una primera línea consistente en la ejercida por los responsables de las diferentes áreas, puesto que la mayoría de circunstancias siempre suelen ocurrir en las áreas operativas; el poder supervisar y controlar en origen es condición necesaria para disponer de la suficiente agilidad para minimizar los incumplimientos y garantizar la eficacia de los controles. Una segunda línea la conforma la función de Compliance que vigila y asesora a las áreas operativas. También elabora los análisis de riesgos en su área de competencia en colaboración con dichas áreas que son las que conocen mejor que nadie los riesgos con los que conviven a diario. La tercera línea la constituye auditoría interna con sus evaluaciones, pero a menudo limitada en el tiempo a una única intervención anual para no agotar a los auditados.

NOTA del editor: No es un tema pacífico el que corresponda al DPD la realización de auditorías sobre protección de datos. Parte de la doctrina piensa que sí, aunque otros pensamos que preferiblemente no. La razón es que, caso de realizar auditorías el DPD, estaríamos mezclando la segunda y tercera líneas de defensa y quizá no es lo más apropiado, salvo en organizaciones pequeñas con pocos recursos. Otra cosa es que el DPD reciba una copia del informe y actúe en consecuencia orientando al Responsable o Encargado sobre la subsanación de las desviaciones detectadas.

3. Estatuto profesional

3.1 Estatuto profesional del Compliance Officer

Actualmente no se dispone de un estatuto profesional del CCO, en lo que se refiere al ámbito de la RPPJ. De hecho, el Código Penal ni tan siquiera nombra a dicha figura, limitándose a señalar como hemos visto en la condición 2ª del art. 31 bis 2 CP que “la supervisión del funcionamiento y del cumplimiento del modelo de prevención implantado ha sido confiada a un órgano de la persona jurídica con poderes autónomos de iniciativa y de control o que tenga encomendada legalmente la función de supervisar la eficacia de los controles internos de la persona jurídica”.

Ha habido muchas voces que claman su promulgación y también esfuerzos encaminados a perfilar su posición por parte de determinadas organizaciones profesionales, que han elaborado documentos titulados “Estatuto del Compliance Officer” y “Libro blanco sobre la función de Compliance” que, aun siendo muy buenas aportaciones, carecen de valor jurídico. Esto nos lleva a que cada vez se considera más necesario disponer de un estatuto profesional para el CCO, o para la función de Compliance en general, que clarifique sus funciones, derechos y responsabilidades. Mientras llega, la mejor solución consiste en detallar como una adenda al contrato las funciones específicas del CCO en relación a su desempeño, dejando bien clara cualquier pretendida delegación de funciones desde la posición originaria de garante del administrador, aspecto que analizamos más adelante.

3.2 Estatuto profesional del Delegado de Protección de Datos

En cuanto al DPO, en lo formal tampoco se dispone de estatuto profesional, aunque si algo en lo material, deduciéndose de los artículos 37, 38 y 39 que constituyen la sección 4 sobre el Delegado de Protección de Datos del propio Reglamento (UE) 2016/679.
Como ejemplo citaré que tanto el responsable como el encargado del tratamiento respaldarán al DPD en el ejercicio de sus funciones (Art. 38.2 RGPD), garantizarán que no reciba ninguna instrucción en lo que respecta al desempeño de sus funciones, ni podrá ser destituido o sancionado por desempeñarlas (Art. 38.3 RGPD), también, pese a hacerlo de forma muy generalista, se explicitan sus requisitos de designación (Art. 37.5 RGPD) y la necesaria publicidad que debe darse al nombramiento (Art. 37.7 RGPD).

Por todo ello podemos afirmar a día de hoy que el desempeño profesional del DPD está más determinado y mejor protegido que el del CCO, no solo por tener las funciones más claramente delimitadas, sino por dedicarse al DPD tres artículos completos en el RGPD frente a ninguno respecto al CCO en el Código Penal, en lo que se refiere a su faceta de velar por la prevención de la RPPJ, como se ha visto en el apartado anterior.

4. Designación del CCO y del DPD

Podemos definir la justicia rogada como la petición dirigida a un órgano judicial para que éste dé a cada una de las partes, especialmente a la propia, lo que le corresponda o pertenezca. Desde este punto de vista, la exoneración de responsabilidad penal de la PJ deberá rogarse en justicia si se estima conveniente, no siendo obligatorios ni los modelos de prevención de delitos ni, en consecuencia, disponer de un CCO. En cambio, si extendemos el alcance del sistema de gestión de Compliance más allá de la RPPJ, debe estudiarse con detenimiento la necesidad, incluso la obligatoriedad, de determinadas funciones, como pueden ser la del Responsable de Prevención en PRL, el Representante ante el SEPBLAC en sujetos obligados por la LPBC/FT, el Delegado de Protección de Datos en la Administración pública y en determinadas circunstancias, etc. Dichas funciones cubren determinados aspectos de cumplimiento en las organizaciones, pudiendo actuar de forma independiente, aunque coordinada, o colegiados en un órgano general de cumplimiento.

En el caso del CCO, incluso, el apartado 3 del artículo 31 bis CP señala que “En las personas jurídicas de pequeñas dimensiones, las funciones de supervisión a que se refiere la condición 2.ª del apartado 2 podrán ser asumidas directamente por el órgano de administración”, estableciendo así un umbral de elusión en la independencia de la figura.

El caso del DPD es distinto al del CCO, ya que es su propia designación la que viene regulada por Ley. Concretamente, el art.  37.1 RGPD establece tres supuestos de obligatoriedad, que vienen desarrollados de forma práctica en el art. 34 del proyecto de nueva Ley Orgánica de Protección de Datos, determinando la necesidad de su designación en función del tipo de entidades de que se trate, detallando un numerus clausus o catálogo de 15 de ellas que van desde los colegios profesionales hasta la seguridad privada.

5. El deber de garante

5.1 El deber de garante originario en las organizaciones

No escapa a la lógica de la razón admitir que, en el ámbito y en representación de la persona jurídica (PJ), el Administrador tiene los deberes propios de garante sobre la conducta de sus empleados.

Este poder lo ejerce de dos formas consecutivas:

·      Primero, desde la perspectiva in eligendo, estableciendo los controles adecuados en el proceso de selección de los trabajadores.

·      Después, in vigilando, supervisando su desempeño profesional, en la medida de sus posibilidades razonables, especialmente con los puestos más especializados.

Se puede decir que este poder de supervisión y control está orientado como:

·      Garante de protección, desde una perspectiva ad intra, evitando resultados lesivos para la propia empresa y sus empleados.

·      Garante de control, desde una perspectiva Ad extra, evitando resultados lesivos sobre terceros, externos a la organización, a partir de la actividad de los empleados.

En consecuencia, puede afirmarse que el Administrador de la PJ se encuentra en una posición de garante originaria, que le obliga a impedir la comisión de delitos por parte de subordinados con repercusión en bienes jurídicos de terceros.

Por ello, Los Administradores deben establecer los mecanismos de organización adecuados para evitar los riesgos de comisión de ilícitos en su seno o, en todo caso, mitigarlos hasta niveles tolerables por las circunstancias de la PJ. Ello, no obstante, no exonera al Administrador de su posición final de garante.

Dicho de otra manera, la comisión por omisión se dará en relación a los riesgos típicamente unidos a la actividad empresarial que tienden a descontrolarse, de no ponerse remedio, con el paso del tiempo y su inevitable evolución.

La propia norma UNE 19601:2017, en su apartado 5.3.2 sobre delegación de facultades, señala: “En los casos en que la alta dirección delegue la toma de decisiones en ámbitos en los que exista riesgo penal mayor que bajo, la organización debe establecer y aplicar un procedimiento y un sistema de controles que garanticen que el proceso de decisión y el nivel de autoridad de los decisores sean adecuados y estén libres de conflictos de interés reales o potenciales. NOTA: La delegación de la toma de decisiones no exonera a la alta dirección de sus propios deberes y responsabilidades en cuanto a la prevención de los riegos penales. Tampoco transfiere a las personas delegadas las posibles responsabilidades legales en materia de supervisión o adopción de decisiones que les corresponda”.

Citando el Real Decreto Legislativo 1/2010, de 2 de julio, por el que se aprueba el texto refundido de la Ley de Sociedades de Capital, en su art. 236.1 señala: “Los administradores responderán frente a la sociedad, frente a los socios y frente a los acreedores sociales, del daño que causen por actos u omisiones contrarios a la ley o a los estatutos o por los realizados incumpliendo los deberes inherentes al desempeño del cargo, siempre y cuando haya intervenido dolo o culpa”, quedando como indelegable la responsabilidad que se deriva de su deber de garante originario. En consecuencia, sin perjuicio de las funciones propias del CCO, siempre corresponderá al Órgano de Administración establecer la política de control y gestión de riesgos de cualquier tipo de la organización y su supervisión, que en las sociedades cotizadas tiene la condición de facultad indelegable, conforme lo establece el art. 529 ter 1 b) de la referida Ley de Sociedades de Capital “El consejo de administración de las sociedades cotizadas no podrá delegar las facultades de decisión a que se refiere el artículo 249 bis ni específicamente las siguientes: (…) b) La determinación de la política de control y gestión de riesgos, incluidos los fiscales, y la supervisión de los sistemas internos de información y control”.

5.2 Transferencia del deber de garante al CCO y/o al DPD

¿Qué ocurre si la empresa delega varias de esas responsabilidades de garante originarias en una figura específica como puede ser el Delegado de Protección de Datos (DPD) o el Corporate Compliance Officer (CCO), cada una en su área de competencias?



La respuesta es que constituye un mecanismo de transferencia de la posición de garante porque, basándonos en esa delegación, el Administrador como delegante hace surgir una posición de garantía en el CCO o DPD, en calidad de delegado. Cabe decir que la posición de garante del Administrador no desaparece del todo, pudiendo pasar a ser residual, ya que la delegación correctamente efectuada modifica la posición jurídica del delegante liberándole de los deberes inherentes del ámbito competencial de que se trate, pues de lo contrario, carecería por completo de sentido que se llevara a cabo. Al administrador ya no le incumbe cómo se articulará el control de la fuente de riesgo, que le corresponde al CCO o al DPD, pero sí le compete la correcta selección, formación e información del responsable de cumplimiento, la dotación a esta figura de los medios necesarios para el cumplimiento de sus funciones y, especialmente, el deber de vigilancia sobre éste en el sentido de verificar su gestión.

Si llega a producirse un incidente motivado por una dejación de funciones del CCO o del DPD, la organización mantiene su responsabilidad última entendida en un caso como posible responsabilidad penal de la persona jurídica donde opera un CCO y, en otro, asumiendo su responsabilidad como Responsable, Corresponsable o Encargado del Tratamiento en relación a la protección de datos personales, donde opera un DPD.

Una prueba de que el administrador mantiene su responsabilidad última, pese a que CCO y DPD dispongan de autonomía, sería el hecho de estar facultado a destituirlos. Esto es así en el caso del CCO respecto a Compliance penal, dado que el art. 31 bis CP y concordantes no señala nada al respecto. En cambio, en el caso del DPD el art. 38.3 RGPD señala que “No será destituido ni sancionado por el responsable o el encargado por desempeñar sus funciones”.

6. Coexistencia de ambos roles (CCO y DPD)

En entornos de Compliance la coexistencia de ambos roles vendrá marcada por la ausencia de conflictos de interés.

En el caso del DPD viene explicitado en el art. 38.8 RGPD que dispone: “El delegado de protección de datos podrá desempeñar otras funciones y cometidos. El responsable o encargado del tratamiento garantizará que dichas funciones y cometidos no den lugar a conflicto de intereses”.

En cambio, el Código Penal español nada dice al respecto del CCO, debiendo acudir a la Circular 1/2016 de la FGE, que señala: “Para conseguir los máximos niveles de autonomía, los modelos deben prever los mecanismos para la adecuada gestión de cualquier conflicto de interés que pudiera ocasionar el desarrollo de las funciones del oficial de cumplimiento, garantizando que haya una separación operacional entre el órgano de administración y los integrantes del órgano de control que preferentemente no deben ser administradores, o no en su totalidad”.

En consecuencia, caso de ausencia de conflictos de interés nada impide concentrar, especialmente en pequeñas organizaciones, ambos roles en la misma persona física. No obstante, debe garantizarse que concurran en el candidato las competencias necesarias para poder desempeñar ambos roles. Dicha concurrencia será poco habitual al requerirse profundos conocimientos jurídicos, técnicos y organizativos en protección de datos, seguridad de la información y gestión de riesgos para las funciones de DPD y de Derecho Penal, de gestión de riesgos y de muchas otras especialidades según el alcance adoptado de Compliance, para las funciones de CCO. 

7. Responsabilidad y protección jurídica del CCO y el DPD

7.1 En relación al deber de garante del CCO

La responsabilidad de cualquier desempeño en una organización radica en su “posición de garantía”. Son el Administrador, o quienes tengan delegadas competencias de dirección general o alta dirección operativa, quienes serán poseedores de dicha posición. Bajo esa concepción será siempre el poder ejecutivo en la organización quien tiene el dominio de la fuente de riesgo, mientras que el CCO no posee en el mismo nivel dicha posición de garantía, concluyendo su responsabilidad - prima facie - con el deber de advertir, vigilar e informar de los riesgos propios de la actividad a la alta dirección operativa.

Dicho en otras palabras, el órgano de administración y, como máximo, la alta dirección operativa, conservan o en su caso adquieren, respectivamente, el deber de garante general originario respecto a la evitación de la comisión de delitos. En cambio, el CCO no se convierte en “garante” ya que el Código Penal únicamente le encomienda la función de “supervisar la eficacia de los controles internos de la persona jurídica” y “funciones de supervisión, vigilancia y control”, como se desprende del art. 31 bis 2 CP, pero no la posibilidad de contener y evitar la comisión del posible hecho delictivo, es decir, no posee el “dominio del hecho” propio del autor de un ilícito tipificado penalmente, incluso equiparando su desempeño a una posición directiva, como sucederá en múltiples ocasiones para legitimar y garantizar su comunicación directa con los órganos de gobierno corporativo.  Adicionalmente, si tuviera conocimiento cierto de que va a cometerse, se está cometiendo, o se ha cometido un delito en el seno de la organización, su única responsabilidad es notificarlo al órgano de administración para que éste obre en consecuencia a su capacidad sancionadora, capacidad de la que adolece el CCO.

No obstante, el CCO podría ser responsable de un delito de omisión si incumple un deber especifico de actuación cuya observancia hubiera impedido o dificultado la comisión de un delito por parte de un tercero en el seno de la empresa.

Para poder atribuir responsabilidad a quién omite una acción se requiere dolo - intencionalidad o conocimiento cierto de que con su inactividad se contribuye al delito, equiparable a cómplice necesario o coautor- o dejación de funciones -comisión por omisión- concretándose este último supuesto en el Derecho Español mediante la necesidad de (1) Posición de garante: La existencia de una posición de garante en previsión de un hecho perjudicial; (2) Conexión: La existencia de alguna conexión entre omisión y responsabilidad; (3) Resultado: La producción de un resultado dañino íntimamente ligado al hecho; (4) Previsibilidad: Que no se haya producido el hecho por la concurrencia de otros factores externos, imprevisibles o inevitables, ajenos a los que configuran la específica posición de garante, ya que éste factor imprevisible eximirá de cualquier responsabilidad al omitente que está situado como garante, al tener su origen el resultado lesivo en factores insalvables; (5) Posibilidad de actuar: la necesidad de que el omitente obligado estuviera en condiciones de realizar la conducta prevista. En caso de imposibilidad de actuar no surge responsabilidad por la inacción, eliminando la responsabilidad inherente a la situación de garante.



Ya el Tribunal Supremo ha señalado en la sentencia nº 797/2010, de 10 de septiembre, con MARCHENA GÓMEZ como presidente de la Sala Segunda del Alto Tribunal, referida a la realización omisiva de un ilícito penal en los delitos de resultado, indica en el FD 17 que: “La jurisprudencia de esta Sala, si bien ha reconocido expresamente que la admisibilidad de una participación omisiva es de difícil declaración, ha aceptado ésta, asociando su concurrencia a la de los elementos propios del art. 11 del CP, entre ellos, que el omitente ocupe una posición de garante (STS 1273/2004, 2 de noviembre). De ahí que sea posible incluso en los delitos de acción, cuando la omisión del deber de actuar del garante haya contribuido, en una causalidad hipotética, a facilitar o favorecer la causación de un resultado propio de un delito de acción o comisión y que podría haberse evitado o dificultado si hubiera actuado como le exigía su posición de garante (cfr. SSTS 19/1998, 12 de enero, 67/1998, 19 de enero, 221/2003, 14 de febrero)”.

Para acabar este apartado, analizaré la referencia que hace la Circular 1/2016 de la FGE respecto a la posición del CCO en relación con su responsabilidad penal y la de la persona jurídica: “Por un lado, el oficial de cumplimiento puede con su actuación delictiva transferir la responsabilidad penal a la persona jurídica a través de la letra a) puesto que, como se ha dicho, está incluido entre las personas que ostentan facultades de organización y control dentro de la misma. Por otro lado, puede ser una de las personas de la letra a) que al omitir gravemente el control del subordinado permite la transferencia de responsabilidad a la persona jurídica. En este supuesto, la omisión puede llevarle a ser él mismo penalmente responsable del delito cometido por el subordinado. Finalmente, si el oficial de cumplimiento omite sus obligaciones de control, la persona jurídica en ningún caso quedará exenta de responsabilidad penal (condición 4ª del art. 31 bis 2). De conformidad con este planteamiento, la exposición personal al riesgo penal del oficial de cumplimiento no es superior a la de otros directivos de la persona jurídica. Comparativamente, su mayor riesgo penal sólo puede tener su origen en que, por su posición y funciones, puede acceder más frecuentemente al conocimiento de la comisión de hechos delictivos, especialmente dada su responsabilidad en relación con la gestión del canal de denuncias y siempre que la denuncia se refiera a hechos que se están cometiendo y que, por tanto, el oficial de cumplimiento pueda impedir con su actuación”.

7.2 El CCO como testigo o como investigado en la instrucción penal

El Juez del Juzgado Central de Instrucción n.º 5 de la Audiencia Nacional ha citado como investigados a siete CCO del Banco de Santander y BNP Paribas, en la pieza separada de entidades financieras de la lista Falciani, por delitos de blanqueo de capitales.

Alfredo Domínguez, socio de Derecho Penal y Coordinador de Corporate Compliance de Cuatrecasas, expuso en unas recientes jornadas que, a su juicio, se está "muy cerca" de vulnerar el derecho de defensa de la persona jurídica en la actual situación, "si el representante de la organización se acoge a su derecho a no declarar y el fiscal o la acusación llama al CCO como testigo y le obliga a testificar". "La persona jurídica, al igual que la física, tiene derecho a definir su estrategia y aportar las pruebas que considere oportunas y necesite".

No entramos aquí, pero también tuvo lugar hace poico en el ICAM una jornada sobre la responsabilidad civil del CCO. Se refuerza pues la necesidad de disponer de un estatuto profesional de la función de Compliance.

7.3 Responsabilidad del DPD

Buscando cierto paralelismo entre ambas figuras, DPD y CCO, según afirma Mar España, directora de la AEPD, “La posición del DPD será próxima a los niveles jerárquicos más elevados dentro de una organización, de manera que aquellos a quienes reporte tengan capacidad de decisión en calidad de Responsables o Encargados del tratamiento. En ningún caso el DPD sustituirá al Responsable del Tratamiento en la toma de decisiones sobre los fines y alcance de los tratamientos, ni deberá asumir la carga de las posibles sanciones en las que pudieran incurrir los Responsables como consecuencia de tratamientos de datos no acordes con el RGPD”.

8. Bibliografía consultada



[1] MACIÁ GÓMEZ, RAMÓN “La posición de garante en el Derecho español: concepto y estructura”. Pórtico legal (Expansión). Enero de 2009. Página Web.

[2] SILVA SÁNCHEZ, JESÚS-MARÍA. “Fundamentos del Derecho Penal de la empresa”. EDISOFER S.L. 2013.

[3] SILVA SÁNCHEZ, JESÚS-MARÍA. “El delito de omisión: Concepto y sistema”. Colección Maestros del Derecho Penal nº 12. Editorial IBdeF. Segunda edición 2010.

[4] GOMEZ-ALLER, DOPICO. “Presupuestos básicos de la responsabilidad penal del Compliance Officer y otros garantes en la empresa”. Actualidad Jurídica Aranzadi Nº 843, página 2. Año 2012.

[5] COLOM, JOSE LUIS. “Compliance en la persona jurídica y las tres líneas de defensa”. Blog “Aspectos Profesionales”. 26 de enero de 2017. Página Web.

[6] MONZÓIN PÉREZ, HELENA. “La naturaleza de la relación laboral del delegado de protección de datos”. UPF - IUSLabor 2/2017. Página Web.

[7] ANLLO, LINA y ALGUACIL, JIMENA. “¿Tiene el Compliance Officer responsabilidad penal?”. Comisión Directiva del capítulo argentino de la WCA. Página WEB.

[8] OSUNA, FERNANDO. “A vueltas con la responsabilidad penal del Chief Compliance Officer”. LEFEBVRE – El Derecho. 5 de octubre de 2017. Página Web.

[9] ESPAÑA, MAR. “El Delegado de Protección de Datos: esquema de certificación, nombramiento, funciones y perfil requerido”. LEFEBVRE – El Derecho. 1 de agosto de 2017. Página Web.

[10] Confederation on Data Protection Organizations (CEDPO). “Posición de CEDPO sobre el Delegado de Protección de Datos (DPO) en el Reglamento General de Protección de Datos (RGPD)”. 15 de febrero de 2017. Página Web.

[11] MARINETTO IGLESIAS, JESÚS. “Responsabilidad de los Directivos”. PRACTICUM de Compliance. THOMSON REUTERS. 2018.

9. 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
28/08/2018
Redacción inicial del artículo
Autor
28/08/2018
Se añade, en relación al artículo original, una observación en el apartado 2.3 Las tres líneas de defensa sobre la conveniencia, o no, de que el DPD realice auditorías de protección de datos.
Editor/Autor















10. Derechos de autor

Imágenes bajo licencia 123RF internacional. La licencia únicamente es válida para su publicación en este blog.



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 técnico, que le facilita el desempeño profesional en el ámbito de los diferentes marcos normativos, ya sean estos jurídicos o de adscripción voluntaria. Está especializado en aplicar normas ISO a entornos jurídicos como pueden ser el Derecho Penal-Económico y el Derecho de las nuevas tecnologías. También es especialista en marcos normativos relacionados con la seguridad de la información como pueden ser ENS e ISO 27001.  A partir de su dilatada experiencia, edita el Blog jurídico “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 y registrado en el Servicio Ejecutivo de la Comisión de Blanqueo de Capitales e Infracciones Monetarias (SEPBLAC).

A nivel de especialización técnica y de gestión, 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, acreditada por ENAC, como Director Técnico (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 anteriormente cómo asesor en materia de Compliance, incidiendo en Compliance Penal, PBC/FT, asesoramiento respecto a cumplimiento normativo, privacidad y auditorías respecto a la seguridad de la información.  Ha participado como lead auditor de diferentes sistemas de gestión basados en Normas ISO 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, asesorando respecto a Privacidad, seguridad de la información y PBC/FT.

Convencido del valor que aportan las organizaciones profesionales, es vocal de la Junta Directiva - miembro de la Comisión de Educación y Certificaciones de INBLAC (Instituto de expertos en la prevención del Blanqueo de Capitales y Financiación del Terrorismo), socio de ASCOM (Asociación Española de Compliance), 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 ENATIC (Asociación de expertos nacionales de la abogacía TIC) y miembro de itSMF (IT Service Management Forum), habiendo sido ponente o colaborado en casi todas las referidas organizaciones.
Es docente en varios Masters y cursos jurídicos organizados por el ICAB, así como del ENS, organizados por el CCN. Es examinador en la AEC del Esquema de Certificación de DPD/DPO propiedad de la AEPD y acreditado por ENAC. Ha obtenido premios compartidos de protección de datos otorgados por la AEPD y la AVPD.






viernes, 27 de octubre de 2017

Integrar la norma ISO 27001, o el Esquema Nacional de Seguridad (ENS), con el RGPD


Resumen: El Reglamento (UE) 2016/679 (RGPD), a diferencia del Reglamento 1720/2007 de desarrollo de la LOPD, introduce el concepto de “Seguridad Activa” que evita, como hasta ahora, señalar un catálogo de medidas de seguridad concretas, dejando la elección de éstas al Responsable y al Encargado en base al riesgo  evaluado respecto a los tratamientos de datos personales. El ENS o la norma ISO 27001:2013, junto a sus respectivas 75 medidas de seguridad y 114 controles, pueden ser una ayuda relevante para el cumplimiento del RGPD.


 
Autor del artículo
Colaboración
José Luis Colom Planas

Actualizado

27 de octubre de 2017




Índice

1. Contexto

2. Introducción al RGPD

3. Las Evaluaciones de Impacto en la Protección de Datos (EIPD)

4. Comparativa entre las normas ISO 27001 y ENS

5. El concepto de Sistema de Gestión y su integración con el RGPD

6. Bibliografía consultada

7. Control de cambios del artículo

8. Derechos de autor

ANEXO I. Comparativa artículos RGPD con controles ISO 27001:2013

ANEXO II. Las 75 medidas de seguridad del ENS



1. Contexto
A partir del artículo publicado por Carlos Galán Cordero [que desempeña su labor profesional en INCIBE] en el Diario La Ley Nº 5, Sección Ciberderecho, el 17 de Marzo de 2017, con el título El esquema nacional de seguridad como mecanismo de certificación del reglamento europeo de protección de datos [1], me decidí a desarrollar dicha idea presentando una ponencia en el Congreso de ISACA en Barcelona, que además de tratar la integración del RGPD con el ENS, por similitud, también lo hace con la norma ISO 27001:2013.

NOTA DEL EDITOR: Ante las múltiples peticiones que he recibido sobre si repetiría la ponencia para quienes no pudieron finalmente asistir, me he decidido a escribir este artículo que, pese a no ser lo mismo que un evento presencial, puede suplir sus efectos.

Ciertamente presenta mayor interés respecto al ENS por una razón de escala. Todas las administraciones públicas en España, o entidades privadas dependientes o que le presten servicios relevantes para sus sistemas de información, están obligadas a cumplir con las disposiciones del ENS. Ello significa que la Administración Pública obligatoriamente contará con las medidas de seguridad que determina el ENS y deberán aprovecharse integrándolas con los requisitos adicionales que se deriven del Reglamento General de Protección de Datos (RGPD).

Presentaré el mismo PPT que empleé en la ponencia incluyendo mis comentarios, esta vez escritos, intercalados entre las “diapositivas”.

La ponencia se divide en cuatro partes:




  • La primera es una introducción al RGPD incidiendo en aquellas características y principios que nos afectarán en esta propuesta de integración con el ENS o la norma ISO 27001.
  • En la segunda se incide en las Evaluaciones de Impacto en la protección de datos (EIPD).
  • La tercera es una comparativa entre la norma ISO 27001:2013 y el ENS.
  • La cuarta es la concreción práctica. Trata de los Sistemas de Gestión de la Seguridad de la Información (SGSI o SGSI-ENS) y su integración con el RGPD.

2. Introducción al RGPD
Incidiré en aquellas características y principios del RGPD que nos afectarán en proyectos de integración con el ENS o la norma ISO 27001.

Lo primero es definir como queda el marco normativo de protección de datos tras la aprobación del Reglamento 2016/679 (UE) General de Protección de Datos (RGPD).




Debe tenerse en cuenta que el Reglamento Europeo, ya aprobado, es un instrumento jurídico de rango superior a las leyes nacionales, de aplicación directa en los estados miembros de la Unión. Eso quiere decir que no requiere de un proceso de transposición al Derecho Nacional como sí ocurría con la Directiva 95/46/CE.

La primera consecuencia es que a partir del 25 de mayo de 2018, fecha en que es de aplicación, quedará desplazado el RD 1720/2007, Reglamento de desarrollo de la LOPD. Aunque no esté técnicamente derogado, sus medidas de seguridad tasadas, en base a una categorización de los datos, choca frontalmente con el concepto de "seguridad activa" con medidas de seguridad consecuencia de la gestión del riesgo para los derechos y libertades de los afectados.

La propia LOPD debería derogarse también, pero dado que el ordenamiento jurídico constituye un sistema interrelacionado, su supresión significaría que deberían modificarse multitud de leyes, concluyéndose por razones de economía legislativa la conveniencia de modificar únicamente la LOPD [2] de modo que asuma el RGPD y añada aspectos de desarrollo específicos que los diferentes estados miembros tienen potestad de decidir.




La primera diferencia relevante entre la LOPD actual y el RGPD es la traslación del centro de gravedad desde los FICHEROS hacia los TRATAMIENTOS.

Esta idea ya la introduje por primera vez en este blog el 24 de septiembre de 2016 en el artículo titulado “La dovela central del Reglamento Europeo de Protección de Datos”. [3] No se trata simplemente de que los ficheros conteniendo datos personales ya no se registren en la Autoridad de Control correspondiente, ya que eso es una simple consecuencia. Se trata de que, en la actualidad, presentan más riesgo para los derechos y libertades de los afectados los tratamientos que los ficheros. Un ejemplo puede ser un conjunto de ficheros conteniendo datos personales aparentemente inocuos sobre los cuales aplicamos tratamientos analíticos de Big Data, infiriendo conocimiento sobre determinadas características de la personalidad… Incluso el mero hecho de conservar datos puede verse como que se les aplica el tratamiento de “almacenamiento y custodia”.




Esa traslación del foco desde los ficheros hacia los tratamientos conlleva una serie de consecuencias:
  • La primera es la desaparición de los tres niveles de seguridad asociados a los datos personales (BÁSICO, MEDIO o ALTO).
  • La segunda es que desaparecen las medidas de seguridad tasadas, como se determinan en el Capítulo III, del Título VIII, del RD 1720/2007, asociadas precisamente a esos tres niveles.




El RGPD, en cambio, tiene un criterio más amplio y abierto, en línea con la tendencia actual de elaboración legislativa para sujetos obligados que sean organizaciones. Se basa en el riesgo. Este es un aspecto sobre el que ya incidí el 22 de diciembre de 2014 en el artículo titulado “Modelos de cumplimiento legal y apreciación del riesgo” elaborado para el blog del Consejo General de la Abogacía Española, gestionado por ENATIC. [7]

El artículo 32.1 RGPD, cuando señala a tenor literal “riesgos de probabilidad y gravedad variables” se está refiriendo de forma indubitada a calcular el valor del riesgo en función  de la probabilidad de materializarse y la consecuencia o gravedad en caso de que finalmente se materialice. Esta idea se explicita en la última línea disponiendo su conveniencia “para garantizar un nivel de seguridad adecuado al riesgo” y así destinarle recursos de forma equilibrada.

Hay en el RGPD un nuevo principio de la protección de datos conocido como ACCOUNTABILITY o principio de rendición de cuentas.




Una primera forma de apreciarlo es mediante la traslación del centro de gravedad de ficheros a tratamientos y en la no obligatoriedad de registrar en la Autoridad de Control los primeros.

Este principio, en síntesis, pretende que Responsables y Encargados del tratamiento actúen y registren esas actuaciones como si tuvieran que rendir cuentas a alguien, sin requerir hacerlo de momento. En otras palabras, todo su trabajo relacionado con la protección de datos deberá estar justificado, conservando esta justificación a disposición de la Autoridad de Control. Dicha justificación podrá ser el resultado de un análisis de riesgos, unas autorizaciones expresas que se hayan recabado, etc. El principio de rendición de cuentas siempre llevará asociadas medidas de control interno.

Como se aprecia en la diapositiva anterior, una de esas medidas de control interno es llevar un Registro de Actividades de Tratamiento, que si bien solo es obligatorio bajo determinados umbrales, en la práctica es dónde pivotará implícitamente el cumplimiento para todas las organizaciones que deseen adecuarse a las disposiciones del nuevo Reglamento Europeo, ya sean de tamaño grande, mediano o pequeño.




Como se desprende del propio artículo 30 RGPD (de color negro en la figura anterior) y entre líneas del resto de artículos (de color azul), éste podría ser el contenido de cada entrada en el Registro de Actividades de Tratamiento.

Haré notar que los ficheros empleados por cada tratamiento, en base a la traslación anteriormente comentada, son un dato más, aunque relevante, de todos los que constituyen cada tratamiento.

3. Las Evaluaciones de Impacto en la Protección de Datos (EIPD)
Ya me he referido antes a que al desaparecer los niveles de los datos (BÁSICO, MEDIO Y ALTO), desaparecían también las medidas de seguridad tasadas que determinaba el próximo a desaparecer RD 1720/2007, Reglamento de desarrollo de la LOPD.




En consecuencia, ya no partimos de la relación de ficheros declarados para hacer el análisis y construir así las diferentes medidas para proteger los datos de naturaleza personal. En su lugar partiremos del Registro de Actividades de Tratamiento dónde constarán todos los tratamientos operativos de la organización que traten o puedan llegar a tratar datos de carácter personal.

Ese Registro es el que emplearemos como base para realizar las EIPD y obtener así acciones de tratamiento que mitiguen los riesgos evaluados como inaceptables.




Las Evaluaciones de Impacto únicamente se harán de aquellas actividades de tratamiento que a priori presenten riesgo para los derechos y libertades de los afectados. En consecuencia será un subconjunto del número total de entradas en el Registro de Actividades de Tratamiento.




Una EIPD puede verse como un proceso de gestión de riesgos focalizada en el ámbito de un único tratamiento de datos personales.

Por tanto, puede basarse en el esquema esencial de la norma ISO 31000:2009, actualmente en revisión, de Gestión de riesgos.

Dicha norma divide la Gestión de riesgos en dos partes:
  • La primera de apreciación del riesgo, que a su vez se divide en identificación o determinación de los riesgos (amenazas) para los principios de la protección de datos que puedan llegar a materializarse; análisis o cálculo del valor del riesgo en función de la probabilidad y la consecuencia (impacto) de su materialización; evaluación o comparación de los valores de riesgo obtenidos con determinado umbral para poder decidir si son aceptables, o por el contrario deben evitarse o tratarse.
  • La segunda es el tratamiento del riesgo, que consiste en planificar, implementar y controlar las acciones que se determinen para tratar y mitigar los riesgos.




En la diapositiva 16 lo vemos plasmado en una herramienta, poniéndose de manifiesto que cada fila se corresponde con determinado riesgo identificado. Para ese riesgo encontraremos la frecuencia (probabilidad) inicial, su consecuencia (impacto) inicial y el valor del riesgo inicial.

Cuando le aplicamos una determinada acción de tratamiento de riesgos, ésta puede alterar la frecuencia o el impacto, modificándose el valor del riesgo residual.

Si dicho valor residual no acaba de satisfacer las expectativas, se debe efectuar otro control adicional para seguir rebajándolo a valores aceptables.

Es conocido, no obstante, que otras alternativas a mitigar el riesgo son aceptarlo -no hacer nada-, evitarlo -eliminando la funcionalidad o el proceso conflictivo, si ello es posible y no desvirtúa el diseño-, o transferirlo externalizándolo por ejemplo en un encargado del tratamiento o contratando un seguro de RC, según el caso.




Es interesante la guía que publicó en 2014 la AEPD titulada “Guía para una Evaluación de Impacto en la Protección de Datos Personales”. [4]

En ella se dispone del anexo III respecto al modelo de informe final de una EIPD. El apartado 8 “Conclusiones” incluye una representación de las medidas técnicas que deben adoptarse, junto a las medidas organizativas.

Por su parte el apartado 6, sobre “Identificación y gestión de riesgos”, señala que debe reflejarse la decisión adoptada para cada riesgo en base a objetivos de control, controles y medidas propuestas. Ignoro si es casualidad, pero el léxico empleado coincide con el de los anexos de las normas ISO 27001 y ENS.

4. Comparativa entre las normas ISO 27001 y ENS

Compararemos a continuación ambas normas de referencia: ISO 27001:2013 y el Esquema Nacional de Seguridad (ENS) en lo que respecta a su catálogo de controles o medidas de seguridad.




Vemos en la diapositiva 19 precedente, respecto a la comparativa entre el anexo A de la norma ISO 27001:2013 y el ENS, que la norma ISO 27001 utiliza el mismo vocabulario: Objetivos de control y controles, siendo 114 los que se determinan en el catálogo, igual que hace el ENS en relación a grupos, subgrupos y medidas de seguridad, siendo 75 las que se determinan también en su correspondiente catálogo.

Debo decir que el hecho de que la norma ISO disponga de 114 controles en su “anexo A” y el ENS únicamente de 75 en su anexo “II”, no significa que este último sea menos completo,  ya que un control del ENS puede expandir en varios de la norma ISO 27001:2013.




En el caso de la norma ISO 27001, se aprecian una serie de dominios divididos entre objetivos de control y controles, recogiéndose los 14 dominios en la transparencia 20 anterior.  Adicionalmente, las cláusulas que van desde la 4 “Contexto de la organización” hasta la 10 “Mejora” constituyen el cuerpo del Sistema de Gestión de la Seguridad de la Información y también son relevantes como se detalla en el Anexo I de este artículo, por cortesía de ISO27K Forum. [5]




Por su parte en el ENS se aprecian los 3 grupos y 14 subgrupos en la transparencia 21 anterior.

Ambas normas, ENS e ISO 27001, cubren ampliamente las medidas organizativas y técnicas relacionadas con la seguridad de la información.




Si queremos ver con algo más de detalle ambos anexos, observamos a simple vista que mientras el Anexo A de la norma ISO 27001 no requiere de comentarios adicionales, en el anexo II del ENS se aprecia que la medida concreta depende de la categoría de los sistemas de información que soportan los servicios, entendidas como BÁSICA, MEDIA Y ALTA.

NOTA del EDITOR: La imagen que se muestra en la diapositiva 22 respecto al ENS es del cuadro resumen de medidas de seguridad. En ese mismo anexo del RD 3/2010 se detalla cada una de ellas, incluso con mayor detalle que en la norma ISO 27001:2013. En relación a ésta última norma, se dispone adicionalmente de la ISO 27002:2013 como guía de buenas prácticas en la aplicación de los controles del anexo A. [En el anexo II de este artículo puede consultarse la tabla completa que aparece en la diapositiva].




Prosiguiendo en la búsqueda de diferencias entre la norma ISO 27001 y el ENS, hay una de sustancial y que tiene que ver con la esencia de la seguridad.

El concepto seguridad de la información es algo abstracto. Si preguntáramos a una amplia muestra de la población estoy convencido que obtendríamos respuestas diversas. Es por eso que se han definido los conocidos como atributos o dimensiones de la seguridad, que ambos marcos entiende de forma diferente.

Para la norma ISO 27001 existen tres dimensiones de la seguridad, que son:
  • Confidencialidad, que preserva la información de modo que únicamente sea accesible o conocida por quien tiene autorización para hacerlo.
  • Integridad, que preserva la información de modo que únicamente sea alterada por quien tiene autorización para hacerlo. Un caso extremo, es la supresión de la información.
  • Disponibilidad, que garantiza que la información sea accesible durante el período acordado, normalmente mediante un acuerdo de nivel de servicio (SLA/ANS). Habitualmente es una dimensión asociada a los servicios que tratan la información.

El Esquema Nacional de Seguridad añade a estas tres, dos dimensiones adicionales:
  • Autenticidad, que garantiza que quien realiza un trámite sea realmente quien dice ser o, desde el punto de vista de la información, garantizar que ésta sea auténtica.
  • Trazabilidad, que asegura que se registren todos los trámites realizados, con indicación de quién los hizo y en qué momento preciso o, desde el punto de vista de la información, posibilitar la comprobación a posteriori de quién la ha accedido, o modificado, y cuando.

Esto es relevante en el análisis general de riesgos de estos marcos normativos, dónde la consecuencia (impacto) de que se materialice un riesgo debe analizarse para cada una de las dimensiones de la seguridad que apliquen, como se aprecia en la diapositiva 23 anterior.

Todo lo anterior y determinados conceptos adicionales  relevantes pueden verse en el cuadro comparativo entre ambas normas en la diapositiva 24.




El Centro Criptológico Nacional (CCN) editó la Guía CCN-STIC-825 "Certificación 27001" [6] en noviembre de 2013, dónde para cada una de las 75 medidas de seguridad del Anexo II del ENS, se ve si queda cubierta, y en que medida, por determinado control del Anexo A de la norma ISO 27001.




En la diapositiva 25 se aprecian los criterios de comparación y en la 26 parte del resumen final.

5. El concepto de Sistema de Gestión y su integración con el RGPD

A diferencia del Reglamento de desarrollo de la LOPD, el RGPD requiere implícitamente de un Sistema de Gestión que soporte y garantice su cumplimiento continuado en el tiempo y esté basado en la mejora continua de sus procesos. Bajo estas circunstancias es una buena opción emplear el que ya esté implantado en la organización en base al ENS o a la norma ISO 27001 y evitar así duplicidades en determinados aspectos.




En la diapositiva 28 paso a definir que entiendo por un Sistema de Gestión de la Seguridad de la Información (SGSI) basado en el riesgo.




Dicho SGSI debe tener como cimientos la comprensión del contexto en que se desenvuelve la organización que lo implanta. A partir de ese conocimiento el Sistema de gestión se sustentará por tres pilares fundamentales: La gestión de riesgos, el seguimiento de acciones y la declaración de aplicabilidad. Iremos analizando cada uno de ellos.




Debe basarse en el ciclo de Deming o PDCA, entendido como una estrategia de mejora continuada en cuatro pasos: planificar, hacer, comprobar y actuar, y así de forma recurrente sin fin.

Los dos primeros pilares son comunes a cualquier sistema de gestión actual -desde el año 2012-, mientras que la declaración de aplicabilidad únicamente se encuentra en aquellos Sistemas que dispongan de un catálogo de controles o medidas de seguridad en sus anexos.




Si lo expresamos en un diagrama con mayor detalle, observamos en la transparencia 31 que, además del contexto de la organización, las tres cajas azules corresponden a los tres pilares de un SGSI que acabamos de comentar.

La primera caja azul es la Gestión de riesgos, que se compone como ya hemos visto de un proceso de apreciación y otro de tratamiento de los riesgos identificados.

La segunda caja azul es el seguimiento de acciones. Si un SGSI es incapaz de generar acciones es que no está persiguiendo la mejora continua. Si todo el “tinglado” no es capaz de actuar, es que únicamente monitoriza y entonces se convierte en prescindible.

Como ejemplo de acciones tenemos:
  • Acciones para alcanzar los objetivos estratégicos de seguridad de la información (ISO 27001).
  • Acciones de Tratamiento de los riesgos evaluados como inaceptables, para su mitigación.
  • Acciones para dar curso a las propuestas de mejora por parte de cualquier parte interesada interna o externa.
  • Acciones para corregir las desviaciones en las auditorías periódicas (No conformidades, observaciones…).




Y entrando por fin en el objetivo de esta ponencia, que no es otro que mostrar la integración del RGPD en un SGSI o SGSI-ENS, vemos en la diapositiva 32  que un punto de contacto son las Evaluaciones de Impacto en la Protección de Datos (EIPD).

Hemos visto anteriormente que una EIPD es una gestión de riesgos especializada, que focaliza en determinada acción de tratamiento. En consecuencia, podemos alterar el diagrama anterior para que contemple las EIPD.




Vemos así que en la caja azul de Gestión de Riesgos se contemplan tanto los riesgos generales de seguridad de la información de la organización, provenientes del ENS o de la norma ISO 27001, como los específicos de protección de datos provenientes de las diferentes EIPD.

El seguimiento de acciones, con esta nueva composición, vemos que no se altera y podrá seguir siendo común.




Pensemos que no ocurre absolutamente nada, al ser algo natural, que contemplemos conjuntamente diferentes clasificaciones de la información. Coexistirán datos personales junto a información clasificada (Pública, uso interno, restringida y confidencial, por ejemplo), como se muestra en la diapositiva 35 orientada al ENS. Incluso habrá datos personales que podrían considerarse simultáneamente información clasificada, según el caso.




En la diapositiva 36 muestro un ejemplo, en este caso para mayor didáctica lo presento en Excel, de un Seguimiento de Acciones del SGSI-ENS.

Se aprecia que hay un bloque de registro inicial, otro de evaluación de las causas y determinación de acciones y un tercero, que veremos luego al no caber en la diapositiva, de plan de proyecto.

Vemos que cada fila, que representa una entrada, identifica si la acción es común, corresponde específicamente al RGPD o bien lo hace respecto al SGSI-ENS.

Lo importante es resaltar que la estructura es común y su gestión conjunta nos simplifica el Sistema de Gestión Integrado RGPD-SGSI-ENS.




Lo que faltaría (parte derecha de las filas del Excel) es gestionar cada una de las acciones del SGSI-ENS como un mini proyecto, indicando que recursos se requerirán, quién se responsabiliza de la acción, fechas estimadas de inicio y final y como se evaluarán los resultados para poder cerrarla. Un indicador de avance de la acción sería muy útil.




En cuanto a la tercera caja azul, la Declaración de Aplicabilidad, en la diapositiva 38 se muestra respecto al anexo A de la norma ISO 27001:2013.  En este caso incorpora de facto 114 controles, algunos de los cuales podríamos llegar a excluir de forma motivada.

Para cada control se indica su código según la norma, su descripción, si aplica o no, un detalle de cómo se aplica y los posibles documentos vinculados a ese control, su origen (Análisis de riesgos, requisito legal…) y la vinculación con el desencadenante que motiva su aplicación (como puede ser la referencia a una acción de tratamiento de riesgos).




Una característica de las declaraciones de aplicabilidad es que pueden añadirse controles adicionales que se determinen relevantes para la organización.

En la diapositiva 39 se aprecia cómo se ha añadido a la Declaración de Aplicabilidad un control específico para el RGPD, que además se vincula a la acción de tratamiento de la diapositiva 36 “TR001/17”.

Podemos buscar controles que apliquen al RGPD en la propia Guía de la AEPD, de otras Autoridades de Control, o construirla nosotros a partir de una lectura detallada del Reglamento Europeo.  Algunas herramientas o plataformas informáticas preparadas para el RGPD incluyen una amplia colección de controles, siendo un ejemplo cualquiera el que se aprecia en la diapositiva 16.




Ya para acabar, en la diapositiva 40 se muestran las conclusiones de esta ponencia.




NOTA DEL EDITOR: Recordar que se incluye en el anexo I, cortesía de ISO27K Forum © y sujeta a propiedad intelectual, una completa tabla de equivalencia (en inglés) entre los artículos del GDPR y las cláusulas y controles de la norma ISO 27001:2013. [5]


6. Bibliografía consultada

- [1] Carlos Galán Cordero. “El esquema nacional de seguridad como mecanismo de certificación del reglamento europeo de protección de datos”. 17 de Marzo de 2017. Diario La Ley, Nº 5. Sección Ciberderecho.
El ENS como mecanismo de certificación el RGPD


- [2] Ministerio de Justicia. “ANTEPROYECTO DE LEY ORGÁNICA DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL. 8 de Junio de 2017.



- [3] José Luis Colom Planas. La dovela central del Reglamento Europeo de Protección de Datos”. Blog “Aspectos profesionales”. 24 de septiembre de 2016.



- [4] AEPD. “Guía para una Evaluación de Impacto en la Protección de Datos Personales”. Agencia Española de Protección de Datos - 2014.



- [5] ISO27K Forum. Mapping between GDPR (the EU General Data Protection Regulation) and ISO27k”. Release 1. November 2016.



- [6] Centro Criptológico Nacional (CCN). “Guía CCN-STIC-825 -Certificaciones 27001-”. Noviembre de 2013.



- [7] 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.

- [8] UE. “Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos). 4 de mayo de 2016.
RGPD


7. 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
27/10/2017
Redacción inicial del artículo
Autor
29/10/2017
Se añade el anexo III, con fotografías del evento facilitadas por el gerente de ISACA Barcelona, Carles Mateu.
Autor















8. Derechos de autor

Imágenes bajo licencia 123RF internacional. La licencia únicamente es válida para su publicación en este blog.

Diapositivas creadas por el autor. La tabla del anexo I es cortesía de ISO27K Forum quién conserva los derechos de 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:



José Luis Colom Planas Posee un doble perfil, jurídico y técnico, que le facilita el desempeño profesional en el ámbito de los diferentes marcos normativos, ya sean estos jurídicos o de adscripción voluntaria. Está especializado en aplicar normas ISO a entornos jurídicos como pueden ser el Derecho Penal-Económico y el Derecho de las nuevas tecnologías. También es especialista en marcos normativos relacionados con la seguridad de la información como pueden ser ENS e ISO 27001.  A partir de su dilatada experiencia, edita el Blog jurídico “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 y registrado en el Servicio Ejecutivo de la Comisión de Blanqueo de Capitales e Infracciones Monetarias (SEPBLAC).

A nivel de especialización técnica y de gestión, 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 Técnico (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 auditorías respecto a la seguridad de la información.  Ha participado como lead auditor de diferentes sistemas de gestión basados en Normas ISO 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 vocal de la Junta Directiva - miembro de la Comisión de Educación y Certificaciones de INBLAC (Instituto de expertos en la prevención del Blanqueo de Capitales y Financiación del Terrorismo), socio de ASCOM (Asociación Española de Compliance), CUMPLEN (Asociación de Profesionales de Cumplimiento Normativo), 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 ENATIC (Asociación de expertos nacionales de la abogacía TIC), miembro de itSMF (IT Service Management Forum) y ATI (Asociación de Técnicos de Informática), habiendo sido ponente o colaborado en casi todas las referidas organizaciones. Ha obtenido, junto a algunos miembros de la iniciativa del Observatorio Iberoamericano de Protección de Datos (OIPRODAT), un premio compartido otorgado por la AEPD y ha sido docente en varios cursos jurídicos organizados por el ICAB.




ANEXO I. Comparativa artículos RGPD con controles ISO 27001:2013

Release 1   November 2016

Disclaimer



This is not legal advice, nor is it information risk, information security or privacy advice.  This generic high-level document is provided purely for informational or general guidance purposes.  You need to interpret and adapt it for your own unique situation, and if GDPR applies to your organization, you should definitely seek competent legal and other professional advice concerning the adequacy and suitability of your particular security controls and other privacy arrangements.   Don’t take our word for anything or blame us for the inevitable errors and omissions: we’re simply trying to help.

Copyright


 This work is copyright © 2016, ISO27k Forum, some rights reserved.  It is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.  In plain English, you are welcome to reproduce, circulate, use and create derivative works from this provided that (a) they are not sold or incorporated into a commercial product, (b) they are properly attributed to the ISO27k Forum, and (c) if they are to be shared or published, derivative works are covered by the same Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.  Be nice.  Contact Gary@isect.com if this license is unsuitable for your intended use.

The mapping

ISO27k controls without the prefix ‘A’ are in the main body of ISO/IEC 27001:2013.  Those prefixed with ‘A’ are listed in Annex A of ISO/IEC 27001:2013 and are explained in more detail in ISO/IEC 27002:2013.  Further ISO27k standards fill-in various supplementary details (e.g. ISO/IEC 27005 on information risk management and ISO/IEC 27018 on privacy in cloud computing), while other ISO and non-ISO standards and resources provide lots more information, and in some cases recommend alternative or complementary approaches and controls.

GDPR
ISO27k
Article
Outline/summary
Control
Notes
1
GDPR concerns the protection and free movement of “personal data”, defined in article 4 as “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.
A.18.1.4
etc.
The ISO27k standards concern information risks, particularly the management of information security controls mitigating unacceptable risks to organizations’ information.  In the context of GDPR, privacy is largely a matter of securing people’s personal information, particularly sensitive computer data.  The ISO27k standards specifically mention compliance obligations relating to the privacy and protection of personal info (more formally known as Personally Identifiable Information - PII - in some countries) in control A.18.1.4.
2
GDPR concerns “the processing of personal data wholly or partly by automated means ....” (essentially, IT systems, apps and networks) and in a business or corporate/organizational context (private home uses are not in scope).
Many
ISO27k concerns information in general, not just computer data, systems, apps and networks.  It is a broad framework, built around a ‘management system’.  ISO27k systematically addresses information risks and controls throughout the organization as a whole, including but going beyond the privacy and compliance aspects.
3
GDPR concerns personal data for people in the European Union whether is it processed in the EU or elsewhere
A.18.1.4
etc.
ISO27k is global in scope.  Any organization that interacts with people in the European Union may fall under GDPR, especially of course if they collect personal info.
4
GDPR privacy-related terms are formally defined here.
3
ISO/IEC 27000 defines most ISO27k terms including some privacy terms.  Many organizations have their own glossaries in this area.  Check that any corporate definitions do not conflict with GDPR.
Chapter I  General provisions
5
Personal data must be: (a) processed lawfully, fairly and transparently; (b) collected for specified, explicit and legitimate purposes only; (c) adequate, relevant and limited; (d) accurate; (e) kept no longer than needed; (f) processed securely to ensure its integrity and confidentiality. 

[This is the latest incarnation of the original OECD principles published way back in 1980 <tips hat>.]








The “controller” is accountable for all that.
6.1.2,
A.8.1.1
A.8.2
A.8.3
A.9.1.1
A.9.4.1
A.10
A.13.2
A.14.1.1 A.15
A.17
A.18 ...
in fact almost all!

5
A.6.1.1
Business processes plus apps, systems and networks must adequately secure personal information, requiring a comprehensive suite of technological, procedural, physical and other controls … starting with an assessment of the associated information risks.  See also ‘privacy by design’ and ‘privacy by default’ (Article 25).

In order to satisfy these requirements, organisations need to know where personal info is, classify it and apply appropriate measures to address (a)-(f).






Although not stated as such, accountability is an important concept within the ‘Leadership’ section of ISO/IEC 27001.
6
Lawful processing must: (a) be consented to by the subject for the stated purpose; (b) be required by a contract; (c) be necessary for other compliance reasons; (d) be necessary to protect someone’s vital interests; (e) be required for public interest or an official authority; and/or (f) be limited if the subject is a child. 

Note: there are several detailed and explicit requirements concerning lawful processing - see GDPR!

Note also that EU member states may impose additional rules.
6.1.2 A.14.1.1
A.18.1.1
etc.
This should also be covered in the assessment and treatment of information risks.  It will influence the design of business processes/activities, apps, systems etc. (e.g. it may be necessary to determine someone’s age before proceeding to collect and use their personal info).  These are business requirements to limit and protect personal information: many security controls are required in practice to mitigate unacceptable information risks that cannot be avoided (by not collecting/using the data) or shared (e.g. relying on some other party to get consent and collect the data - a risk in its own right!).
7
The data subject’s consent must be informed, freely given and they can withdraw it easily at any time.
A.8.2.3
A.12.1.1
A.13.2.4?
A.18.1.3

6.1.2 A.14.1.1
A.8.3.2
A.13.2
etc.
There is a requirement to request informed consent for processing (otherwise stop!) and to be able to demonstrate this. Procedures need to be in place for this and records demonstrating the consent must be protected and retained.


Withdrawal of consent implies the capability to locate and remove the personal info, perhaps during its processing and maybe also from backups and archives, plus business processes to check and handle requests.
8
Special restrictions apply to consent by/for children.
See
Article 7
These special restrictions apply primarily at the time information is gathered (e.g. getting a parent’s consent).
9
Special restrictions apply to particularly sensitive data concerning a person’s race, political opinions, religion, sexuality, genetic info and other biometrics etc.  Processing of such info is prohibited by default unless consent is given and processing is necessary (as defined in the Article).
A.8.2.1
A.8.2.3
A.14.1.1
See 7 above. It is important to identify where sensitive data may be processed, whether that is ‘necessary’ in fact, and to obtain explicit consent - factors to be considered in the design of systems, apps and business processes.
10
Special restrictions also apply to personal data concerning criminal convictions and offenses.
A.7.1
A.8.2.1
A.8.2.3
6.1.2
A.14.1.1 A.7.1
etc.
Any use of this information should be identified and only processed in specific circumstances. Such information should preferably not be retained except by the authorities … but may be needed for background checks, credit/fraud risk profiling etc.
11
Some restrictions don’t apply if a person cannot be identified from the data held.
A.8.2.1
A.8.2.3
6.1.2 A.14.1.1
etc.
Avoiding information risks (by NOT knowing who the subjects are) is a good option, where feasible: does the business really need to know a person’s identity or will aggregate info/statistics suffice?
Chapter III   Rights of the data subject
12
Communications with data subjects must be transparent, clear and easily understood.
A.12.1.1
A.14.1.1
A.16
etc.
See above.  This affects the wording of web forms, notifications, telephone scripts etc. plus the processes.  It may also be relevant to incident management i.e. mechanisms allowing people to enquire or complain in relation to their own personal information (implying a means to identify and authenticate them), for responding promptly, and for keeping records of such comms (e.g. to limit or charge for excessive requests)
13
When personal data are collected, people must be given (or already possess) several specific items of information such as details of the data “controller” and “data protection officer”, whether their info will be exported (especially outside the EU), how long the info will be held, their rights and how to enquire/complain etc.
A.8.2.1
A.8.2.3
A.12.1.1
A.14.1.1
A.16
etc.
Procedures for the provision of fair processing information, information on the data controller and purposes for processing the data need to be defined and implemented. This relies in part on identifying where personal info is in use.
14
Similar notification requirements to Article 13 apply if personal info is obtained indirectly (e.g. a commercial mailing list?): people must be informed within a month and on the first communication with them.
A.8.2.1
A.8.2.3
A.12.1.1
A.14.1
A.16
etc.
See Article 13.
15
People have the right to find out whether the organization holds their personal info, what it is being used for, to whom it may be disclosed etc., and be informed of the right to complain, get it corrected, insist on it being erased etc.
People have rights to obtain a copy of their personal information.
A.8.1.1
A.8.2.1
A.12.1.1
A.13.2.1
A.14.1.1
etc.
Subject rights include being able to obtain a copy of their own info (again implying the need for identification and authentication before acting on such requests), disclosing the nature of processing e.g. the logic behind and the consequences of ‘profiling’, and info about the controls if their data are exported. It may also affect backup and archive copies. See also Article 7 on withdrawal of consent.
16
People have the right to get their personal info corrected, completed, clarified etc.
A.12.1.1
A.14.1
A.9
A.16?
A.12.3 A.18.1.3
Implies functional requirements to check, edit and extend stored info, with various controls concerning identification, authentication, access, validation etc.  It may also affect backup and archive copies.
17
People have a right to be forgotten i.e. to have their personal info erased and no longer used.
6.1.2 A.14.1.1
A.9
A.16
A.12.3
A.8.3.2
This is a form of withdrawing consent (see Article 7). Implies system & process functional requirements to be able to erase specific stored info, with various controls concerning identification, authentication, access, validation etc.  It may also affect backup and archive copies.
18
People have a right to restrict processing of their personal info.
6.1.2
A.8.2.1
A.8.2.3
A.12.1.1
A.14.1.1 A.16
A.12.3
A.18.1.1
See Articles 7, 12 etc. 
May need ways to identify the specific data that is to be restricted and implement new handling / processing rules. Note it may also affect backup and archive copies.
19
People have a right to know the outcome of requests to have their personal info corrected, completed, erased, restricted etc.
A.12.1.1
6.1.2 A.14.1.1 A.16
etc.
Informing/updating the originator is a conventional part of the incident management process, but there may be a separate or parallel process specifically for privacy complaints, requests etc. since the originators here are not usually employees/insiders.
20
People have a right to obtain a usable ‘portable’ electronic copy of their personal data to pass to a different controller.
6.1.2
A.13 A.14.1.1 A.8.3
A.10 A.18.1.3
etc.
Depending on your organisation’s purpose, this may seem such an unlikely scenario in practice (low risk) that it may best be handled by exception, manually, without automated IT system functions.  Note that the extracted data must be limited to the identified and authenticated person/s concerned, and must be communicated securely, probably encrypted.  It may also imply erasing or restricting the data and confirming this (Articles 17, 18 and 19).
21
People have a right to object to their information being used for profiling and marketing purposes.
6.1.2
A.12.1.1
A.14.1.1 A.16
A.12.3
etc.
See article 18.
May need ways to identify the specific data that is not to be processed and implement new handling / processing rules.
22
People have a right to insist that key decisions arising from automatic processing of their personal info are manually reviewed/reconsidered.
6.1.2 A.12.1.1
A.14.1.1 A.16
Profiling and decision support systems involving personal info must allow manual review and overrides, with the appropriate authorization, access and integrity controls etc.
23
National laws may modify or override various rights and restrictions for national security and other purposes.
A.18.1.1
This is primarily of concern to the authorities/public bodies and their systems (e.g. police, customs, immigration, armed forces), but may affect some private/commercial organizations, either routinely (e.g. legal sector, defence industry, ISPs, CSPs, money laundering rules in financial services?) or by exception (implying a legally-sound manual process to assess and handle such exceptional situations).
Chapter IV  Controller and processor
24
The “controller” (generally the organization that owns and benefits from processing of personal info) is responsible for implementing appropriate privacy controls (including policies and codes of conduct) considering the risks, rights and other requirements within and perhaps beyond GDPR.
4, 5, 6, 7, 8, 9, 10 and much of Annex A
This is a formal reminder that a suitable, comprehensive mesh of privacy controls must be implemented, including policies and procedures as well as technical, physical and other controls addressing the information risks and compliance obligations.  The scale of this typically requires a structured, systematic approach to privacy.  Given the overlaps, it normally makes sense to integrate or at least align and coordinate privacy with the ISO27k ISMS and other aspects such as compliance and business continuity management - in other words, it is a governance issue.
25
Taking account of risks, costs and benefits, there should be adequate protection for personal info by design, and by default.
6 and much of Annex A
There are business reasons for investing appropriately in privacy, including information risks and compliance imperatives, as well as implementation options with various costs and benefits: elaborating on these is a good way to secure management support and involvement, plus allocate the funding and resources necessary to design, deliver, implement and maintain the privacy arrangements.  Privacy by design and by default are examples of privacy principles underpinning the specification, design, development, operation and maintenance of privacy-related IT systems and processes, including relationships and contracts with third parties e.g. ISPs and CSPs.
26
Where organizations are jointly responsible for determining and fulfilling privacy requirements collaboratively, they must clarify and fulfil their respective roles and responsibilities.
5.3
9.1
A.13.2
A.15
A.16
A.18.1
Organizations need to manage relationships with business partners, ensuring that privacy and other information security aspects don’t fall between the cracks.  This includes, for instance, jointly investigating and resolving privacy incidents, breaches or access requests, achieving and maintaining an assured level of GDPR compliance, and respecting consented purposes for which personal info was initially gathered, regardless of where it ends up.
27
Organizations outside Europe must formally nominate privacy representatives inside Europe if they meet certain conditions (e.g. they routinely supply goods and services to, or monitor, Europeans).
 5.3
7.5.1
A.15? A.18.1.4
This is one of many compliance formalities: the Privacy Officer (or Data Protection Officer or equivalent) should be accountable for making sure this is done correctly.
28
If an organisation uses one or more third parties to process personal info (‘processors’), it must ensure they too are compliant with GDPR.
8.2
9.1
A.15 A.18.1.1 A.18.1.3 A.18.1.4
This applies to ISPs and CSPs, outsourced data centres etc., plus other commercial services where the organization passes personal info to third parties e.g. for marketing plus HR, payroll, tax, pension and medical services for employees.  It also applies on the receiving end: service suppliers can expect to be questioned about their GDPR compliance status, privacy policies and other controls (e.g. any subcontractors), and to have compliance and assurance clauses/terms and liabilities included in contracts and agreements.  The information risks need to be identified, assessed and treated in the normal manner, on both sides.
29
Processors must only process personal info in accordance with instructions from the controller and applicable laws.
Most
Processors need to secure and control personal info in much the same way as controllers.  They may well be controllers for personal info on employees etc. so will hopefully have all necessary privacy arrangements in hand anyway: it’s ‘just’ a case of extending them to cover client info, and manage privacy within client relationships (e.g. how to handle breaches or other enquiries, incidents and issues).
30
Controllers must maintain documentation concerning privacy e.g. the purposes for which personal info is gathered and processed, ‘categories’ of data subjects and personal data etc.
7.5
More important formalities.
31
Organizations must cooperate with the authorities e.g. privacy or data protection ombudsmen.
A.6.1.3
Another formality.
32
Organizations must implement, operate and maintain appropriate technical and organizational security measures for personal info, addressing the information risks.
8.2
8.3
and most of Annex A
GDPR mentions a few control examples (such as encryption, anonymization and resilience) covering data confidentiality, integrity and availability aspects, plus testing/assurance measures and compliance by workers (implying policies and procedures, awareness/training and compliance enforcement/reinforcement).  An ISO27k ISMS provides a coherent, comprehensive and structured framework to manage privacy alongside other information risk and security controls, compliance etc.
33
Privacy breaches that have exposed or harmed personal info must be notified to the authorities promptly (within 3 days of becoming aware of them unless delays are justified).
A.16 A.18.1.4
Breaches etc. would normally be handled as incidents within the ISMS incident management process but GDPR-specific obligations (such as the 3-day deadline for notifying the authorities) must be fulfilled.  Note that losses or thefts of IT devices containing personal info are probably not notifiable if the data are strongly encrypted (but remember this is NOT legal advice!). Note also that the point the clock starts ticking is not explicitly defined: it is arguably appropriate to gather and assess the available information/evident first to determine whether or not a reportable incident has actually occurred i.e. the clock may not start until the incident is declared genuine, not a false-alarm.
34
Privacy breaches that have exposed or harmed personal info and hence are likely to harm their interests must be notified to the people so affected ‘without undue delay’.
A.16 A.18.1.4
Aside from the legal and ethical considerations and direction/guidance from the privacy authorities, there are obviously significant business issues here concerning the timing and nature of disclosure.  This would normally be a part of the incident management process for serious or significant incidents, involving senior management as well as specialists and advisors.  Avoiding exactly this situation and the associated business costs, disruption and aggravation is one of the strongest arguments to make privacy a corporate imperative, and to invest appropriately in appropriate preventive measures.  The same point applies to other serious/significant information incidents of course.
35
Privacy risks including potential impacts must be assessed, particularly where new technologies/systems/arrangements are being considered, or otherwise where risks may be significant (e.g. ‘profiling’ defined in Article 4 as “any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements”).  ‘Significantly risky situations’ are to be defined by the national privacy authorities, apparently.
6.1.2
A.6.1.3 A.8.2.1 ISO/IEC 27005 and ISO 31000
Again, there are sound business and ethical reasons to identify, assess and treat information risks (including privacy and compliance risks), aside from the GDPR obligations.  Privacy-related risks should probably be included in corporate risk registers alongside various other risks.  GDPR also hints at integrating the assessment of privacy risks as part of the routine risk assessment activities for business change projects, new IT systems developments etc.
36
Privacy risks assessed as “high” [undefined] should be notified to the authorities, giving them the chance to comment.
6.1.2
A.6.1.3
A.8.2.1 ISO/IEC 27005 and ISO 31000
The GDPR requirement is well-meaning but vague: this might be covered in corporate policies concerning the precise definition of “high” privacy risks … but on the other hand explicit inputs from the authorities may be helpful in terms of an official position on the suitability and adequacy of proposed controls - in other words this comes down to a business risk/strategic decision by management.
37
A data protection officer must be formally identified under specified circumstances e.g. public bodies, organizations regularly and systematically monitoring people on a large scale, or those performing large-scale processing of sensitive personal info relating to criminal records.
5.3
A.6.1.1 A.18.1.4
Aside from GDPR obligation, the “Privacy Officer” role (or equivalent titles) is much more broadly applicable and valuable, whether full or part-time, formal or informal, notifiable or not.  There are clearly many angles to privacy: a designated corporate focal point for privacy (ideally a competent privacy specialist or expert) makes sense for virtually all organizations. This is another governance issue.
38
[If formally designated] the data protection officer must be supported by the organization and engaged in privacy matters.
5.3
A.6.1.1 A.18.1.4
See above.  Formalities aside, without management support and engagement with the organization, a Privacy Officer is powerless and pointless.
39
[If formally designated] the data protection officer must offer advice on privacy matters, monitor compliance, liaise with the authorities, act as a contact point, address privacy risks etc.
5.3
A.6.1.1 A.18.1.4
See above.  The GDPR requirements would form the basis of a Privacy Officer role description.
40
Various authorities, associations and industry bodies are anticipated to draw up codes of conduct elaborating on GDPR and privacy, offer them to be formally approved (by an unspecified mechanism) and (where appropriate) to implement their own (member) compliance mechanisms.
5.3,
A.6.1.1 A.18.1.4
Although this is a valiant attempt to add weight to industry codes, it struggles to achieve a full legal mandate … but the ethical obligation is clear: privacy is more than just a matter of strict compliance with formal, legal obligations.  Aside from that, codes (and ISO27k standards!) offer good practice guidance, and compliance may generate commercial/marketing advantages.
41
The bodies behind codes of conduct are required to monitor compliance (by their members), independently and without prejudice to the legal and regulatory compliance monitoring conducted by the national authorities.
5.3
A.6.1.1 A.18.1.4
See above.
42
Voluntary data protection certification schemes offering compliance seals and marks (valid for 3 years) are to be developed and registered.
5.3
A.6.1.1 A.18.1.4
Similar schemes already exist: GDPR gives them some official recognition, on top of the commercial advantages they already exploit. 
43
Certification bodies that award compliance seals and marks should be competent and accredited for this purpose.  The European Commission may impose technical standards for certification schemes.
5.3
A.6.1.1 A.18.1.4
This should improve the credibility and meaning of privacy seals and marks, but may also increase the costs.  Since they are voluntary, whether or not to be certified, and which schemes to join, are commercial/business matters for management.
Chapter V  Transfers of personal data to third countries or international organisations
44
International transfers and processing of personal info must fulfil requirements laid down in subsequent Articles.
-
Preamble.
45
Data transfers to countries whose privacy arrangements (laws, regulations, official compliance mechanisms ...) are deemed adequate by the European Commission (i.e. compliant with GDPR) do not require official authorisation or specific additional safeguards.
A.18.1.4
Most formalities are to be handled by the Commission. Compliance involves avoiding transfers to other countries, monitoring the official lists for changes, and ensuring that suitable contracts/agreements and other privacy controls are in place as with other third party data transfers (see Article 28 especially).
46
Data transfers to countries whose privacy arrangements (laws, regulations, official compliance mechanisms ...) are not deemed adequate by the European Commission (i.e. compliant with GDPR) but meet certain other criteria require additional safeguards.
A.18.1.4
Essentially, the organization must implement and ensure the adequacy of privacy controls before transferring personal data to such countries, and subsequently e.g. suitable contractual clauses and compliance activities.
47
National authorities may approve legally-binding privacy rules permitting transfers to non-approved countries.
A.18.1.4
Formalities may affect contractual terms, compliance arrangements, liabilities etc.  Hint: it may not be worth the aggravation, risks and costs.
48
Requirements on European organizations from authorities outside Europe to disclose personal data may be invalid unless covered by international agreements or treaties.
A.18.1.4, A.16
Such situations would normally be handled by legal and regulatory compliance specialists - but may start out as incidents.
49
Yet more conditions apply to personal info transfers to non-approved countries e.g. explicit consent by the data subjects.
A.18.1.4
The Commission is deliberately making it difficult, or rather taking great care since the privacy risks are higher.
50
International authorities will cooperate on privacy
-
-
Chapter VI  Independent supervisory authorities
51-59
[Concern national bodies to oversee privacy.]
-
-
Chapter VII  Cooperation and consistency
60-76
[Concern supervisory authorities and the EU Data Protection Board.]
-
-
Chapter VIII  Remedies, liability and penalties
77-81
[Supervisory authorities can deal with privacy complaints.]
-
-
82
Anyone damaged by infringements of GDPR has a right to compensation from the controller/s or processor/s.
A.18.1.4
-
83
Administrative fines imposed by supervisory authorities shall be “effective, proportionate and dissuasive”.  Various criteria are defined.  Depending on the infringements and circumstances, fines may reach 20 million Euros or up to 4% of total worldwide annual turnover for the previous year if greater.
6
A.18.1.4
Such huge fines are clearly intended to be a strong deterrent, representing a significant part of the potential impact of privacy breaches etc. in the organization’s assessment of GDPR compliance and other privacy risks.
84
Other penalties may be imposed.  They too must be “effective, proportionate and dissuasive”.
6
A.18.1.4
See above. 
Chapter IX  Provisions relating to specific processing situations
85
Countries must balance privacy/data protection rights against freedom of expression, journalism, academic research etc. through suitable laws.
6
A.18.1.1
A.18.1.4
Issues under this Article may come down to differing legal interpretations in court, hence again there are information risks to be identified, assessed and treated where personal information is involved.
86
Personal data in official documents may be disclosed if the documents are formally required to be disclosed under ‘freedom of information’-type laws.
6
A.18.1.1 A.18.1.4
It may be feasible to redact personal or other sensitive information instead - see ISO/IEC 27038.
87
Countries may impose further privacy controls for national ID numbers.
6
A.18.1.1
A.18.1.4
National ID numbers may be used as secret personal authenticators, in which case they must remain confidential to reduce the risk of identity theft.  In effect they are sensitive personal information, implying the need for encryption and other security/privacy controls.
88
Countries may impose further constraints on corporate processing and use of personal information about employees e.g. to safeguard human dignity and fundamental rights.
6
A.18.1.1
A.18.1.4
Employment laws may intersect with GDPR and privacy, further complicating compliance and altering the information risks in this area.
89
Where personal data are to be archived e.g. for research and statistical purposes, the privacy risks should be addressed through suitable controls such as pseudonymization and data minimization where feasible.
6
A.18.1.4
Privacy concerns remain as long as the data subjects are alive (perhaps longer if their families or communities may be impacted by breaches).  Taking account of this, the information risks should be identified, assessed and treated appropriately in the normal way.
90
Countries may enact additional laws concerning workers’ secrecy and privacy obligations.
6
A.18.1.1
A.18.1.4
Employment or secrecy laws may intersect with GDPR and privacy, still further complicating compliance and altering the information risks in this area.
91
Pre-existing privacy rules for churches and religious associations may continue, “provided they are brought into line with” GDPR.
A.18.1.4
Good luck interpreting this highly ambiguous Article!
Chapter X  Delegated acts and implementing acts
92-99
[Concern how GDPR is being enacted by the EU.]
A.18.1.1
Not relevant to an individual organization’s privacy arrangements, except in as much as they need to comply with applicable laws and regulations.



The “Recitals” - extensive notes preceding the Articles in GDPR - are worth reading for additional explanation relevant to information security plus some (implicit) control requirements.  For instance:

Recital 39 ends with “Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing.” - an important requirement not entirely clear from the Articles.

Recital 49 notes (in effect) that systems and network security monitoring (e.g. to detect and respond to hacks, denial-of-service attacks etc.) is a “legitimate interest of the data controller concerned”, hence it is not unlawful to capture personal data during such activities (even without the data subjects’ explicit consent) … but this doesn’t negate the need to secure it, to declare it as one of the “purposes” and to inform system/network users that the information may be monitored for such purposes.

Recital 83 starts “In order to maintain security and to prevent processing in infringement of this regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption.”  The information-risk-driven approach is fundamental to ISO27k.



ANEXO II. Las 75 medidas de seguridad del ENS

Se relacionan a continuación, de forma esquemática, las 75 medidas de seguridad que determina el Anexo II del 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, contemplando el RD 951/2015, de 23 de octubre, de modificación del ENS.

Pueden verse las medidas que aplican en función de la categorización de los sistemas y, en su caso, de la dimensión de seguridad afectada.

Dimensiones

Medidas de seguridad
Afectadas
B
M
A


org
Marco organizativo
categoría
aplica
=
=
org.1
Política de seguridad
categoría
aplica
=
=
org.2
Normativa de seguridad
categoría
aplica
=
=
org.3
Procedimientos de seguridad
categoría
aplica
=
=
org.4
Proceso de autorización


op
Marco operacional




op.pl
Planificación
categoría
aplica
+
++
op.pl.1
Análisis de riesgos
categoría
aplica
+
++
op.pl.2
Arquitectura de seguridad
categoría
aplica
=
=
op.pl.3
Adquisición de nuevos componentes
D
n.a.
aplica
=
op.pl.4
Dimensionamiento/Gestión de capacidades
categoría
n.a.
n.a.
aplica
op.pl.5
Componentes certificados




op.acc
Control de acceso
A T
aplica
=
=
op.acc.1
Identificación
I C A T
aplica
=
=
op.acc.2
Requisitos de acceso
I C A T
n.a.
aplica
=
op.acc.3
Segregación de funciones y tareas
I C A T
aplica
=
=
op.acc.4
Proceso de gestión de derechos de acceso
I C A T
aplica
+
++
op.acc.5
Mecanismo de autenticación
I C A T
aplica
+
++
op.acc.6
Acceso local (local logon)
I C A T
aplica
+
=
op.acc.7
Acceso remoto (remote login)




op.exp
Explotación
categoría
aplica
=
=
op.exp.1
Inventario de activos
categoría
aplica
=
=
op.exp.2
Configuración de seguridad
categoría
n.a.
aplica
=
op.exp.3
Gestión de la configuración
categoría
aplica
=
=
op.exp.4
Mantenimiento
categoría
n.a.
aplica
=
op.exp.5
Gestión de cambios
categoría
aplica
=
=
op.exp.6
Protección frente a código dañino
categoría
n.a.
aplica
=
op.exp.7
Gestión de incidentes
T
aplica
+
++
op.exp.8
Registro de la actividad de los usuarios
categoría
n.a.
aplica
=
op.exp.9
Registro de la gestión de incidentes
T
n.a.
n.a.
aplica
op.exp.10
Protección de los registros de actividad
categoría
aplica
+
=
op.exp.11
Protección de claves criptográficas




op.ext
Servicios externos
categoría
n.a.
aplica
=
op.ext.1
Contratación y acuerdos de nivel de servicio
categoría
n.a.
aplica
=
op.ext.2
Gestión diaria
D
n.a.
n.a.
aplica
op.ext.9
Medios alternativos




op.cont
Continuidad del servicio
D
n.a.
aplica
=
op.cont.1
Análisis de impacto
D
n.a.
n.a.
aplica
op.cont.2
Plan de continuidad
D
n.a.
n.a.
aplica
op.cont.3
Pruebas periódicas




op.mon
Monitorización del sistema
categoría
n.a.
aplica
=
op.mon.1
Detección de intrusión
categoría
n.a.
n.a.
aplica
op.mon.2
Sistema de métricas

mp
Medidas de protección




mp.if
Protección de las instalaciones e infraestructuras
categoría
aplica
=
=
mp.if.1
Áreas separadas y con control de acceso
categoría
aplica
=
=
mp.if.2
Identificación de las personas
categoría
aplica
=
=
mp.if.3
Acondicionamiento de los locales
D
aplica
+
=
mp.if.4
Energía eléctrica
D
aplica
=
=
mp.if.5
Protección frente a incendios
D
n.a.
aplica
=
mp.if.6
Protección frente a inundaciones
categoría
aplica
=
=
mp.if.7
Registro de entrada y salida de equipamiento
D
n.a.
n.a.
aplica
mp.if.9
Instalaciones alternativas




mp.per
Gestión del personal
categoría
n.a.
aplica
=
mp.per.1
Caracterización del puesto de trabajo
categoría
aplica
=
=
mp.per.2
Deberes y obligaciones
categoría
aplica
=
=
mp.per.3
Concienciación
categoría
aplica
=
=
mp.per.4
Formación
D
n.a.
n.a.
aplica
mp.per.9
Personal alternativo




mp.eq
Protección de los equipos
categoría
aplica
+
=
mp.eq.1
Puesto de trabajo despejado
A
n.a.
aplica
+
mp.eq.2
Bloqueo de puesto de trabajo
categoría
aplica
=
+
mp.eq.3
Protección de equipos portátiles
D
n.a.
aplica
=
mp.eq.9
Medios alternativos




mp.com
Protección de las comunicaciones
categoría
aplica
=
+
mp.com.1
Perímetro seguro
C
n.a.
aplica
+
mp.com.2
Protección de la confidencialidad
I A
aplica
+
++
mp.com.3
Protección de la autenticidad y de la integridad
categoría
n.a.
n.a.
aplica
mp.com.4
Segregación de redes
D
n.a.
n.a.
aplica
mp.com.9
Medios alternativos




mp.si
Protección de los soportes de información
C
aplica
=
=
mp.si.1
Etiquetado
I C
n.a.
aplica
+
mp.si.2
Criptografía
categoría
aplica
=
=
mp.si.3
Custodia
categoría
aplica
=
=
mp.si.4
Transporte
C
aplica
+
=
mp.si.5
Borrado y destrucción




mp.sw
Protección de las aplicaciones informáticas
categoría
n.a.
aplica
=
mp.sw.1
Desarrollo
categoría
aplica
+
++
mp.sw.2
Aceptación y puesta en servicio




mp.info
Protección de la información
categoría
aplica
=
=
mp.info.1
Datos de carácter personal
C
aplica
+
=
mp.info.2
Calificación de la información
C
n.a.
n.a.
aplica
mp.info.3
Cifrado
I A
aplica
+
++
mp.info.4
Firma electrónica
T
n.a.
n.a.
aplica
mp.info.5
Sellos de tiempo
C
aplica
=
=
mp.info.6
Limpieza de documentos
D
aplica
=
=
mp.info.9
Copias de seguridad (backup)




mp.s
Protección de los servicios
categoría
aplica
=
=
mp.s.1
Protección del correo electrónico
categoría
aplica
=
+
mp.s.2
Protección de servicios y aplicaciones web
D
n.a.
aplica
+
mp.s.8
Protección frente a la denegación de servicio
D
n.a.
n.a.
aplica
mp.s.9
Medios alternativos»



ANEXO III. Algunas fotografías del evento en relación a esta ponencia

  


Fotografía 1. Iniciando la ponencia sobre cómo integrar el RGPD con un SGSI-ENS.





Fotografía 2. Recibiendo un recuerdo del evento de manos de Joan Barceló, presidente del Capítulo de Barcelona de ISACA.





Fotografía 3. Firmando una dedicatoria en el libro de visitas de la asociación, a la que agradezco haberme invitado a participar.



Fotografía 4. Vista panorámica de los asistentes al evento, a quienes agradezco su participación.