Skip to main content
Traducción. Autoritativo: ../../runbooks/breach-72h.md.
Referencias: DEC-J4, Ley 21.719 (notificación a la APDP sin dilación indebida; objetivo 72 h; titulares afectados si hay riesgo alto).
  1. Detectar y triage (T+0–2 h): confirmar que hay datos personales involucrados; abrir canal de incidente; congelar evidencia (export de BetterStack, extracto de audit_log por correlation_id); clasificar alcance (tenants, contactos, campos — ¿se expuso national_id?).
  2. Contener (T+2–12 h): revocar keys y tokens expuestos; rotar secretos; parchar el vector; si hubo exfiltración por webhook o integración, desactivar el endpoint; snapshot del estado de la base.
  3. Evaluar (T+12–36 h): contar titulares afectados por tenant; nivel de riesgo (campos sensibles ⇒ alto); documentar en el registro de incidente (plantilla en Comply).
  4. Notificar a los responsables (tenants) (T+≤48 h): según la obligación del DPA “sin dilación indebida”: conteos afectados, campos, medidas, recomendaciones. Plantilla: anexo de 70-legal.
  5. Notificar a la APDP (T+≤72 h): por el canal de la Agencia; firma el DPO. Si hay riesgo alto: planificar la notificación a los titulares CON los tenants afectados (ellos son responsables; nosotros asistimos).
  6. Remediar y verificar (T+≤7 d): corregir la causa raíz; agregar test de regresión; verificar en los logs que no se repite.
  7. Post-mortem (T+≤14 d): documento sin culpas; actualizar RAT y DPIA si cambió el tratamiento; archivar el paquete de evidencia (la APDP audita evidencia operativa fechada).
Trimestral: simulacro de mesa; mantener al día la hoja de contactos (APDP, abogado, DPO de los proveedores de hosting).