BRECHA 005 – Ataque mediante SQL injection

En esta quinta entrega de GDPR Brechas analizamos una resolución de la AEPD relativa a un ciberataque mediante SQL injection para obtener las credenciales de acceso a un sitio web dedicado a la cocina. Mediante este ataque consiguieron acceso al servidor. Este sitio web tenía 137.725 usuarios, cuyos datos quedaron comprometidos en el ciberataque.

Puedes ver el vídeo completo de esta brecha y descargar el PDF con la ficha del caso analizado, así como participar en el debate con tu opinión sobre el incidente, las medidas aplicadas por la empresa y el contenido de la resolución en: https://www.campus-ribas.com/p/brechas-de-seguridad

GDPR Brechas es un espacio para el análisis de las brechas de seguridad que han sido objeto de resolución por las autoridades de control. 

ACCESO AL PROYECTO GDPR BRECHAS

Te invito a participar en el proyecto accediendo a la sección GDPR Brechas en Campus Ribas:

https://www.campus-ribas.com/p/brechas-de-seguridad

En dicha sección podrás ver los vídeos explicativos del proyecto y de cada uno de los casos que se vayan publicando.

También podrás descargar la ficha de cada caso en formato PDF.

En el apartado de comentarios podrás manifestar tu opinión sobre cada caso y sobre cada resolución.

Brexit y RGPD: periodo transitorio hasta 2021

La autoridad de control inglesa (ICO) ha elaborado un documento informativo sobre Brexit y GDPR y una página web en la que publica sus guías y recomendaciones para el caso de un Brexit sin acuerdo: https://ico.org.uk/no-deal.

El acuerdo alcanzado entre la Unión Europea y el Reino Unido establece un período transitorio que finalizará el 31 de diciembre de 2020. Durante este periodo el RGPD seguirá siendo de aplicación en el Reino Unido.

Una vez finalizado el periodo transitorio, todo dependerá del resultado de las negociaciones.

En el caso de que no se llegue a un acuerdo, el RGPD se incorporará a la legislación del Reino Unido como “UK GDPR”, pero puede haber desarrollos adicionales en temas específicos como las transferencias de datos.

Durante 2020 no habrá restricciones en el flujo de datos en ambas direcciones, pero si no hay acuerdo, las transferencias de datos de la Unión Europea al Reino Unido deberán contar con las garantías adecuadas, entre las que destacan las cláusulas tipo y las normas corporativas vinculantes.

Si hay acuerdo, probablemente habrá una decisión de adecuación de la Comisión Europea que permitirá realizar transferencias de datos al Reino Unido sin restricciones.

La autoridad de control inglesa sostiene que, en la práctica, el UK GDPR implicará pocos cambios en los principios básicos, derechos y obligaciones de protección de datos previstos en el RGPD.

En una reciente declaración sobre el Brexit, Boris Johnson afirma que: “The UK will in future develop separate and independent policies in areas such as (but not limited to) the points-based immigration system, competition and subsidy policy, the environment, social policy, procurement, and data protection, maintaining high standards as we do so.”

Invitación a participar en el proyecto GDPR Brechas

Origen del proyecto

El análisis de las resoluciones de las autoridades de control relativas a violaciones de la seguridad de los datos se inició en mayo de 2019, al cumplirse el primer año de aplicación efectiva del RGPD. La presentación de las primeras conclusiones del estudio tuvo lugar en un webinar sobre brechas de seguridad que organizó Thomson Reuters en 24 de octubre de 2019.

Objetivos del proyecto

Los objetivos del análisis de las resoluciones son los siguientes:

  1. Identificar las principales causas de las brechas notificadas.
  2. Identificar el origen más habitual: autores o responsables.
  3. Valorar la implicación de los proveedores o encargados del tratamiento.
  4. Identificar las medidas previas al incidente que la autoridad de control ha valorado.
  5. Identificar las medidas posteriores al incidente que la autoridad de control ha valorado.
  6. Identificar los argumentos utilizados para fundamentar el archivo o la sanción.
  7. Aprovechar el conocimiento obtenido para la prevención de futuras brechas.
  8. Ir más allá de una auditoría de seguridad basada en un modelo teórico.
  9. Reducir los efectos de una brecha en el caso de no poder evitarla.
  10. Generar pruebas que permitan acreditar la diligencia de la empresa.
  11. Evitar sanciones e indemnizaciones de daños y perjuicios a los afectados.

Referencias a los casos analizados

Las referencias a los casos analizados se limitan al número de expediente, con el fin de evitar cualquier mención a la empresa que ha tenido el incidente de seguridad.

Las valoraciones y los comentarios constituyen únicamente un análisis jurídico y técnico.

No se valora la gestión de la empresa ni de sus responsables.

ACCESO AL PROYECTO GDPR BRECHAS

Puedes participar en el proyecto accediendo a la sección GDPR Brechas en Campus Ribas:

https://www.campus-ribas.com/p/brechas-de-seguridad

En dicha sección podrás ver los vídeos explicativos del proyecto y de cada uno de los casos que se vayan publicando.

También podrás descargar la ficha de cada caso en formato PDF.

En el apartado de comentarios podrás manifestar tu opinión sobre cada caso y sobre cada resolución.

GDPR Hack 02 – Periodicidad de las auditorías GDPR

  PLANTEAMIENTOS Planteamiento 1 – Proyecto inicial incompleto
  1. La mayor parte de los proyectos de adecuación al RGPD se planificaron para acabar el 25 de mayo de 2018.
  2. La prioridad de cumplir el plazo hizo que algunos proyectos no profundizasen en algunos puntos críticos.
  3. La idea era completar el proyecto posteriormente, pero muchas empresas no lo han hecho.
Planteamiento 2 – Información inicial escasa
  1. Una parte de las guías de las autoridades de control se publicaron tras la finalización del proyecto.
  2. El nivel de detalle y concreción del RGPD es escaso en algunos puntos.
  3. Las empresas no dispusieron durante el proyecto de tanta información como la existente en la actualidad.
Planteamiento 3 – Cultura de auditoría
  1. Las grandes empresas realizan auditorías de riesgos cada año.
  2. Los riesgos derivados del RGPD han sido incluidos por Auditoría Interna en las auditorías anuales.
  3. El alcance de estas auditorías hasta ahora ha sido limitado.
Planteamiento 4 – Criterio del legislador
  1. El RGPD menciona las auditorías al hablar de las funciones del DPO pero no establece plazos.
  2. El RGPD también habla de las auditorías a los encargados del tratamiento pero tampoco establece plazos.
  3. El legislador español estableció una periodicidad máxima de dos años en la normativa anterior.
Planteamiento 5 – Cambios constantes en el modelo de datos y en las finalidades
  1. El modelo de datos (la estructura de campos) de los tratamientos cambian constantemente.
  2. También pueden producirse cambios en las finalidades de los tratamientos.
  3. El registro de tratamientos queda desactualizado muy rápidamente.
  4. El principio de privacidad desde el diseño y por defecto exige realizar verificaciones periódicas.
  5. El principio de responsabilidad proactiva exige realizar verificaciones periódicas del cumplimiento.
Cuestión planteada ¿Cuál es la periodicidad más adecuada de las auditorías GDPR? Interpretación 1 – Auditoría anual El RGPD exige la realización de verificaciones periódicas. El modelo de datos y las finalidades de los tratamientos están sujetos a cambios constantes. El registro de actividades de tratamiento se desactualiza rápidamente. Es aconsejable realizar una auditoría cada año. Interpretación 2 – Auditoría bienal Es suficiente realizar una auditoría cada dos años. Interpretación 3 – Auditoría mixta Se pueden revisar cada año los elementos más afectados por los cambios y realizar una auditoría en profundidad cada dos años. Interpretación 4 – Auditoría continuada Las tareas de revisión se pueden repartir a lo largo del año con verificaciones mensuales de un tratamiento grupo de tratamientos, de un departamento o de un grupo de controles. COMENTARIOS Puedes realizar tus aportaciones y apoyar una de las dos alternativas en la sección de comentarios de GDPR Hacks en Campus Ribas. Las opiniones pueden ir acompañadas de fundamentación jurídica o de los criterios que te han llevado a tomar partido por la alternativa escogida. Acceso a Campus Ribas https://www.campus-ribas.com Acceso a GDPR Hacks https://www.campus-ribas.com/p/gdpr-hacks

Presentación de la iniciativa GDPR hacks

Origen de la idea

La iniciativa GDPR Hacks surge a causa de la falta de concreción de algunos puntos del GDPR y la diversidad de interpretaciones que ello ha originado.

Las guías de las autoridades de control han sido de gran ayuda para esclarecer cuestiones controvertidas y aportar más detalle a una regulación que en algunos casos puede ser demasiado genérica.

Esta labor de unificación de criterios no ha llegado todavía a zonas que permanecen inexploradas por la doctrina, por las guías y por las resoluciones.

No se trata únicamente de una cuestión cultural ni de la falta de encaje del derecho anglosajón y el derecho continental. La complejidad de la materia y su trascendencia económica exigen una mayor exactitud en algunos puntos de la norma.

Ante la opción de que un mismo precepto pueda tener varias interpretaciones, las altas cuantías de las sanciones del GDPR han hecho que, en muchos casos, los responsables del tratamiento hayan escogido la opción más conservadora. Ese exceso de prudencia ha provocado una pérdida de competitividad en las empresas europeas y, en algunos casos evidentes como el de la interpretación del consentimiento, ha generado pérdida de negocio y un impacto en el PIB acumulado de la UE que nunca llegaremos a conocer.

Sin ningún afán de alterar el sentido de la norma ni la intención original del legislador, GDPR Hacks es un espacio para la reflexión y el análisis de las distintas interpretaciones que puede admitir un artículo o un concepto del GDPR, con el fin de encontrar la más acorde y coherente con el hilo argumental del Reglamento y con cada escenario concreto.

¿Qué es un GDPR Hack?

El concepto GDPR Hack puede incluir, por lo tanto, una gran variedad de opciones:

  1. Un análisis de las distintas interpretaciones que pueden existir sobre una determinada materia.
  2. Un espacio para la reflexión y el debate sobre dichas interpretaciones.
  3. Una invitación a plantear una alternativa a las interpretaciones derivadas más de una inercia que de una reflexión profunda.
  4. Una oportunidad para identificar situaciones en las que hemos sido excesivamente prudentes o conservadores en la interpretación de un precepto al que el legislador, en realidad, había dado otro sentido.
  5. Una forma más eficiente y fácil de cumplir una obligación, dentro de la legalidad, o de crear una evidencia de cumplimiento.
  6. Un reto para la creatividad.
  7. Una nueva visión sobre cuestiones obvias que tal vez no se han tenido en cuenta.
  8. Una nueva conclusión obtenida por inferencia tras el análisis conjunto de varios preceptos. O la detección de una contradicción.
  9. Una exploración conjunta sobre cuestiones que las guías de las autoridades de control no han resuelto todavía.
  10. Una nueva oportunidad para los considerandos, que complementan y explican los preceptos del Reglamento.

¿Qué no es un GDPR Hack?

Un GDPR Hack no es, ni pretende ser, una forma de reingeniería jurídica orientada a alterar el criterio del legislador con la finalidad de alcanzar objetivos que, no siendo los propios de la norma analizada, podrían equivaler a una infracción de la misma.

Debe tenerse en cuenta que los actos realizados al amparo del texto de una norma que persigan un resultado prohibido por el ordenamiento jurídico, o contrario a él, se considerarán ejecutados en fraude de ley y no impedirán la debida aplicación de la norma que se hubiere tratado de eludir.

Un GDPR Hack simplemente plantea dos interpretaciones alternativas que ayuden a formar un criterio sobre aspectos complejos, controvertidos o inexplorados de una norma compleja como el GDPR.

Ya que el usuario es el que toma partido a favor de una de las dos alternativas, un GDPR Hack no lleva implícito ningún tipo de asesoramiento ni recomendación por parte de Campus Ribas.

Un GDPR Hack es un ejercicio dialéctico que puede ayudar a la toma de decisiones, pero no puede ser la única base para la interpretación del GDPR, ya que su aplicación en una organización exige asesoramiento profesional especializado.

Vídeo de presentación

Ver vídeo de presentación en YouTube

Enlace a Campus Ribas

http://www.campus-ribas.com

Servicio específico de prevención de brechas de seguridad

Este mes de agosto, y a pesar de los turnos organizados, hemos tenido que alternar las vacaciones con la gestión de las brechas de seguridad que han sufrido algunos de nuestros clientes.

El crecimiento experimentado en el número de brechas gestionado se debe, principalmente, al incremento del reporte interno de incidentes ocasionados por la pérdida o el robo de ordenadores portátiles y teléfonos móviles que antes no se llegaban a conocer.

La aplicación del RGPD ha obligado a realizar acciones de formación y concienciación, y a establecer la obligación de comunicar internamente cualquier incidente de seguridad, incluida la pérdida y el robo de dispositivos informáticos, por lo que las empresas están recibiendo más información de incidentes que antes no se reportaban.

Teniendo en cuenta que en todas las empresas se pierden o se producen robos de dispositivos móviles, podríamos decir que, en relación a este aspecto, este tipo de incidentes se dividen en dos categorías:

  1. Los que son gestionados como un incidente de seguridad.
  2. Los que simplemente son tratados como un activo informático a reponer.

La diferencia entre ambos enfoques puede tener efectos jurídicos y económicos importantes, ya que, ignorar este tipo de incidentes ayuda a tener unas estadísticas saneadas en materia de seguridad, pero impide realizar un tratamiento adecuado de los riesgos asociados y de la actividad preventiva.

En otras palabras, tener pocos incidentes de seguridad no es un indicador de la eficacia de las medidas de seguridad. Es muy probable que sea un indicador del nivel de desconocimiento de los incidentes que se producen en la empresa.

Otra causa importante de brechas de seguridad han sido los ciberataques en general y los ataques de phishing en especial. El perfeccionamiento de las técnicas de suplantación de identidad, los clics realizados sin un mínimo de reflexión previa y la falta de experiencia en la identificación de los mensajes fraudulentos están haciendo que este tipo de ataques sigan triunfando.

Gracias a la aplicación de un protocolo que permite excluir los incidentes que no han generado una violación de la confidencialidad, la integridad y la disponibilidad de los datos, así como los que no han supuesto un riesgo para los derechos y libertades de los afectados, sólo un pequeño porcentaje de los incidentes gestionados se ha tenido que comunicar a la Agencia Española de Protección de Datos.

En cualquier caso, si unimos la experiencia adquirida en la gestión de brechas a la información suministrada por los incidentes de seguridad publicados y las estadísticas y las resoluciones de la AEPD, podemos decir que existe conocimiento suficiente para identificar:

  1. Las causas más habituales de las brechas de seguridad.
  2. Los errores más habitualmente cometidos por las empresas.
  3. Las medidas concretas que habrían evitado la brecha, pero no se aplicaron.
  4. Las medidas y argumentos en los que la AEPD se ha basado para archivar el expediente sancionador de una brecha.

Con este conocimiento hemos diseñado un servicio específico de prevención de brechas de seguridad que se une al protocolo de gestión de incidentes de seguridad que ya incluía  nuestra aplicación Compliance 3.0.

Si deseas más información sobre este servicio, puedes enviarme un mensaje a xavier.ribas@ribastic.com

Controles de la nueva ISO 27701 sobre seguridad de los datos personales

Hemos introducido en el apartado Certificaciones de nuestra aplicación Compliance 3.0 los 263 controles de la nueva ISO 27701.

Esta ISO está específicamente destinada a la seguridad de los datos personales, y se basa directamente en el RGPD y en una ISO anterior.

Por ello, se convierte en el marco de referencia ideal para las medidas de seguridad de la empresa. Aunque no se obtenga la certificación, recomendamos que la política de seguridad de la empresa en materia de datos personales se base en los criterios de esta ISO.

Estas medidas también son válidas para la protección de los secretos empresariales.

Si la empresa ya tiene la ISO 27001, o estaba pensando en obtenerla, esta ISO es un desarrollo de la ISO 27001 y de la ISO 27002, pero específicamente orientada a la seguridad de los datos personales.

También recomendamos exigirla a los proveedores críticos que realizan funciones de encargado del tratamiento. Si hasta ahora la ISO 27001 se trataba en el contrato como una de las garantías previstas en el artículo 32 del RGPD, a partir de ahora esta ISO se puede convertir en la mejor garantía en materia de seguridad de los datos personales.

En el caso de que se produzca una brecha de seguridad, tener esta certificación o acreditar que se ha seguido este marco de referencia puede ser utilizado como evidencia del esfuerzo realizado por la empresa para la prevención de incidentes de seguridad.

Datos y conclusiones de las notificaciones relativas a brechas de seguridad realizadas a la AEPD desde el 25/05/18

Analizar los datos relativos a las brechas de seguridad que se han notificado hasta ahora a la AEPD puede ayudarnos a conocer las causas más habituales de los incidentes de seguridad y a identificar las medidas más eficaces para prevenirlas.

Desde el 25 de mayo de 2018 hasta el 31 de marzo de 2019, los datos publicados por la AEPD indican que el número de notificaciones relativas a brechas de seguridad recibidas por dicha Agencia superan las 800. Este número parece bajo si tienen en cuenta los siguientes escenarios que pueden ser considerados como una brecha de seguridad con violación de la confidencialidad de los datos:

  1. Cada vez que se pierde o es objeto de hurto o robo un dispositivo informático, la probabilidad de que contenga datos personales es alta.
  2. Cada vez que un empleado es víctima de un ataque que utiliza la ingeniería social, incluyendo el engaño, la suplantación de identidad, el phishing para acceder a datos o para instalar malware, la probabilidad de que este ataque genere una brecha de seguridad es alta.
  3. Cada vez que un empleado causa baja en una organización, especialmente en las áreas de marketing y comercial, la probabilidad de que conserve datos en su poder de forma no autorizada es alta.

Origen de las notificaciones

De acuerdo con los datos de la AEPD, el número de notificaciones realizadas por organizaciones privadas es muy superior al de las realizadas por organizaciones públicas.

Tipología de las brechas de seguridad

Podemos apreciar que la gran mayoría de las notificaciones se refieren a violaciones de la confidencialidad de los datos, es decir, a incidentes de seguridad que han permitido un acceso no autorizado o una divulgación no autorizada de los datos personales. Ello permite actualizar el mapa de riesgos y optimizar el esfuerzo realizado en medidas de seguridad, confirmando que los riesgos que tienen mayor probabilidad son los relacionados con la confidencialidad de los datos. También permite acumular los esfuerzos realizados en materia de protección de los activos intangibles a las medidas derivadas de la reciente normativa relativa a los secretos empresariales.

Medios de materialización de las brechas de seguridad

Se confirma la sospecha de que el usuario sigue siendo el elemento más débil de la seguridad. Si analizamos los medios de materialización de las brechas de seguridad y agrupamos los que se tienen como origen un descuido, un engaño o cualquier otro escenario en la que la actuación del usuario puede provocar o facilitar la brecha de seguridad, veremos que son la mayoría. Por ello es necesario seguir reforzando la inversión en formación y concienciación. También es importante tener en cuenta que la violación de la confidencialidad puede producirse de manera verbal.

Contexto y nivel de intencionalidad

Se puede comprobar que cuando el origen es interno, los incidentes provienen generalmente de un descuido o de otras causas no intencionadas. Por el contrario, cuando el origen es externo, la mayor parte de los incidentes son intencionados. Entendemos que los incidentes externos no intencionados provienen en su mayoría de los encargados del tratamiento que no han invertido suficientes medidas de seguridad para la protección de los datos tratados. Ello confirma la necesidad de extremar el control sobre los proveedores críticos y de verificar el alcance real de las certificaciones ISO 27001 aportadas.

NOTA: pueden producirse pequeñas discrepancias en la suma de cada tabla a causa de la conversión de porcentajes a unidades en relación a los datos de origen del año 2018.

FUENTE DE LOS DATOS: Agencia Española de Protección de Datos.

 

Atrapados entre las reclamaciones de los interesados y las limitaciones de responsabilidad de los encargados del tratamiento

Si hacemos un análisis de las brechas de seguridad que se han conocido desde el 25 de mayo veremos que un gran número de ellas han tenido su origen en el proveedor que trataba los datos.

En el momento de distribuir las responsabilidades veremos que el incumplimiento de las obligaciones del proveedor encargado del tratamiento puede afectar al responsable del tratamiento que ha contratado sus servicios. 

El responsable del tratamiento tiene la obligación de contratar proveedores que ofrezcan garantía suficientes (culpa in eligendo) y controlar su actividad, llegando a auditarlos en el caso de los proveedores críticos (culpa in vigilando)

En la siguiente tabla se puede ver cómo podrían distribuirse las responsabilidades entre el responsable y el encargado del tratamiento en cada uno de los escenarios en los que puede incurrir un proveedor.

Esta tabla no contempla las posibles acciones penales derivadas de un eventual delito contra la intimidad en el caso de violación de la confidencialidad o de un delito de daños en el caso de violación de la integridad.

 

En la práctica, la empresa responsable del tratamiento será la que tendrá que hacer frente a las reclamaciones de los interesados, por ser la que tiene legitimación pasiva en virtud del contrato suscrito con ellos.

Salvo en el caso de las excepciones contempladas en la tabla anterior, el interesado no tiene acción directa contra el encargado del tratamiento, por lo que si quiere reclamar los daños y perjuicios sufridos tendrá que demandar al responsable del tratamiento, que es el que tiene una relación contractual con el interesado. 

El problema surge cuando el responsable del tratamiento quiere repercutir al encargado del tratamiento las sanciones de la AEPD y las indemnizaciones pagadas a los interesados, ya que puede encontrar limitaciones de responsabilidad en el contrato o limitaciones de cobertura en la póliza de seguros del proveedor.

La empresa responsable del tratamiento puede verse entonces atrapada entre las reclamaciones de los perjudicados y las limitaciones de responsabilidad del proveedor que ha incumplido el RGPD y ha causado el perjuicio a los interesados. 

La primera barrera, es decir, la limitación de responsabilidad por vía contractual puede ser de tres tipos:

  1. Cuantitativa: establecida en una cantidad determinada o en el resultado de multiplicar el coste del servicio por una cifra.
  2. Cualitativa: basada en la exclusión de unos supuestos determinados de responsabilidad.
  3. Indirecta: derivada del incumplimiento de otros requisitos o provocada de facto por la insolvencia del proveedor.

En el caso de que no existan limitaciones contractuales, o éstas sean anuladas tras una negociación con el proveedor o por vía judicial, aparece la segunda barrera, consistente en las limitaciones de la póliza de seguros de responsabilidad civil o en la de ciberriesgo. La limitación de responsabilidad en este caso también puede ser tres tipos:

  1. Cualitativa: supuestos excluidos de la cobertura.
  2. Cuantitativa individual: límite por siniestro.
  3. Cuantitativa anual: límite por la suma anual de siniestros.

Un ejemplo de supuesto excluido de la cobertura del seguro de responsabilidad civil son las sanciones de la AEPD, que acostumbran a formar parte de la cobertura del seguro de ciberriesgo.

La tercera barrera sería la solvencia económica del proveedor.

El análisis de la existencia y la dimensión de las tres barreras que pueden impedir la repercusión al proveedor de las sanciones impuestas por la AEPD y de las cantidades pagadas a los interesados en concepto de indemnización por daños y perjuicios, debe hacerse en la fase de selección y homologación de proveedores, es decir, en la fase previa a la contratación.

Si la empresa no hace sus deberes en esa fase previa, tendrá que hacerlos en un momento en que puede ser demasiado tarde:

  1. Durante la fase de negociación del contrato con el proveedor seleccionado.
  2. Durante la vigencia del contrato, tras una auditoría contractual, o de seguros, que evidencia la existencia de limitaciones a la responsabilidad.
  3. Tras la brecha de seguridad o el incidente o imcumplimiento que ha causado el perjuicio, negociando una distribución adecuada de responsabilidades en función del nivel de implicación en las causas del incidente o por vía judicial.

Una vez constatado el papel de los proveedores en las brechas de seguridad y en las infracciones del RGPD que se han producido hasta el momento, las empresas responsables del tratamiento deberán revisar su metodología de selección, homologación, contratación y control continuado de los proveedores que traten datos personales, con el fin de introducir medidas que permitan una distribución adecuada de las responsabilidades. 

Estas medidas deberán incluir una revisión del contrato, de la cobertura del seguro y de la solvencia del proveedor, con el fin de identificar, gestionar y tener en cuenta, en el proceso de toma de decisiones a aplicar en la fase de selección, las limitaciones que puedan existir a la responsabilidad del proveedor.

 

Invitación a la jornada “RGPD: ¿Qué ha pasado en las empresas desde su obligada aplicación?

El próximo 27 de septiembre tendrá lugar la jornada “RGPD: ¿Qué ha pasado en las empresas desde su obligada aplicación?, en la que participaré con la ponencia “Impacto y valoración de la aplicación del RGPD”.

En ella trataré los siguientes puntos:

  1. Buenas prácticas y errores identificados en los últimos cuatro meses.
  2. Cuál será su coste para las empresas españolas.
  3. Brechas de seguridad que se han conocido desde el 25 de mayo, cómo se han gestionado y cómo podían haberse evitado.

Acceso a la invitación