Cada pocas semanas leemos la misma noticia, una empresa sufre un “ciberataque” y los datos de sus clientes acaban en manos ajenas. Detrás de esos titulares hay conceptos que conviene entender, porque afectan a cualquier organización que maneje datos personales, desde un hotel hasta una clínica, un ayuntamiento o una pequeña tienda online. Y afectan, sobre todo, a las personas cuyos datos están en juego. Vamos a explicarlo sin tecnicismos.

Incidente de seguridad y brecha de datos, no son lo mismo

El primer malentendido habitual es confundir ambos términos. Un “incidente de seguridad” es cualquier evento que compromete, o puede comprometer, la seguridad de la información. Una “brecha de datos personales” es algo más concreto, un incidente que afecta a datos de personas, ya sea porque se han perdido, alterado, destruido o porque alguien no autorizado ha accedido a ellos.

Dicho de otro modo, toda brecha de datos es un incidente de seguridad, pero no todo incidente de seguridad es una brecha de datos

Ejemplo. Si a una empresa se le cae el servidor de correo durante unas horas por un fallo eléctrico, hay un incidente de seguridad (se ha visto afectada la disponibilidad), pero no necesariamente una brecha de datos, porque nadie ha accedido indebidamente a información personal. En cambio, si un empleado pierde un portátil sin cifrar con la base de datos de clientes, ahí sí hay una brecha, datos personales expuestos a quien encuentre el equipo.

Las tres caras de una brecha

La normativa (el Reglamento General de Protección de Datos, o RGPD) distingue tres tipos de afectación, y una brecha puede combinar varias:

Confidencialidad: alguien accede o se lleva datos que no debería ver. Es el caso típico del robo o la filtración de una base de datos.

Integridad: los datos se alteran o manipulan. Por ejemplo, un atacante que modifica importes o registros.

Disponibilidad: los datos se pierden o quedan inaccesibles. Es lo que ocurre en un ataque de “ransomware” que cifra la información y pide un rescate para devolverla.

Ejemplo. Un correo enviado por error con copia visible a doscientos destinatarios (el clásico “para” en lugar de “copia oculta”) es una brecha de confidencialidad, cada destinatario ha visto las direcciones de los demás. Pequeña, quizá, pero brecha al fin y al cabo.

¿Hay que avisar siempre a la Agencia? No

Aquí está una de las claves peor entendidas. No toda brecha se comunica a la Agencia Española de Protección de Datos (AEPD). La ley exige notificarla únicamente cuando suponga un riesgo para los derechos y libertades de las personas afectadas. Si es improbable que ese riesgo exista, no hay obligación de notificar, aunque sí de documentar internamente lo sucedido.

El plazo, cuando procede notificar, es de 72 horas desde que el responsable tiene conocimiento de la brecha. No desde que se resuelve, ni desde que se entiende del todo, desde que se sabe que ha ocurrido. Si no se llega a tiempo con toda la información, se notifica igualmente y se completa después, explicando el motivo del retraso.

Ejemplo que SÍ se notifica. Un tercero accede sin autorización al sistema de reservas de un hotel y extrae nombres, teléfonos, correos y fechas de estancia de miles de clientes. Aunque no haya datos bancarios, esa combinación permite fraudes de suplantación dirigidos (mensajes que se hacen pasar por el hotel). Hay riesgo real, y hay que notificar.

Ejemplo que probablemente NO se notifica. Un empleado accede por error a la ficha de un compañero de trabajo, se da cuenta, cierra sin copiar nada y lo comunica de inmediato. El riesgo para el afectado es ínfimo. Se documenta internamente, pero no es necesario acudir a la Agencia.

¿Y hay que avisar a los propios afectados?

Es un segundo nivel, distinto del anterior. Cuando la brecha entraña un riesgo alto para las personas, no basta con avisar a la Agencia, hay que comunicar también a los propios interesados e interesadas, de forma clara y sin rodeos, para que puedan protegerse. La ley incluso advierte de que no vale esconder la gravedad tras eufemismos ni dar falsas tranquilidades del tipo “sus datos no corren ningún riesgo”.

Ejemplo. Si la brecha expone datos que permiten estafar a los clientes, hay que escribirles y decirles qué ha pasado, qué datos se han visto afectados, qué podrían intentar hacer los delincuentes y cómo protegerse. Avisar a tiempo no solo es una obligación legal, es lo que evita que una persona pique en el fraude por no estar advertida.

El punto que muchos olvidan, ¿y si la brecha ocurre en un proveedor?

Llegamos al aspecto menos conocido y, a la vez, más decisivo en la práctica. La mayoría de las organizaciones no gestionan solas sus datos, usan proveedores. El programa de facturación, la plataforma de reservas, el servicio de “nube”, la empresa de mensajería que envía los correos… Todos ellos tratan datos por cuenta de la organización, en el lenguaje de la ley, la organización es el “responsable del tratamiento” y el proveedor es el “encargado del tratamiento”.

La consecuencia es importante, si la brecha se produce en el proveedor, la obligación de responder ante la Agencia y ante los afectados sigue siendo, con carácter general, del responsable, es decir, de la organización que contrató el servicio. El proveedor no desaparece del mapa (tiene sus propias obligaciones), pero quien da la cara ante los clientes y ante la autoridad es, normalmente, la empresa que recogió esos datos.

Ejemplo. Una clínica utiliza un software de gestión de pacientes de una empresa externa. Un atacante entra en los servidores de esa empresa y roba las historias. Aunque el fallo técnico esté en el proveedor, es la clínica quien debe valorar la notificación a la Agencia y avisar a sus pacientes. Por eso conviene tanto elegir bien a los proveedores como tener el contrato adecuado con ellos.

El contrato de encargo, el seguro de vida que casi nadie lee

Aquí es donde el cumplimiento normativo deja de ser teoría. La ley exige que la relación entre el responsable y su proveedor esté regulada por un contrato específico, el llamado “contrato de encargo de tratamiento”. No es un trámite burocrático, es el documento que determina quién hace qué cuando las cosas van mal.

Un buen contrato de encargo debe dejar claro, entre otras cosas:

Qué puede hacer el proveedor con los datos y qué no, y que solo los tratará siguiendo las instrucciones de la organización.

Qué medidas de seguridad está obligado a aplicar.

Cómo y en cuánto tiempo debe avisar a la organización si sufre una brecha, para que esta pueda cumplir su plazo de 72 horas. De poco sirve el plazo legal si el proveedor tarda una semana en dar la alarma.

Qué ocurre con los subcontratistas (el proveedor del proveedor), que son un punto ciego frecuente.

Qué responsabilidades asume cada parte y cómo se reparten las consecuencias, incluidas las económicas, si el incidente causa daños.

Ejemplo. Dos hoteles sufren la misma brecha a través del mismo proveedor de reservas. El primero tenía un contrato de encargo cuidado, obligaba al proveedor a notificar cualquier incidente en 24 horas, a colaborar en la investigación y a responder de los daños imputables a su negligencia. El segundo se había limitado a aceptar las condiciones genéricas del proveedor sin leerlas. Cuando llega la reclamación y la posible sanción, el primero tiene una posición sólida y un responsable claro al que dirigirse, el segundo, mucho menos. El incidente fue el mismo, la diferencia la marcó el contrato.

Las brechas de seguridad han dejado de ser un riesgo excepcional para convertirse en parte del paisaje digital. No siempre se pueden evitar, pero sí se puede estar preparado, y estar preparado significa tres cosas;

• saber distinguir cuándo un incidente obliga a actuar,
• tener claro que la responsabilidad ante los ciudadanos no se “subcontrata” aunque el fallo ocurra en un proveedor,
• y haber regulado bien, por escrito y de antemano, la relación con quienes tratan nuestros datos.

Cuando llega el problema, ya no hay tiempo de negociar el contrato.

La diligencia se demuestra antes, no después.

Isaac Díaz

Procade