Playbook de Respuesta a Violaciones de Datos

Descripción General

Una violación de datos no es un incidente normal. Alguien copió datos que no debía, los clientes pueden enterarse antes de que termines tu primera llamada, y los reguladores empiezan a contar desde el momento en que lo confirmas, estés listo o no. Las primeras 24 horas deciden si queda en un incidente contenido o se convierte en titular y multa.

Este playbook te da una respuesta por fases: confirma y contiene primero, preserva evidencia e investiga después, notifica a quien la ley exige, y luego remedia y aprende. Cada fase termina en casillas con responsables, porque bajo presión lo que falla rara vez es el plan. Es recordar quién hace qué.

Si el incidente es de disponibilidad y no de datos (un DDoS, un clúster caído), esta no es la herramienta. La guía de respuesta a incidentes cubre incidentes generales de producción; usa este playbook solo cuando el acceso no autorizado a datos esté confirmado o sea creíblemente sospechado.

Cuándo Usarlo

Activa este playbook cuando:

• Se detectó o se sospecha con credibilidad un acceso no autorizado a datos sensibles: una alerta de DLP, un archivo señuelo tocado, una exportación masiva inusual
• Un sistema con PII, PHI, datos financieros o credenciales fue comprometido
• Un insider exfiltró datos sin autorización
• Un proveedor con acceso a tus datos reporta una violación que afecta a tus registros
• Un ransomware cifró datos o amenaza con publicarlos. El ransomware moderno casi siempre exfiltra antes de cifrar

No lo actives por una vulnerabilidad que podría provocar una violación pero aún no fue explotada. Eso va al flujo normal de parches y vulnerabilidades, y tratarlo como violación quema tiempo de revisión legal que puedes necesitar después.

Requisitos Previos

Si estás leyendo esto durante una violación activa, salta adelante; improvisarás alrededor de lo que falte. Si lo lees con calma, deja esto listo ahora; cada punto ahorra horas después:

• El asesor legal revisó los requisitos de notificación (GDPR, CCPA, leyes estatales, contratos)
• Existe un contacto o retainer de análisis forense
• Un equipo de respuesta a incidentes con roles (líder, legal, comunicaciones, técnico) está definido
• Las listas de contacto de reguladores, clientes y medios están actualizadas
• Un inventario de datos mapea dónde viven los datos sensibles y quién tiene acceso

Los dos que más duelen cuando faltan son la revisión legal y el retainer forense. Llamar a un bufete por primera vez en la hora 60 de un plazo GDPR es caro y lento. Lo mismo con la forensia: las firmas con retainer contestan el teléfono; a las demás te ponen en cola.

Solución

# Playbook de Respuesta a Violaciones de Datos

> Responsable del playbook: ______ | Última actualización: ______
> Equipo de respuesta a incidentes: ______ | Contacto legal: ______

## Fase 1: Detección y Evaluación (0-2 horas)

### Acciones inmediatas

- [ ] Confirmar que la violación es real (descartar falso positivo)
- [ ] Documentar el indicador inicial: hora, fuente, tipo de alerta
- [ ] Clasificar los datos involucrados: PII, PHI, financieros, credenciales, propiedad intelectual, otros
- [ ] Estimar número de registros o usuarios afectados
- [ ] Asignar comandante de incidente y roles
- [ ] Abrir un canal de comunicación seguro y restringido (no el canal general de incidentes)

### Decisión: ¿dispara requisitos de notificación?

| Jurisdicción | Disparador | Plazo | Notas |
|-------------|---------|----------|-------|
| GDPR | Datos personales comprometidos | 72 horas a la autoridad supervisora | ______ |
| CCPA / CPRA | Información personal accedida sin autorización | Sin demora irrazonable | ______ |
| Leyes estatales (EE. UU.) | Varía por estado | Varía | ______ |
| Contractuales | Definido en DPA o MSA | Definido en el acuerdo | ______ |

## Fase 2: Contención (2-24 horas)

### Contención técnica

- [ ] Aislar sistemas comprometidos (no apagues — preserva la memoria volátil)
- [ ] Revocar credenciales y sesiones comprometidas
- [ ] Bloquear IPs o cuentas no autorizadas a nivel firewall / WAF
- [ ] Deshabilitar claves API o cuentas de servicio comprometidas
- [ ] Rotar todos los secretos que puedan haberse expuesto
- [ ] Preservar logs, snapshots e imágenes de disco antes de limpiar

### Contención administrativa

- [ ] Restringir el acceso a los detalles del incidente a personal con necesidad de saber
- [ ] Pausar despliegues o cambios no esenciales
- [ ] Informar al liderazgo ejecutivo del alcance y estado de la respuesta

## Fase 3: Preservación de Evidencia e Investigación (24-72 horas)

- [ ] Convocar al equipo de forensia (interno o externo)
- [ ] Crear imágenes forenses de los sistemas afectados
- [ ] Recopilar y preservar logs: aplicación, base de datos, red, acceso, auditoría
- [ ] Documentar la cadena de custodia de toda la evidencia
- [ ] Construir la línea de tiempo del atacante: acceso inicial, movimiento lateral, acceso a datos, exfiltración
- [ ] Identificar la causa raíz: vulnerabilidad, mala configuración, robo de credenciales, amenaza interna, compromiso de terceros

## Fase 4: Notificación (según el plazo legal)

### Notificación interna

- [ ] Junta directiva / liderazgo ejecutivo
- [ ] Asesor legal
- [ ] Proveedor de seguros (ciberriesgo)
- [ ] RRHH (si se sospecha amenaza interna)

### Notificación externa

- [ ] Organismos reguladores (según la ley aplicable)
- [ ] Clientes / usuarios afectados
- [ ] Socios o proveedores si sus datos estuvieron involucrados
- [ ] Fuerzas del orden (si es requerido o aconsejable)

### Checklist de contenido de notificación

- [ ] Qué pasó
- [ ] Qué datos estuvieron involucrados
- [ ] Qué pasos se tomaron para contener la violación
- [ ] Qué pasos deben tomar las personas afectadas
- [ ] Información de contacto para preguntas
- [ ] Qué hace la organización para prevenir que se repita

## Fase 5: Remediación y Recuperación (1-4 semanas)

- [ ] Parchear o corregir la vulnerabilidad causa raíz
- [ ] Eliminar los mecanismos de persistencia del atacante (backdoors, cuentas, tareas programadas)
- [ ] Reconstruir sistemas comprometidos desde fuentes confiables si la integridad es incierta
- [ ] Rehabilitar sistemas con monitoreo reforzado
- [ ] Verificar que no persiste acceso no autorizado
- [ ] Realizar una revisión de seguridad de los sistemas afectados
- [ ] Actualizar controles de seguridad: MFA, segmentación, logging, alertas

## Fase 6: Post-Incidente (2-4 semanas)

- [ ] Realizar un postmortem sin culpa (ver plantilla de postmortem)
- [ ] Rastrear y completar todas las acciones de remediación
- [ ] Revisar y actualizar este playbook con las lecciones aprendidas
- [ ] Revisar el inventario de datos y los controles de acceso
- [ ] Actualizar la evaluación de riesgos y la cobertura de seguros si hace falta
- [ ] Publicar un resumen transparente a las partes afectadas (según corresponda)

## Roles y Responsabilidades

| Rol | Responsabilidades | Primario | Respaldo |
|------|------------------|----------|----------|
| Comandante de Incidente | Coordinación general, autoridad de decisión, actualizaciones a interesados | ______ | ______ |
| Líder Técnico | Contención, forensia, remediación | ______ | ______ |
| Asesor Legal | Requisitos de notificación, cumplimiento regulatorio, privilegio | ______ | ______ |
| Líder de Comunicaciones | Mensajería a clientes, medios e interna | ______ | ______ |
| Representante de RRHH | Amenaza interna, impacto en empleados | ______ | ______ |

## Lista de Contactos

| Parte | Contacto | Método | Notas |
|-------|----------|--------|-------|
| Asesor legal | ______ | ______ | ______ |
| Seguro cibernético | ______ | ______ | ______ |
| Firma forense | ______ | ______ | ______ |
| Fuerzas del orden | ______ | ______ | ______ |
| Organismo regulador | ______ | ______ | ______ |

Explicación

El orden de las fases sigue la presión real de una violación. Las horas 0-24 son para confirmar que es real y frenar la hemorragia; los días 1-3 para entender qué pasó y preservar la prueba; las semanas siguientes para cerrar el agujero y cerrar el ciclo con la gente a la que tuviste que avisar.

Dos decisiones de la plantilla pesan más de lo que parece. Primero, el canal restringido: asume que el atacante puede leer tu sala de incidentes habitual. Si la violación tocó el correo o el chat, mueve la coordinación a un canal fuera de banda. Segundo, la matriz de notificación: saltarse un plazo legal convierte un incidente de seguridad en una sanción, y los plazos son cortos. Las 72 horas de GDPR son el límite estricto más común, así que la mayoría de equipos lo usa como reloj por defecto y deja que el asesor legal lo relaje si la ley no aplica.

La contención con evidencia primero es la otra decisión no obvia. Aislar una máquina está bien; borrarla, mal. La memoria volátil, las sesiones y los procesos en ejecución desaparecen al apagar, y los logs rotan por su propia cuenta. Captura antes de limpiar, o tu equipo forense, y luego tus abogados, no tendrán con qué trabajar.

Por último, la tabla de roles existe porque la propiedad compartida es propiedad de nadie. Cuando tres personas creen que otro llamó a la aseguradora, nadie llama a la aseguradora.

El Reloj de 72 Horas: Un Escenario GDPR

Recorre un escenario para ver por qué las fases van en ese orden. Imagina un martes a las 09:00: los datos de cuentas de clientes europeos salen en un paste público.

• 09:00-11:00. El ingeniero de guardia confirma que el paste es data real, no un dump reciclado, y abre el canal restringido. El comandante de incidente lo clasifica: datos personales de residentes de la UE. El reloj GDPR acaba de arrancar.
• 11:00-día 2. Se revoca la cuenta de servicio comprometida, el endpoint de exportación se limita y luego se deshabilita, y se toman snapshots de los hosts afectados antes de reconstruir nada. El liderazgo recibe un brief de dos líneas: qué sabemos, qué no.
• Día 2-3. La forensia arma la línea de tiempo: el atacante entró por una API key filtrada, leyó el endpoint de exportación durante seis días y se llevó ~40.000 registros. El asesor legal confirma que la notificación es obligatoria: datos personales, acceso confirmado, riesgo probable para las personas.
• Antes de las 72 horas. Notifica a la autoridad supervisora con lo que se sepa para entonces. GDPR exige puntualidad, no completitud. A los clientes afectados les llega el email de la plantilla de abajo. El postmortem y la remediación completa siguen semanas, pero el plazo legal ya quedó cubierto.

Nota lo que no pasó: nadie esperó certeza perfecta sobre el alcance antes de decidir notificar. “Detectamos acceso no autorizado a datos personales y estamos investigando” es una notificación completa y conforme cuando los hechos aún se están formando.

Plantillas de Comunicación de Respuesta a Violación

Tres reglas antes de enviar cualquier cosa de esta sección: un solo portavoz, revisión legal de cada mensaje externo y cero especulación. Escribe lo que sabes y lo que estás haciendo — nunca lo que crees que hizo el atacante ni lo grave que podría ser. Si tu organización ya usa la plantilla de comunicación de incidentes, fusiona su estructura con estas; los campos específicos de violación son los que importan.

=== Interno: Alerta Inicial de Violación (Slack/Email) ===

ASUNTO: [SEV-SECURITY] Sospecha de violación de datos — [SISTEMA]

Comandante de incidente: [NOMBRE]
Bridge: [TELÉFONO/ENLACE DE VIDEO]
Estado: Investigando
Resumen: [DESCRIPCIÓN BREVE — qué se detectó, cuándo, por quién]
Impacto: [DESCONOCIDO / CONFIRMADO — qué sistemas/datos pueden estar afectados]
Próximos pasos: [CONTENCIÓN / FORENSIA / NOTIFICACIÓN]

NO discutir detalles en canales públicos.
Usar solo el bridge del incidente y #sec-incident-private.

=== Externo: Email de Notificación al Cliente ===

Asunto: Aviso de Seguridad Importante — [EMPRESA]

Estimado/a [CLIENTE],

Te escribimos para informarte de un incidente de seguridad que pudo
afectar la información de tu cuenta. Descubrimos el incidente el
[FECHA] y actuamos de inmediato para asegurar nuestros sistemas.

Qué pasó:
  [DESCRIPCIÓN BREVE, NO TÉCNICA]

Qué datos estuvieron involucrados:
  [LISTA DE TIPOS DE DATOS — ej., nombre, email, contraseña hasheada]

Qué hemos hecho:
  - Contener la violación y asegurar los sistemas afectados
  - Contratar investigadores forenses y notificar a las autoridades
  - [PASOS ADICIONALES]

Qué debes hacer:
  - Cambia tu contraseña de inmediato
  - Activa la autenticación de dos factores
  - Revisa tu cuenta en busca de actividad sospechosa
  - [RECOMENDACIONES ADICIONALES]

Nos tomamos en serio la seguridad de tus datos y lamentamos cualquier
preocupación que esto pueda causarte. Te daremos actualizaciones a
medida que sepamos más.

Contacto: [EMAIL_SOPORTE / TELÉFONO DEDICADO]

Equipo de Seguridad de [EMPRESA]

=== Externo: Actualización de Página de Estado ===

[INVESTIGANDO] Estamos investigando un incidente de seguridad que
afecta a [SISTEMA]. Hemos puesto los sistemas afectados fuera de
línea y trabajamos para determinar el alcance. Actualizaremos esta
página cada [INTERVALO] hasta que se resuelva.

[IDENTIFICADO] Hemos identificado la causa del incidente de seguridad
y contenido la amenaza. Los sistemas afectados se están restaurando
con medidas de seguridad reforzadas. Notificaremos a los usuarios
afectados directamente.

[RESUELTO] El incidente de seguridad está resuelto. Todos los sistemas
afectados están seguros y operativos. Publicaremos un informe
post-incidente detallado el [FECHA].

Variantes

Contexto	Ajustes	Notas
Violación en proveedor cloud	Añadir contacto del equipo de respuesta del proveedor, revisión de responsabilidad compartida y notificación al proveedor	Tú y el proveedor pueden tener obligaciones
Amenaza interna	Añadir participación de RRHH, revisión de logs de acceso y consideraciones de derecho laboral	Los casos internos tienen implicaciones legales y de RRHH distintas
Violación en proveedor externo	Añadir revisión del DPA, requisitos de notificación del proveedor y evaluación de dependencias	Tus datos en sus sistemas siguen siendo tu responsabilidad
Ransomware	Añadir política de pago, plan de restauración de copias y contacto con fuerzas del orden	Pagar el rescate es una decisión de negocio y legal
Startup pequeña (sin equipo de seguridad)	Añadir pasos de contratación de firma externa y asignación simplificada de roles	La velocidad importa más que la exhaustividad cuando eres pequeño

La fila de proveedor merece énfasis porque los equipos se equivocan en ambos sentidos: o asumen que la notificación del proveedor los cubre (no — tú eres el responsable del tratamiento) o notifican antes de confirmar qué registros suyos se expusieron. Revisa el DPA, pide el informe de incidente del proveedor y entonces decide.

Lo Que Funciona

1. Practica el playbook. Haz un ejercicio de mesa trimestral: elige un escenario, recorre las fases, anota dónde se rompe. Un playbook que nunca usaste es un pasivo
2. Preserva antes de limpiar. La forensia depende de la evidencia; una contención que destruye logs hace imposible el análisis de causa raíz
3. Involucra al legal temprano. El privilegio cliente-abogado puede proteger los hallazgos de la investigación ante un litigio
4. Documenta en tiempo real. La memoria se distorsiona bajo presión; un registro continuo vale más que un recuerdo ante un regulador
5. No prometas lo que no puedes verificar. Si aún no sabes el alcance, dilo. Prometer certezas que no tienes mata la credibilidad cuando salen los números

Errores Comunes

1. Apagar los sistemas de inmediato. Pierdes memoria volátil y logs. Aísla, no apagues
2. Notificar demasiado pronto o demasiado tarde. Notificar pronto sin hechos causa pánico; tarde, sanciones. La matriz existe para dosificar esa decisión
3. Saltarse la preservación de evidencia. Sin evidencia no puedes probar qué pasó, defenderte de demandas ni aprender
4. Coordinar por canales comprometidos. Asume que el atacante lee tu chat de incidentes; usa comunicación fuera de banda desde la primera hora
5. Declarar victoria en la contención. La violación no termina cuando sale el atacante. Termina cuando el sistema es demostrablemente más seguro y la lista de remediación está cerrada

Troubleshooting

• El atacante sigue dentro tras rotar credenciales: rota en oleadas: cuentas de servicio, tokens de refresco y sesiones activas también, no solo contraseñas de usuario. Las sesiones persistentes suelen sobrevivir a un reset.
• Los logs ya rotaron: revisa la retención del SIEM y de los backups antes de declarar el alcance. Recupera lo que puedas de los archivos y anota el vacío en la línea de tiempo: un “no lo sabemos” documentado vale más que una suposición.
• El proveedor no comparte detalles forenses: escala por las cláusulas de violación de tu DPA y documenta su negativa. Tus obligaciones de notificación son tuyas, coopere o no.
• El asesor legal no responde un fin de semana: el reloj de 72 horas no pausa. Mantén una vía de escalado de guardia en la lista de contactos, no el número de una sola persona.
• El seguro exige su propia firma forense: revisa la póliza antes de contratar la tuya. Usar una firma no aprobada puede anular la cobertura de la investigación.

Mantener el Playbook al Día

Un playbook de violaciones envejece más rápido que la mayoría de documentos: la gente se va, los proveedores cambian, las leyes se actualizan. Revísalo trimestralmente junto al ejercicio de mesa, y trata la lista de contactos como lo que primero se pudre. Tras cualquier incidente real, actualízalo con el postmortem aún fresco; la plantilla de postmortem de incidentes encaja con este playbook para ese paso.

Mantenlo bajo control de versiones con un responsable con nombre, y guarda una copia que sobreviva a un compromiso de tu correo y chat. Una copia offline ha sacado de un apuro a más de una respuesta real.

Véase También

• GDPR art. 33 — notificación a la autoridad supervisora y art. 34 — comunicación a los interesados
• HHS — regla de notificación de brechas de HIPAA
• NIST SP 800-61r2 — guía de gestión de incidentes de seguridad
• PCI Security Standards Council — biblioteca de documentos
• Guía de respuesta a incidentes para incidentes de producción que no sean violaciones
• Guía de cumplimiento GDPR para el programa general de protección de datos
• Repositorio complementario: playbook de violaciones + plantillas de notificación