Cumplimiento GDPR: Modelos de Compliance

Publicado el 17-05-2018      Notícia sobre:

 

Mucho se ha escrito, mucho se ha oído y mucho se ha podido ver, incluyéndose a las respectivas autoridades de control comentar respecto a cómo debería ser la adecuación y/o implementación del nuevo marco regulador de protección de datos. Este artículo no pretende ir más allá de mostrar mi humilde opinión jurídica en cuanto a lo que considero una correcta aplicación del GDPR, la cual la supedito a la integración o realización de los denominados modelos de compliance y, más concretamente, a la posibilidad de integrar el modelo COSO e ISO 19600 que no son más que modelos de control y gestión del riesgo, pudiendo partir, si se dispusiere, del Modelo de Prevención de Delitos Penales a los que hace referencia el artículo 31 bis del Código Penal.

Bajo mi interpretación del GDPR, el cual es configurado de forma transversal, y centrándome en la responsabilidad proactiva, dado que en virtud de la configuración enunciada, los responsables de tratamiento deberán prima facie (sustantivo) asegurar la correcta aplicación de los principios recogidos en el artículo 5 y desarrollados mediante los requisitos y obligaciones contenidos en los artículos 6  a 23, dando primacía al principio de transparencia, información, consentimiento y derecho de los afectados (garantizar el derecho de autodeterminación informativa). Sin embargo, dicho derecho sustantivo (hardlaw) es completado, dentro del principio de responsabilidad proactiva (Capítulo IV, especialmente, artículos 24 a 39) mediante normativa softlaw y, considero que dicho cumplimiento está configurado bajo los modelos de compliance.

La anterior afirmación la emito porque de una lectura exhaustiva del artículo 24 GDPR se desprende que dicha responsabilidad está basada en el principio de COMPLAIN & EXPLAIN: CUMPLE Y EXPLICA, base de todo programa de cumplimiento normativo. Dicho artículo hace mención expresa a términos como: riesgo, controles, políticas, etc. Por tanto y, en virtud, de la configuración transversal, el GDPR obliga con carácter general a establecer un modelo de compliance, el cual es desarrollado más pormenorizadamente, a través de los siguientes artículos, en los cuales se establecen especialidades en virtud del tipo de tratamiento de datos personales. Por ello, las obligaciones formales y/o documentales, tales como el Registro de Actividades de Tratamiento, no es el eje principal de una correcta aplicación y garantiza el cumplimiento, dado que dicho RAT no es más que lo que expresamente establece el propio GDPR (documento interno formal), pero no el requisito determinante para demostrar y garantizar el cumplimiento afecto, tal y como últimamente estoy cansado de escuchar a múltiples “consultoras.”

Comentado el precedente, qué pretende el GDPR con la responsabilidad proactiva. Dado que los estados ya no pueden garantizar el cumplimiento, no sólo en materia de protección de datos sino en otros ámbitos del derecho a través del referido hardlaw pretenden servirse de los distintos actores (empresas, administraciones públicas, servicios, etc.), por así decirlo, para controlar el cumplimiento, dándoles libertad para establecer un modelo o un proceso de cumplimiento (softlaw, el cual es aceptado por la sociedad), en este caso, relacionado con la privacidad, tomando como referencia cultura anglosajona (USA[1], Reino Unido[2]) pero también cultura europea (Alemania[3]) respecto a los denominados cumplimientos normativos. Dicho softlaw, principalmente y actualmente, toma como referencia marcos o normas estandarizadas reconocidos internacionalmente[4]. Entre dichos marcos y normas se encuentra el denominado marco COSO e ISO 19600 que, principalmente, recoge un proceso interno de gestión del riesgo y cómo contralar el mismo.

Si efectuamos una extrapolación de la finalidad del GDPR en cuanto a garantizar y acreditar la responsabilidad en referencia al modelo COSO e ISO 19600, las similitudes son extraordinarias. El GDPR, al igual que el modelo COSO (Coso I y III determinada el modelo, mientras que COSO II indica cómo gestionar el riesgo) el cual es tomado como base en ISO 196000 de la misma forma que en otro tipo de ISO (calidad, medio ambiente, prevención de riesgos, etc.), base su eficacia en los referidos modelos de cumplimiento. Analicemos el GDPR en base a dicho modelo de gestión del riesgo: El GDPR expresamente hace mención a las tres líneas de defensa de los modelos de compliance: Medición del riesgo (mapa) y establecimiento de políticas y controles a los riesgos; establecimiento y seguimiento de los controles; monitorización y/o supervisión del modelo de cumplimiento. Las tres líneas deben ser justificadas y documentadas, tanto en el supuesto de tratamientos que no precisen EIDP como aquellos tratamientos que precisen de EIDP por el carácter de alto riesgo en dicho tratamientos.

Ahora bien, como se pone lo comentado en tierra, a nivel práctico, es decir, dicha libertad basada en un modelo de compliance, cómo es operativo. Un modelo de cumplimiento GDPR se basa en tres pilares: diseño, implementación y eficacia operativa y, dicho modelo no se efectúa de la noche a la mañana y más, lamentándolo mucho, según está configurado el propio GDPR puesto que el mismo obliga a analizar el riesgo en virtud de operaciones, es decir, en virtud de la vida del dato (recogida, tipo de fuente de procedencia, operaciones internas, comunicaciones y/o transferencias, bloqueos, conservación, etc.) Relaciono el presente con las famosas EIDP, dado que pudiere suceder que en el análisis del riesgo la recogida no alcanzara un riesgo alto, pero la operación de comunicación a terceros sí y, en ese caso, sería necesario dicha EIPD.

Centrándonos en el GDPR y como base inicial, es obligatorio efectuar lo que se denomina mapeo de riesgos. Existen varias fórmulas, pero centraré el mismo, en dos extremos: riesgo en base a la actividad y el riesgo en base a los procesos. De dicho extremos, bajo mi impresión, es más fácil efectuar y/o medir el riesgo en base a la actividad, por lo tanto, en base a ella y a su afectación al responsable del tratamiento, habrá que determinar qué riesgos asociados a la actividad pudieren ser afectos en cuanto a la privacidad (tratamientos), dado que no es lo mismo una actividad de un centro sanitario que la actividad de una PYME más allá del servicio que presta, pero habrá que atender a las finalidades que se efectúan, puesto que pudiere suceder que se efectúe en una PYME profiling o análisis de perfiles que impliquen un aumento del riesgo y, por ende, un mayor seguimiento respecto a los controles a establecer.

Una vez efectuado el mapeo de riesgo y la matriz obtenida de dos coordenadas (riesgo y probabilidad), recomendando establecer o documentar el proceso a implementar, es decir, la denominada política de protección de datos; habrá que establecer los controles precisos a dichos riesgos, los cuales deberían, igualmente, establecer o contener los riesgos a las medidas técnicas y organizativas que se disponen (p.e. si disponemos de un riesgo asociado al acceso al sistema de información por falta de establecimiento de temporalidad de modificación de contraseñas, un control a establecer sería recordar o establecer la temporalidad; otro control es la revisión, cada cierto tiempo, respecto a la incorporación o testeo de las distintas cláusulas afectas o relacionar los encargados de tratamiento). Este segundo paso es la segunda línea de defensa, respecto a la cual ha de documentarse, por así decirlo, obtener la evidencia a dicho seguimiento y actuación. La tercera línea de defensa sería la verificación y/o supervisión, la cual, tal y como indica el propio GPDR la asumiría el DPO en caso que fuere preciso o la persona respecto a la cual el responsable del tratamiento haya designado. En este punto concreto, se ha de resaltar, como así se establece en los programas de compliance, que el mismo debe ser objeto principal de la dirección de la empresa, es decir, en el primer nivel y, ese nivel, sería por ejemplo el Consejo de Administración, al cual se habrá de reportar en relación al ámbito de privacidad y, sobre el cual, recaerá la asunción del nombramiento del respectivo DPO, puesto que el mismo, al igual que en otros ámbitos (PBCFT; Delitos Penales), aquel se sitúa, tal y como el propio GDPR establece en su artículo 38.3, en lo más alto jerárquicamente y bajo el principio de independencia y, dichos extremos deben ser garantizados: “El responsable y el encargado del tratamiento garantizarán que el delegado de protección de datos no reciba ninguna instrucción en lo que respecta al desempeño de dichas funciones. El delegado de protección de datos rendirá cuentas directamente al más alto nivel jerárquico del responsable o encargado.” Dicho DPO será el encargado de supervisar la Eficacia Operativa del modelo diseñado e implementado y el encargado de reportar a la alta dirección los informes relacionados, a través de las evidencias y documentos obtenidos a lo largo del tiempo.

La pregunta sería, se puede establecer dicho modelo de compliance con las herramientas y/o publicaciones que las autoridades de control han publicado. No tengo respuesta para ello, puesto que, si bien es cierto que tanto las guías sobre medición de riesgo y EIDP pudieren servir de base para establecer la primera línea de defensa, por el contrario, todo modelo de compliance ha de estar VIVO y, por ello, al contrario que sucedía con la LOPD (se efectuaba documento de seguridad y se quedaba en el cajón cogiendo polvo), ahora por el contrario, dicho modelo diseñado e implementado debe estar actualizado, puesto que será la defensa principal (atenuante o eximente) en caso de procedimientos sancionadores u otros análogos, más aún si lo extrapolamos con los principios rectores del ámbito penal y del artículo 31 bis referenciado al inicio del presente artículo, el cual indica que dicho programa debe estar VIVO, habiendo indicado la propia FISCALIA que disponer de certificación de ISO 19601 no es elemento atenuante sino que debe demostrarse que dicho modelo ha sido implantado eficazmente, de la misma forma que el GDPR se expresa al hablar de diligencia, supervisión y verificación. Por ello, mi primera reflexión acerca de que el modelo de cumplimiento del GDPR pudiere formar parte integrada del modelo de prevención de delitos penales, ampliando su alcance al establecimiento de controles y políticas asociadas a los delitos relacionados con la privacidad.

Terminando con el presente artículo, el cual precisaría de una mayor extensión, aunque la finalidad del mismo ha sido “intentar mostrar un poco de luz”, si bien habrá que dejar caminar al GDPR, sí me gustaría indicar dos cosas: primera, poco a poco se está produciendo una cambio cultural al respecto del presente ámbito, el cual ya empieza a tener su punto de partida tanto en la Ley de Contratos del Sector Público como en las relaciones con otras empresas e inversores, destacando la obligatoriedad y/o exigencia de acreditar o valorar el riesgo asociado a una actividad empresarial concreta; y segunda, para poder interpretar, entender y, especialmente, implementar el GDPR es necesario conocer y desenvolverse con procesos de cumplimiento basados en el riesgo y en la supervisión de los controles asociados a los mismos, por lo que, bajo mi apreciación, simplemente realizar un análisis a través, por ejemplo, de la herramienta FACILITA, descarga del RAT y check-list de verificación, no sería suficiente, porque como he comentado, el modelo de responsabilidad del GDPR ha de estar VIVO y las precedentes acciones son meras formalidades, amén de otros extremos afectos que no forman parte del presente artículo. Este artículo no es más que una simple opinión basada en la experiencia y en la interpretación del GDPR, pudiendo no ser compartida por otros actores o lectores.

       Efrén Santos Pascual

       Socio – Abogado TIC

       ICEF Consultores

       www.icefconsultores.com

      @efrensantos_tic                                                                                    

                                                                                    

[1] FCPA. Foreign Corrupt Practices Act

[2] Bribery Act

[3] IDWAssS 980

[4] BS 10012:2017: ISO 31000:2009; Directrices OCDE.