Brecha de seguridad de datos: qué se debe poder demostrar

Publicado el 20 de agosto de 2026

Tu equipo detecta una anomalía un viernes por la noche, activa el protocolo y el lunes envía la notificación dentro de plazo. Sobre el papel todo ha funcionado: la brecha de seguridad de datos personales se ha gestionado como indica el manual.

El problema aparece después. La verificación puede llegar meses o años más tarde, y entonces la autoridad de control ya no pregunta qué declaraste, sino de dónde sale lo que declaraste: quién vio qué, a qué hora y con qué información delante al decidir. Ahí muchas organizaciones descubren que tienen un relato ordenado y muy poca prueba, porque los registros que lo sostienen los custodia la misma parte que necesita acreditar su diligencia. Conviene hacerse la pregunta antes de que la haga otro: ¿con qué evidencia sostienes cada dato que ya has notificado?

Qué exige la normativa cuando se notifica una brecha de seguridad

Una brecha de seguridad de datos personales es un incidente que provoca la destrucción, pérdida o alteración accidental o ilícita de datos personales, o su comunicación o acceso no autorizados. El plazo de 72 horas del artículo 33 del RGPD corre desde que el responsable tiene constancia de la brecha, no desde que ocurre.

Esa distinción entre ocurrencia y constancia es la que más discusiones genera. Las Directrices 9/2022 del Comité Europeo de Protección de Datos precisan que hay constancia cuando existe un grado razonable de certeza de que se ha comprometido información personal, y admiten un breve periodo de investigación previa para alcanzarla. Ese periodo también habrá que explicarlo después.

El artículo 33.3 fija el contenido mínimo: naturaleza de la brecha, categorías y número aproximado de interesados y de registros afectados, contacto del delegado de protección de datos, consecuencias probables y medidas adoptadas. El artículo 83.4.a sitúa el incumplimiento en el tramo de hasta 10 millones de euros o el 2 % del volumen de negocio anual global, la cifra que resulte mayor. El RGPD alcanza además a responsables de terceros países que ofrecen bienes o servicios a personas situadas en la Unión, de modo que muchas empresas latinoamericanas responden a la vez ante su autoridad nacional y ante una europea.

Los plazos del RGPD y de la directiva NIS2

Cuando un incidente afecta a datos personales y a la continuidad de un servicio, se abren dos cadenas de notificación con destinatarios y plazos distintos.

Las entidades financieras suman una tercera capa con el Reglamento DORA. Tres cadenas paralelas producen tres versiones de los mismos hechos, y cualquier discrepancia entre ellas es material de contradicción.

Las obligaciones que siguen vigentes después de notificar

Enviar la notificación no cierra el expediente. El artículo 33.5 obliga a documentar cualquier brecha, sus efectos y las medidas correctivas, con una finalidad expresa: permitir que la autoridad verifique el cumplimiento. Ese registro es obligatorio incluso cuando decides que el incidente no era notificable, y en ese caso es la única prueba de que la valoración del riesgo se hizo y se hizo bien.

Se añaden dos deberes más. La notificación puede completarse por fases si en 72 horas no dispones de toda la información, según el artículo 33.4. Y el artículo 34 obliga a comunicar la brecha a los interesados cuando entrañe un alto riesgo para sus derechos y libertades, con excepciones tasadas como el cifrado previo de los datos afectados.

Las cuatro cosas que una organización debe poder demostrar

La notificación te pide declarar cuatro elementos; la verificación posterior te pide demostrarlos, que es una exigencia distinta. El artículo 5.2 del RGPD establece la responsabilidad proactiva: el responsable no solo debe cumplir, sino ser capaz de demostrar que cumple. Aplicado a una brecha, acreditar cuándo se detectó el incidente, a qué datos afectó, quién decidió cada paso y qué medidas se adoptaron recae sobre la propia organización. Nadie tiene que probar que actuaste tarde: eres tú quien debe probar que actuaste a tiempo.

1. Detección: cuándo supiste que había un incidente y a partir de qué señal.
2. Alcance: qué datos, cuántos interesados y qué sistemas quedaron expuestos.
3. Decisiones: quién resolvió cada paso, con qué información y en qué orden.
4. Medidas: qué se contuvo, qué se corrigió y en qué momento exacto.

El momento exacto en que se detectó el incidente

De este dato depende todo lo demás, porque marca el inicio de las 72 horas. Si el registro que lo acredita procede del mismo sistema que administra tu equipo, estás afirmando una hora, no demostrándola: el reloj que genera la marca y el archivo que la almacena dependen de la parte interesada en que esa hora sea la correcta. No se trata de sospechar de nadie, sino de que un tercero no tiene forma independiente de confirmarlo.

El alcance de los datos y los sistemas afectados

El artículo 33.3 admite un número aproximado de interesados y de registros, concesión razonable al desconocimiento inicial. No exime, en cambio, de explicar cómo se llegó a esa cifra: qué consultas se lanzaron, sobre qué tablas y con qué resultado en pantalla. En sectores con datos de categorías especiales, como la sanidad, donde la integridad de la historia clínica digital condiciona además la asistencia, delimitar el alcance suele ser el punto más discutido.

Las decisiones tomadas y por quién

Gestionar un incidente es encadenar decisiones con información incompleta: quién autorizó aislar un segmento, quién descartó la exfiltración, quién concluyó que el riesgo no era alto y que por tanto no procedía la comunicación del artículo 34. Todo eso circula por correo, mensajería corporativa y sistemas de tickets, soportes que la organización administra y puede modificar. Certificar el correo electrónico de la escalada convierte una afirmación sobre la cadena de mando en un documento con fecha verificable desde fuera.

Las medidas adoptadas para contener y remediar

Las medidas de contención se declaran en la notificación y se valoran después al graduar la sanción, conforme al artículo 83.2. Un bloqueo de cuentas o una rotación de credenciales dejan huella en los sistemas, pero esa huella vuelve a ser interna. Lo que resiste una revisión es el estado del sistema documentado mientras la intervención se produce, no reconstruido semanas más tarde con los mismos registros que se pretende validar.

Por qué los registros internos no bastan como prueba

Un registro interno es un archivo modificable, generado y custodiado por la misma organización que necesita acreditar su diligencia. Como prueba es admisible, aunque es también el punto más fácil de discutir: basta impugnar su autenticidad para que el debate deje de girar sobre el incidente y pase a girar sobre el archivo. El deber de documentar del artículo 33.5 garantiza que la información exista; que un tercero pueda verificarla es otro problema, y se confunden a menudo porque el primero se resuelve con una política de retención y el segundo no.

Archivos modificables producidos por quien debe demostrar su propia diligencia

Los logs de aplicación, el registro de brechas, las capturas guardadas en una carpeta compartida y las notas del gestor del incidente comparten un rasgo: cualquiera con permisos suficientes puede alterarlos sin dejar rastro externo. Que nadie lo haya hecho resulta irrelevante: lo que se examina no es tu conducta, sino la posibilidad de comprobarla. Una cadena de custodia digital documentada acredita que el contenido examinado hoy es idéntico al recogido entonces, sin depender de la buena fe de quien lo aporta. La respuesta al incidente sigue en manos de tu equipo de seguridad; TrueScreen actúa en la capa siguiente, la que hace oponible a un tercero lo que ese equipo vio y decidió.

Cómo se impugna un registro interno y a quién vuelve la carga de la prueba

En el proceso civil español, el artículo 299.2 de la LEC 1/2000 admite como medios de prueba los instrumentos que permiten archivar, conocer o reproducir palabras, datos y cifras, y el artículo 384 dispone que el tribunal los valore conforme a las reglas de la sana crítica. No hay valor tasado: la fuerza de un archivo depende de cuánto pueda verificarse sobre él. Ahí se abre la vía de la impugnación, porque cuando la parte contraria discute la autenticidad de lo aportado, la carga de acreditarla vuelve a quien lo presentó. Así funciona la prueba electrónica en el proceso civil, y quien produjo el archivo por sí mismo tiene mucho que probar.

Cómo recoger evidencias que resistan una impugnación

La diferencia entre una evidencia sólida y una discutible rara vez está en la tecnología empleada: está en el momento en que se recoge y en quién garantiza ese momento. Los criterios de admisibilidad de la prueba digital apuntan siempre a lo mismo: identificar la fuente, fijar el instante de la captura y demostrar que nada cambió desde entonces.

Qué certificar mientras se gestiona el incidente

No todo necesita certificación y pretenderlo paralizaría la respuesta. El criterio útil es certificar lo que después habrá que demostrar y no existe en ningún otro sitio: la pantalla de la alerta en el momento del hallazgo, la captura de pantalla como prueba del panel con las cifras que sustentaron la valoración del riesgo, los extractos de registro al exportarlos y las áreas autenticadas consultadas durante el análisis.

Las organizaciones usan TrueScreen para certificar extractos de registro, comunicaciones internas y páginas consultadas durante la gestión de un incidente, de modo que la evidencia no resulte producida unilateralmente por quien debe demostrar su propia diligencia.

Cuándo certificar: captura en el momento frente a exportación posterior

Exportar un log tres semanas después demuestra qué contiene el archivo hoy, no qué mostraba el sistema aquella noche. Entre ambos momentos ha habido rotaciones, reindexaciones y, si el incidente fue serio, reconstrucciones de entornos completos. Las políticas de retención resuelven que el dato siga disponible. La integridad verificable no viene incluida en el paquete. Certificar en el momento invierte el orden, porque el instante queda fijado cuando todavía es el presente.

Cómo certificar las evidencias de un incidente mientras se gestiona

TrueScreen certifica las capturas de pantalla de los sistemas de monitorización en el momento en que se miran, aplicando sello de tiempo y sello electrónico a través de un prestador cualificado de servicios de confianza tercero. La adquisición se hace con metodología forense en el origen y el hash SHA-256 del contenido se calcula en ese mismo instante. Sobre ese valor se aplica después el sello electrónico cualificado del Reglamento eIDAS 910/2014, cuyo sellado de tiempo cualificado goza de presunción de exactitud de la fecha y de integridad de los datos asociados.

Son las 23:14 de un viernes. El SOC detecta un volumen de salida anómalo en un servidor de archivos, el responsable de seguridad abre la consola, ve el gráfico y decide aislar el segmento de red. El lunes la organización notifica indicando esa hora como momento de la detección. Ocho meses más tarde, en una inspección, llega la pregunta: ¿de qué evidencia resulta que a las 23:14 la consola mostraba ese dato? El registro del SIEM lo custodia la propia organización, así que responde a medias. Una captura certificada en el instante en que se miró, con sello de tiempo de un tercero, responde del todo.