Gestión de incidentes y brechas de datos: flujo operativo y evidencia (Ley 21.719)

Qué es un incidente vs una brecha (en simple)

No todo incidente de seguridad es una brecha de datos personales, pero toda brecha empieza como un incidente.

• Incidente de seguridad: cualquier evento que comprometa o pueda comprometer la confidencialidad, integridad o disponibilidad de información. Incluye accesos no autorizados, malware, pérdida de dispositivos, errores humanos.
• Brecha de datos personales: un incidente que efectivamente afecta datos personales de titulares identificados o identificables. Es el subconjunto que activa las obligaciones de notificación.

La clasificación importa porque determina la respuesta: un incidente sin datos personales se gestiona internamente; una brecha activa obligaciones legales de notificación, plazos y documentación específica.

El plazo de 72 horas: a quién y cuándo notificar

Cuando una brecha implica un riesgo para los derechos de los titulares, la Ley 21.719 exige notificar a la Agencia de Protección de Datos sin demora injustificada y, como referencia, dentro de las 72 horas desde que el responsable toma conocimiento del incidente. El "reloj" parte con el conocimiento, no con la resolución: no se espera a cerrar el incidente para notificar.

Por eso el flujo de respuesta debe estar definido de antemano: improvisar la notificación dentro de 72 horas, sin roles ni plantillas, es la forma más rápida de incumplir el plazo o de notificar mal.

Flujo operativo recomendado (end-to-end)

1) Detección y registro

Cualquier persona de la organización debe poder reportar un incidente. El sistema debe generar un ticket único con: quién reporta, cuándo, qué se observó, qué sistemas están involucrados. Sin registro inicial, no hay timeline.

2) Contención

Acciones inmediatas para limitar el alcance: revocar accesos comprometidos, aislar sistemas afectados, preservar evidencia forense. Cada acción debe quedar registrada con timestamp y responsable.

3) Evaluación de impacto

Determinar: ¿afecta datos personales? ¿Cuántos titulares? ¿Qué categorías de datos? ¿Qué tratamientos del RAT están involucrados? Esta evaluación define si se activa la obligación de notificación.

4) Decisiones y escalamiento

Convocar al comité de respuesta: legal, compliance/privacidad, seguridad, dueño del proceso afectado. Documentar las decisiones: notificar o no, a quién, con qué mensaje, en qué plazo.

5) Comunicación y gestión de titulares

Si la brecha representa riesgo para los titulares, comunicar: qué pasó, qué datos se vieron afectados, qué pueden hacer para protegerse. La comunicación debe ser clara, oportuna y documentada.

6) Remediación

Implementar controles correctivos: parchar vulnerabilidades, actualizar accesos, reforzar monitoreo. Cada acción correctiva debe quedar vinculada al incidente y verificada.

7) Cierre y lecciones aprendidas

Auditar el proceso de respuesta: ¿se cumplieron los plazos? ¿Los controles fallaron? ¿Qué se debe mejorar? Las lecciones aprendidas alimentan la mejora continua del programa.

Evidencia mínima que debes producir en cada incidente

Checklist de evidencia

• Fecha/hora de detección y quién reporta
• Clasificación inicial (incidente vs brecha)
• Sistemas afectados
• Tratamientos del RAT involucrados
• Acciones de contención (con timestamps)
• Evaluación de impacto y decisión de notificación (acta/registro)
• Comunicaciones enviadas (a autoridad, a titulares)
• Acciones correctivas implementadas (con vínculo a controles)
• Validación de cierre
• Lecciones aprendidas y mejoras al programa

Roles y responsabilidades (RACI)

R = Responsable, A = Aprobador, C = Consultado, I = Informado

Señales de "improvisación" (y por qué te expone)

• Múltiples planillas y correos: la información del incidente está dispersa en emails, chats y archivos sin conexión. No hay una fuente única de verdad.
• No hay timeline: no se puede reconstruir la secuencia de eventos con timestamps. La autoridad va a preguntar "¿cuándo supieron?" y no hay respuesta clara.
• No hay dueño: nadie coordina la respuesta. Cada área actúa por su cuenta sin visibilidad del estado general.
• No hay vínculo a controles: el incidente se cierra sin conectar las acciones correctivas a los controles del programa. El mismo problema puede repetirse.
• No hay lecciones aprendidas: cada incidente es "un proyecto nuevo" que empieza de cero, sin aprendizaje acumulado.

Cómo Ordentis lo soporta

• Incidente como caso trazable: cada incidente es un caso con timeline, roles, acciones y estado, desde la detección hasta el cierre.
• Vínculo a RAT: se identifica qué tratamientos y titulares fueron impactados, conectando directamente al inventario.
• Vínculo a controles: las acciones correctivas se asocian a los controles del programa, cerrando el loop.
• Evidencias trazables: cada acción, decisión y comunicación queda registrada con fecha, responsable y versión.
• Auditoría: timeline completo y recuperable en minutos para cualquier fiscalización o auditoría interna.

Preguntas frecuentes sobre gestión de incidentes

¿En qué plazo debo notificar una brecha de datos?

Cuando la brecha implica riesgo para los titulares, debes notificar a la Agencia de Protección de Datos sin demora injustificada y, como referencia, dentro de las 72 horas desde que tomas conocimiento del incidente. Si el riesgo para los titulares es alto, también debes notificarles a ellos sin dilación indebida. El plazo corre desde el conocimiento, no desde la resolución.

¿Qué evidencia es crítica en las primeras 24–72 horas?

El registro inicial (quién, cuándo, qué), las acciones de contención con timestamps, la evaluación de impacto y la decisión de notificación. Estos cuatro elementos definen si la respuesta fue diligente o negligente.

¿Cómo conecto incidentes con el RAT?

Cada incidente debe identificar qué tratamientos del RAT se vieron afectados. Esto permite saber qué titulares están impactados, qué bases legales aplican y qué controles fallaron. Sin esta conexión, la respuesta es genérica.

¿Qué pasa si el incidente involucra un proveedor?

El proveedor (encargado de tratamiento) debe notificar al responsable. Tu organización mantiene la responsabilidad ante la autoridad y los titulares. El contrato debe definir plazos de notificación y colaboración en la respuesta.

¿Cómo evito que cada incidente sea "un proyecto nuevo"?

Con un flujo estandarizado: roles predefinidos, checklist de acciones, plantillas de comunicación y un sistema que guíe la respuesta paso a paso. Las lecciones aprendidas de cada incidente mejoran el flujo para el siguiente.

¿Cómo audito mi capacidad de respuesta?

Con simulacros periódicos (al menos semestrales): simula una brecha, mide tiempos de respuesta, evalúa la calidad de la documentación y verifica que los roles funcionan. El registro del simulacro es evidencia de diligencia.

¿Cómo construir mejora continua desde incidentes?

Cada incidente cerrado debe producir: lecciones aprendidas documentadas, acciones correctivas vinculadas a controles, y verificación de que esas acciones se implementaron. El programa mejora con cada incidente gestionado.