Ya han pasado casi dos años desde que se ha promulgado el Reglamento General de Protección de Datos (RGPD) de la Unión Europea. Desde entonces, mucho se ha escrito sobre la regulación. De hecho, una búsqueda rápida en Google genera unos 486.000.000 resultados.1 Dado el tiempo transcurrido desde su entrada en vigor, el RGPD debiera ser ya habitual. Sin duda, los auditores TI debieran considerar la regulación para todas aquellas auditorías donde se tratan datos personales.2 Entonces, ¿qué aspectos de la regulación deben considerarse cuando se auditan los controles generales de TI de una aplicación?
El RGPD comprende 99 artículos; sin embargo, muchos de estos definen las reglas generales para la regulación. Estas han sido bien documentadas en dos programas de auditoría publicados por ISACA®.3, 4 Aquí el foco se pone en los artículos del RGPD que creo que son aplicables transversalmente a cualquier auditoría con foco en aplicaciones de TI donde se tratan datos personales.
Artículo 30: registros de las actividades de tratamientos
El Artículo 30 requiere que cada responsable del tratamiento y, donde sea aplicable, el representante de cada responsable del tratamiento mantenga un registro de las actividades de tratamiento bajo su responsabilidad.5 El punto de partida de la auditoría debiera ser la solicitud de una copia de estos registros, ya que permiten entender los propósitos del tratamiento, ofreciendo una descripción de las categorías tanto de los sujetos de los datos y de los datos personales y cerciorarse de que estén involucrados terceros o, de hecho, terceros países. Donde no esté implantado y se entienda que se traten datos personales, esto debiera constituir un hallazgo de auditoría. Un ejemplo del artículo 30 se incluye en el paquete del Programa de auditoría RGPD de ISACA.6
Artículo 6: licitud del tratamiento
Para que el tratamiento sea lícito, los datos personales debieran ser tratados a partir del consentimiento del interesado involucrado, o sobre otra base legítima.7 Desde una perspectiva de auditoría, uno debiera confirmar que este consentimiento ha sido capturado, ya que el responsable del tratamiento debiera ser capaz de demostrar que el interesado ha consentido al tratamiento de sus datos personales.8 Para una aplicación en particular, este consentimiento puede ser almacenado en la base de datos para cada interesado. Si es así, debiera ser revisado. Otras bases legales existen y una prueba incluida en el Paquete de auditoría RGPD de ISACA requiere que las mismas estén documentadas en los Registros de actividades de tratamiento (Artículo 30).9
Una de dichas bases legales la constituyen los intereses legítimos, lo que se refiere a los intereses de la empresa que está siendo revisada o los intereses de terceras partes. Esto puede incluir intereses comerciales, intereses individuales o beneficios sociales más amplios.10 Los intereses legítimos difieren de otras bases legales, ya que no están centradas en un propósito particular y no están tratando lo que el individuo ha acordado específicamente (consentimiento). Los intereses legítimos son más flexibles y podrían, en principio, aplicar a cualquier tipo de tratamiento para cualquier propósito razonable.11 Por este motivo, es importante confirmar que ha sido realizada una evaluación de propósitos legítimos y que un registro de esta se ha guardado para justificar la decisión de la empresa.12 Una vez más, esto podría almacenarse con los Registros de Actividades de Tratamiento (Artículo 30).13
Artículo 9: tratamiento de categorías especiales de datos personales
El Artículo 9 del RGPD establece que se prohibirá el tratamiento de datos personales que revele el origen étnico o racial, las opiniones políticas, las creencias religiosas o filosóficas o afiliación sindical, y el tratamiento de datos genéticos, datos biométricos dirigidos a identificar de manera unívoca a una persona física, datos sobre la salud o sobre la vida sexual de una persona o su orientación sexual.14 Incluye ciertas excepciones como el consentimiento explícito.
Desde una perspectiva de auditoria, es vital confirmar que este consentimiento explícito se captura, quizás en el nivel de interesado en la base de datos de la aplicación y que, una vez más, los propósitos han sido documentados. De nuevo, se dispone de un ejemplo en el Paquete de auditoria RGPD de ISACA.15 Para los artículos 6 y 9, es posible que un ejercicio de clasificación de datos16 sea realizado. Esto debiera ser revisado.
Artículo 15: derecho de acceso del interesado
De acuerdo con el Artículo 15, el interesado tendrá el derecho de obtener del responsable del tratamiento la confirmación acerca de si están siendo tratados o no datos personales que le conciernen y, si ese fuera el caso, el acceso a los datos personales.17 Además, mucha de la información capturada bajo los términos del Artículo 30 debiera hacerse disponible para el interesado. El Artículo 12 establece que la información será provista por escrito o por otros medios incluyendo, cuando sea apropiado, por medios electrónicos.18 Esto ha sido interpretado como que, en aquellos casos en que la solicitud sea hecha por medios electrónicos, la información debiera ser proporcionada en un formato electrónico de uso común. De hecho, cuando sea posible, el responsable del tratamiento debiera proporcionar acceso remoto a un sistema seguro que proporcione al interesado un acceso directo a sus datos personales.19
Por consiguiente, desde una perspectiva de auditoría, es importante asegurar que hay un mecanismo definido para proporcionar este acceso o para extraer de manera electrónica todos los datos personales que la aplicación almacena. Esto puede materializarse como simples impresiones de pantalla; sin embargo, debiera existir un proceso definido y demostrable.
Artículo 16: derecho de rectificación
El Artículo 16 del RGPD establece que el interesado tendrá el derecho de obtener del responsable del tratamiento sin dilación indebida la rectificación de datos personales incorrectos sobre él o ella.20 Como la mayoría de las aplicaciones, por su propia naturaleza, permiten la rectificación de datos, este debiera ser un derecho relativamente sencillo de cumplir. Sin embargo, el auditor TI debiera asegurar que existe un proceso que permita la rectificación de los datos en la aplicación que está siendo revisada.
Artículo 17: derecho de supresión (“el derecho al olvido”)
De acuerdo con el Artículo 17, el interesado tendrá el derecho de obtener del responsable del tratamiento la supresión de datos de carácter personal sobre el o ella sin dilación indebida y el responsable del tratamiento tendrá la obligación de suprimir los datos personales sin dilación indebida.21 Sin embargo, este no es un derecho absoluto y el artículo detalla reglas específicas acerca de cuándo es aplicable, incluyendo excepciones.
Si se recibe una solicitud de supresión válida, se debieran tomar pasos para asegurar la supresión tanto de los sistemas productivos como de los sistemas de respaldo. Se debe aclarar al individuo qué sucederá a sus datos cuando se cumplimente la solicitud de supresión, incluyendo en lo concerniente a las copias de respaldo. Puede suceder que la solicitud de supresión pueda ser satisfecha instantáneamente respecto de los sistemas productivos, pero que los datos permanezcan en el entorno de respaldo por un cierto tiempo hasta que sean sobrescritos.22
Los auditores debieran confirmar que existe un mecanismo para borrar los datos y que se conocen y están documentados los procesos respecto de las copias de respaldo, de forma tal que se pueda informar al interesado.
Artículo 18: derecho a la limitación del tratamiento
El artículo 18 del RGPD establece que el interesado tendrá el derecho de obtener del responsable del tratamiento la limitación del tratamiento bajo ciertas circunstancias23 De nuevo, este no es un derecho absoluto. Lo importante, desde una perspectiva de auditoría de TI, es considerar ¿cómo se limitaría el tratamiento en la aplicación que está siendo revisada? ¿Existe un mecanismo que lo permita?
Artículo 20: derecho a la portabilidad de los datos
El Artículo 20 del RGPD dice que el interesado tendrá el derecho de recibir los datos personales que le conciernan, que él o ella hayan proporcionado a un responsable del tratamiento, en un formato estructurado, de uso común y lectura mecánica, y que tendrá el derecho de transmitir dichos datos a otro responsable del tratamiento sin ningún obstáculo por parte del responsable del tratamiento al que se hayan provistos los datos personales.24 Además, cuando sea técnicamente factible, el interesado tendrá el derecho de que los datos personales sean transmitidos directamente de un responsable del tratamiento al otro.25
Desde una perspectiva de auditoría TI, es importante asegurar de que cualquier dato de carácter personal puede o pudiera ser exportado desde la aplicación. Cuando existan grupos de la industria (p. ej., en banca) pude ser importante demostrar que está preparado para desarrollar un formato interoperable.26
Artículo 25: protección de datos desde el diseño y por defecto
De acuerdo con el Artículo 25, el responsable del tratamiento implementará, tanto en el momento de la determinación de los medios para el tratamiento como en el momento del propio tratamiento, medidas técnica y organizacionales apropiadas, como la seudonimización, diseñadas para implementar principios de protección de datos tales como la minimización de datos de manera efectiva, e integrar las salvaguardas necesarias en el tratamiento para alcanzar los requerimientos de la regulación y proteger los derechos de los sujetos de datos.27
Los auditores debieran confirmar que los principios de Privacidad desde el Diseño28 fueron considerados y documentados para cualquier cambio o desarrollo significativo de la aplicación que está siendo revisada.
El término “seudonimización” requiere una clarificación. Seudonimización de datos significa que se reemplazan cualesquiera características identificadoras de los datos con un seudónimo o, en otras palabras, con un valor que no permita la identificación directa del interesado.29 RGPD define a la seudonimización como el tratamiento de datos personales de forma tal que los datos personales no puedan ser atribuidos a un interesado específico sin utilizar información adicional, siempre y cuando a) dicha información adicional se mantenga separada y b) sea sujeta a medidas técnicas y organizacionales que aseguren que los datos personales no sean atribuidos a un individuo identificado o identificable.
Artículo 32: seguridad del tratamiento
El Artículo 32 requiere que el responsable del tratamiento y el encargado del tratamiento implementen medidas técnicas y organizacionales apropiadas para asegurar un nivel de seguridad apropiado al riesgo, incluyendo inter alia según sea apropiado:30
- La seudonimización y cifrado de datos personales
- La capacidad de asegurar la confidencialidad, integridad, disponibilidad y resiliencia continuada de los sistemas y servicios de tratamiento.
- La capacidad de recuperar la disponibilidad de y el acceso a datos personales de manera oportuna en el evento de una incidencia física o técnica.
- Un proceso para, de manera regular, probar, ponderar y evaluar la efectividad de las medidas técnicas y organizacionales para asegurar la seguridad del tratamiento.
Este es un terreno más familiar para los auditores TI, y pueden usarse para demostrar el cumplimiento los controles documentados en, por ejemplo, el estándar de Gestión de la Seguridad de la Información ISO 27001 de la Organización Internacional de Normalización y/o la Publicación Especial (SP) 800-53 Controles de Seguridad y Privacidad para Sistemas de Información y Organizaciones Federales del Instituto Nacional de Estándares y Tecnología (NIST) de los EE. UU. También se proporciona una buena orientación en el Paquete de auditoría RGPD.31
Artículo 35: evaluación de impacto relativa a la protección de datos
El Artículo 35 del RGPD requiere que donde un tipo de tratamiento, en particular usando nuevas tecnologías, y teniendo en cuenta la naturaleza, alcance, contexto y propósitos del tratamiento, es posible que resulta en un riesgo alto que afecte a los derechos y libertades de las personas naturales, el responsable del tratamiento deberá, antes del tratamiento, realizar una evaluación del impacto de las operaciones de tratamiento previstas en la protección de los datos personales.32
Fundamentalmente, se trata de una evaluación de riesgos, pero debe ser dirigida desde la perspectiva de los sujetos de datos. El RGPD no define “posible que resulte en riesgo alto”. Sin embargo, el punto importante aquí no es si el tratamiento realmente es de riesgo alto o posible que resulte en daño – este es el trabajo de evaluación en detalle de la Evaluación de Impacto en la Protección de Datos (EIPD). En cambio, la pregunta tiene que ver con una prueba de cribado de más alto nivel o un análisis de umbral: ¿Hay características que apunten a un potencial riesgo alto?33
Desde una perspectiva de auditoría TI, cuando se han hecho cambios importantes a la aplicación que se está revisando es importante confirmar que se ha realizado y documentado un análisis de umbral y/o una EIPD.
DESDE UNA PERSPECTIVA DE AUDITORÍA TI, CUANDO SE HAN HECHO CAMBIOS IMPORTANTES A LA APLICACIÓN QUE SE ESTÁ REVISANDO ES IMPORTANTE CONFIRMAR QUE SE HA REALIZADO Y DOCUMENTADO UN ANÁLISIS DE UMBRAL Y/O UNA EIPD.
Conclusión
A pesar de algunos comentarios en tal sentido, RGPD ni era ni es un proyecto tipo Y2K. Además de la necesidad de conformidad continua con RGPD,34 a nivel de negocio y operacional, la regulación ha generado diversos requisitos a ser considerados cuando se audita cualquier aplicación donde se tratan datos personales35 Estos requisitos debieran ser hoy en día habituales para todos los auditores de TI que dirigen este tipo de revisiones.
Notas finales
1 Accedido el 9 de octubre de 2019
2 Esto depende también del alcance territorial. Ver Comité Europeo de Protección de Datos, Guidelines 3/2018 sobre Territorial Scope of the GDPR (Artículo 3), Versión 2.0, 12 de noviembre de 2019
https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_3_2018_territorial_scope_after_public_consultation_en.pdf
3 ISACA, GDPR Audit Program Bundle, EE.UU.,
2018, https://www.isaca.org/bookstore/COBIT-5/WAGDPR
4 ISACA, GDPR Audit Program for Small and
Medium Enterprises, EE.UU., 2019,
https://www.isaca.org/bookstore/COBIT-5/WAUGDPR
5 Intersoft Consulting, Art. 30 GDPR, Right of
Access by the Data Subject, EU General Data
Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-30-gdpr/
6 Op cit, GDPR Audit Program Bundle
7 Intersoft Consulting, Recital 40 Lawfulness of
Data Processing, EU General Data Protection
Regulation, Bélgica, 2017, https://gdpr-info.eu/recitals/no-40/
8 Intersoft Consulting, Art. 7 GDPR, Conditions
for Consent, EU General Data Protection
Regulation, Bélgica, 2017, https://gdpr-info.eu/art-7-gdpr/
9 Op cit Art. 30 GDPR
10 Information Commissioner’s Office, Legitimate Interests, Reino Unido, https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/legitimate-interests/
11 Information Commissioner’s Office, What Is the
“Legitimate Interests” Basis? Reino Unido,
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/legitimate-interests/what-is-the-legitimate-interests-basis/
12 Op cit Legitimate Interests
13 Op cit Art. 30 GDPR
14 Intersoft Consulting, Art. 9 GDPR, Processing of
Special Categories of Personal Data, EU
General Data Protection Regulation, Bélgica,
2017, https://gdpr-info.eu/art-9-gdpr/
15 Op cit GDPR Audit Program Bundle
16 Cooke, I.; “Doing More With Less,” ISACA
Journal, vol. 5, 2017, https://www.isaca.org/archives
17 Intersoft Consulting, Art. 15 GDPR, Right of
Access by the Data Subject, EU General Data
Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-15-gdpr/
18 Intersoft Consulting, Art. 12 GDPR, Transparent
Information, Communication and Modalities for
the Exercise of the Rights of the Data Subject,
EU General Data Protection Regulation,
Bélgica, 2017, https://gdpr-info.eu/art-12-gdpr/
19 Intersoft Consulting, Recital 63, Right of Access,
EU General Data Protection Regulation, Bélgica,
2017, https://gdpr-info.eu/recitals/no-63
20 Intersoft Consulting, Art. 16 GDPR, Right to
Rectification, EU General Data Protection
Regulation, Bélgica, 2017, https://gdpr-info.eu/art-16-gdpr/
21 Intersoft Consulting, Art. 17 GDPR, Right to
Erasure (“Right to be Forgotten”), EU General
Data Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-17-gdpr/
22 Information Commissioner’s Office, Right to
Erasure, Reino Unido, https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/
23 Intersoft Consulting, Art. 18 GDPR, Right to
Restriction of Processing, EU General Data
Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-18-gdpr
24 Intersoft Consulting, Art. 20 GDPR, Article 20,
Right to Data Portability, EU General Data
Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-20-gdpr/
25 Intersoft Consulting, Recital 68, Right of
Data Portability, EU General Data
Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/recitals/no-68/
26 Ibid.
27 Intersoft Consulting, Art. 25 GDPR, Data
Protection by Design and by Default, EU General
Data Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-25-gdpr/
28 Agencia Española de Protección de Datos, Guía de Privacidad desde el Diseño, España, 2019,
https://www.aepd.es/sites/default/files/2019-12/guia-privacidad-desde-diseno_en.pdf
29 Data Protection Commission, Guidance Note:
Guidance on Anonymisation and
Pseudonymisation, Irlanda, junio de 2019, https://www.dataprotection.ie/sites/default/files/uploads/2019-06/190614%20Anonymisation%20and%20Pseudonymisation.pdf
30 Intersoft Consulting, Art. 32 GDPR, Security of
Processing, EU General Data Protection
Regulation, Bélgica, 2017, https://gdpr-info.eu/art-32-gdpr/
31 Op cit GDPR Audit Program Bundle
32 Intersoft Consulting, Art. 35 GDPR, Data
Protection Impact Assessment, EU General
Data Protection Regulation, Bélgica, 2017,
https://gdpr-info.eu/art-35-gdpr/
33 Information Commissioner’s Office, When Do
We Need to Do a DPIA?, Reino Unido,
https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/
34 Cooke, I.; “Assurance Considerations for
Ongoing GDPR Conformance,” ISACA Journal,
vol. 1, 2019, https://www.isaca.org/ archives
35 Op cit Guidelines 3/2018 on the Territorial
Scope of the GDPR
Ian Cooke, CISA, CRISC, CGEIT, COBIT 5 Assessor and
Implementer, CFE, CIPM, CIPP/E, CIPT, FIP, CPTE, DipFM, ITIL
Foundation, Six Sigma Green Belt
Es el director corporativo de auditoria TI en An Post (el Correo irlandés con
sede en Dublín, Irlanda) y tiene más de 30 años de experiencia en todos los
aspectos de los sistemas de información. Cooke ha sido miembro de varios
comités de ISACA®, fue líder temático para las discusiones de Auditoría y
Garantía en los Foros Online de ISACA y es miembro del Grupo de Trabajo de
ISACA para el Desarrollo de Ítems de Examen de CGEIT®. Cooke ha apoyado la
actualización del Manual de Preparación para el Examen CISA® y ha sido
experto de área temática para el desarrollo de los Cursos en línea de
preparación para los exámenes CISA® y CRISC™ de ISACA. Ha recibido el
Premio del Cuerpo de Conocimiento Común John W. Lainhart IV en 2017 por
sus contribuciones al desarrollo y mejora de las publicaciones y módulos de
formación de ISACA y el Premio a Mejor Libro/Autor Michael Cangemi en
2020. Agradece comentarios o sugerencias para artículos vía correo
electrónico (Ian_J_Cooke@hotmail.com), Twitter (@COOKEI), LinkedIn
(www.linkedin.com/in/ian-cooke-80700510/), o en el Foro Online de Auditoría y
Garantía (engage.isaca.org/home). Las opiniones formuladas son propias y no
representan necesariamente los puntos de vista de An Post.