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.

Anteproyecto LOPD

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

La dovela central del RGPD

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

Guía EIPD

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

Mapping GDPR & ISO27001

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

Guía CCN-STIC-825

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

Cumplimiento legal y Riesgo

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