Hackeos México 2026: Respuesta Incidentes y Lecciones para España

En enero de 2026, la UNAM informó de una intrusión no autorizada en cinco de sus más de cien mil sistemas, y publicaciones de terceros atribuyeron a un grupo autodenominado «Chronus Team» la extracción de un gran volumen de datos. La propia Universidad declaró haber activado de inmediato sus protocolos y no haber encontrado, en un primer análisis, indicios de extracción de datos personales; las cifras de gran volumen las difundió la parte atacante y no se han confirmado con una fuente primaria. Lo que interesa aquí no es el recuento —en disputa— sino cómo se comunica un incidente cuando conviven la versión oficial y la del atacante y aún no se conoce el alcance.

Lo que hace útil este caso para una empresa española no es la geografía, sino que muestra los problemas que un procedimiento de respuesta a incidentes está pensado para ordenar: comunicar con rapidez y precisión cuando aún no se conoce el alcance, contrastar la versión del atacante, preservar la evidencia desde el primer momento y no dejar que sean los medios quienes marquen los tiempos. En España, además, el RGPD fija plazos concretos de notificación que conviene tener claros de antemano.

Este artículo analiza los hackeos México enero 2026, compara respuesta vs mejores prácticas RGPD España, y proporciona un plan acción completo primeras 72 horas post-brecha para cumplimiento legal y mitigación daños.

Hackeos México Enero 2026: Cronología

Caso 1: UNAM (Universidad Nacional Autónoma de México)

Lo que informó la UNAM (fuente primaria). En su boletín UNAM-DGCS-011, del 7 de enero de 2026, la Universidad comunicó que había detectado una intrusión no autorizada en cinco de sus más de cien mil sistemas, que activó de inmediato los protocolos institucionales, inhabilitó los sistemas afectados y que, en un primer análisis, no había indicios de extracción de datos personales. El boletín no menciona a ningún grupo atacante ni cifra de datos.

Lo que circuló por otras vías (alegaciones no confirmadas). Publicaciones de terceros atribuyeron el incidente a un grupo autodenominado «Chronus Team» y describieron un gran volumen de material supuestamente extraído (se llegaron a mencionar decenas de gigabytes y cientos de miles de credenciales). Esas cifras las difundió la parte atacante y no se han podido confirmar con una fuente primaria; contradicen, de hecho, el primer análisis de la propia Universidad. Se recogen aquí como lo que son —alegaciones en disputa—, no como hechos acreditados.

Lo instructivo del episodio, con independencia del recuento, es la tensión entre la versión oficial y la del atacante y la dificultad de comunicar con rapidez y precisión cuando todavía no se conoce el alcance. Es exactamente el escenario que un procedimiento de respuesta a incidentes está pensado para ordenar.

Caso 2: gobierno de México (varias dependencias)

Semanas después circularon alegaciones —de nuevo atribuidas a «Chronus»— sobre bases de datos vinculadas a organismos del gobierno federal. El 4 de febrero de 2026 una proposición del Senado todavía las calificaba de presunto hackeo y posible vulneración de datos, recogía que la autoridad de transformación digital había negado una filtración reciente y pedía precisamente el informe técnico que aún faltaba. No hay, por tanto, confirmación oficial del alcance ni prueba de que fuera el mismo actor que en el caso de la UNAM: conviene separar lo anunciado por el atacante, lo negado por el Gobierno y lo que sigue sin verificar.

Análisis forense: patrones típicos de una intrusión (escenario genérico)

Una intrusión dirigida suele encadenar cuatro fases:

1. Reconocimiento: el atacante mapea la superficie expuesta —subdominios, servicios abiertos, correos del personal— con OSINT y motores de búsqueda de dispositivos.
2. Acceso inicial: entra por phishing dirigido, por la explotación de una vulnerabilidad sin parchear en un servicio expuesto o por credenciales débiles o reutilizadas.
3. Movimiento lateral y escalada: desde el primer equipo obtiene más credenciales y se desplaza hacia los sistemas con datos, elevando privilegios.
4. Exfiltración: comprime y extrae la información hacia infraestructura que controla, a menudo en varios envíos para no disparar alarmas.

Los fallos que hacen posible este recorrido son casi siempre los mismos: sistemas sin actualizar, ausencia de segmentación de red, falta de monitorización que detecte la exfiltración, copias de seguridad no protegidas y credenciales débiles o reutilizadas. Sobre ellos actúa el plan de respuesta que se detalla a continuación.

RGPD (España) frente al marco mexicano: diferencias

Qué ley mexicana aplica

Conviene no confundir las dos leyes mexicanas de protección de datos. La LFPDPPP regula el tratamiento por sujetos privados (personas físicas o morales de carácter privado). Para la UNAM —que por su ley orgánica es una corporación pública y organismo descentralizado del Estado— y para las dependencias gubernamentales, la referencia pertinente es la LGPDPPSO, aplicable a autoridades, entidades y organismos del sector público. Presentar la LFPDPPP como su régimen es aplicar la ley al sujeto equivocado.

Para los casos de la UNAM y del gobierno, el paralelismo correcto con el RGPD parte de la LGPDPPSO, que —al igual que el RGPD— exige llevar registro de las vulneraciones y comunicar sin dilación. Cualquier comparación con la ley privada debe etiquetarse como tal y no mezclarse con estos casos, que son de sujetos públicos.

Art. 33 RGPD: Notificación a Autoridad

Texto legal:

“En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente […] sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella.”

Contenido obligatorio notificación:

1. Naturaleza de la violación (qué datos afectados)
2. Nombre y datos contacto DPO
3. Consecuencias probables violación
4. Medidas adoptadas o propuestas para remediar
5. Si notificación excede 72h: Justificación retraso

Ejemplo notificación AEPD (formato):

NOTIFICACIÓN VIOLACIÓN SEGURIDAD DATOS PERSONALES
Fecha incidente: 15/01/2026 10:23 UTC
Fecha conocimiento: 15/01/2026 12:00 UTC
Fecha notificación: 17/01/2026 11:45 UTC (dentro plazo 72h)

1. NATURALEZA VIOLACIÓN:
   - Tipo: Acceso no autorizado + exfiltración datos
   - Vector: Explotación SQL injection portal clientes
   - Volumen: 45,000 registros afectados
   - Datos: Nombre, email, teléfono, dirección, IBAN parcial

2. CATEGORÍAS INTERESADOS AFECTADOS:
   - Clientes activos: 45,000 personas
   - Menores de edad: 0

3. CONSECUENCIAS PROBABLES:
   - Riesgo: ALTO (datos financieros parciales)
   - Phishing dirigido, fraude identidad, spam

4. MEDIDAS ADOPTADAS:
   - T+2h: Servidor vulnerable desconectado
   - T+6h: Parche aplicado (CVE-XXXX)
   - T+12h: Auditoría forense iniciada (peritos externos)
   - T+24h: Cambio contraseñas forzado todos los usuarios
   - T+48h: Notificación email a 45,000 afectados

5. MEDIDAS PREVISTAS:
   - Contratación SIEM (monitorización 24/7)
   - Pentesting externo trimestral
   - Formación empleados seguridad (phishing awareness)

DPO: [Nombre] - [Email] - [Teléfono]
Responsable: [Empresa SL] - CIF [XXX]

Art. 34 RGPD: Notificación a Afectados

Cuándo obligatorio:

“Cuando sea probable que la violación […] entrañe un alto riesgo para los derechos y libertades de las personas físicas, el responsable la comunicará al interesado sin dilación indebida.”

Factores que elevan el riesgo (la guía de la AEPD advierte que sus ejemplos no son reglas de aplicación general, sino factores a ponderar en conjunto):

• Datos financieros (cuentas bancarias, tarjetas)
• Datos de salud
• Datos de menores
• Datos sensibles (art. 9: origen étnico, religión, orientación sexual)
• Gran volumen de afectados (el número es un factor, no un umbral fijo)

Excepciones (no notificar a los afectados si):

1. Las medidas aplicadas hacen los datos ininteligibles —por ejemplo, cifrado con una implementación adecuada— y las claves no se han comprometido (el art. 34.3 no prescribe un algoritmo concreto: importan la implementación, las claves y el contexto)
2. Medidas posteriores hacen improbable el alto riesgo
3. La notificación individual exige un esfuerzo desproporcionado (entonces: comunicación pública)

Contenido notificación afectados:

Asunto: Notificación Importante: Incidente Seguridad Datos Personales

Estimado/a [Nombre]:

Le informamos de un incidente de seguridad ocurrido el 15/01/2026
que ha afectado a sus datos personales almacenados en nuestros sistemas.

DATOS AFECTADOS:
- Nombre completo, email, teléfono, dirección
- IBAN parcial (últimos 4 dígitos visibles)

CAUSA:
Acceso no autorizado a través de vulnerabilidad en nuestro portal web,
corregida inmediatamente tras detección.

RIESGOS:
- Phishing dirigido usando su nombre/email
- Posibles intentos fraude identidad

MEDIDAS ADOPTADAS POR NOSOTROS:
- Vulnerabilidad corregida
- Auditoría forense completa iniciada
- Mejoras seguridad implementadas
- Denuncia autoridades competentes

QUÉ DEBE HACER USTED:
1. Cambiar contraseña nuestra plataforma (obligatorio)
2. Revisar movimientos bancarios (IBAN expuesto parcialmente)
3. Desconfiar emails sospechosos mencionando este incidente
4. Activar alertas fraude en su banco

CONTACTO:
DPO: dpo@empresa.com | Tel: 900 XXX XXX
Más información: www.empresa.com/incidente-seguridad

Lamentamos sinceramente este incidente.
[Empresa SL]

Plan de Respuesta a Incidentes (IR): Primeras 72 Horas

Marco de referencia: ISO/IEC 27035-1:2023 y 27035-2:2023 y NIST SP 800-61 Rev. 3. Los tramos de horas, los plazos, la revisión anual, la formación periódica y el score que siguen son objetivos orientativos propuestos por el autor, adaptables al riesgo de cada organización; no son una receta literal de esas normas, que declaran que la guía se ajusta a cada caso.

Hora 0-2: Detección y Contención Inmediata

Script automatización contención (ejemplo Linux):

#!/bin/bash
# incident-response-contain.sh
# Ejecutar en servidor comprometido

INCIDENT_ID="IR-2026-001"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

echo "[+] Iniciando contención incidente $INCIDENT_ID"

# 1. Preservar evidencia volátil
echo "[+] Capturando memoria RAM..."
sudo insmod lime.ko "path=/forensics/ram_$TIMESTAMP.lime format=lime"

# 2. Capturar conexiones red activas
netstat -tulpn > /forensics/netstat_$TIMESTAMP.txt
ss -tulpn > /forensics/ss_$TIMESTAMP.txt

# 3. Listar procesos sospechosos
ps aux > /forensics/processes_$TIMESTAMP.txt
lsof > /forensics/open_files_$TIMESTAMP.txt

# 4. Exportar logs críticos
tar -czf /forensics/logs_$TIMESTAMP.tar.gz /var/log/

# 5. Bloquear acceso red (excepto IP forense)
FORENSIC_IP="203.0.113.10"
iptables -F
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT -s $FORENSIC_IP -j ACCEPT
iptables -A OUTPUT -d $FORENSIC_IP -j ACCEPT

echo "[+] Sistema aislado. Evidencia preservada en /forensics/"
echo "[+] SOLO acceso desde IP forense: $FORENSIC_IP"

# 6. Calcular hashes evidencia
sha256sum /forensics/* > /forensics/SHA256SUMS_$TIMESTAMP.txt

echo "[+] Contención completada. Contactar equipo forense."

Hora 2-12: Investigación Forense Inicial

Objetivos:

• Identificar vector entrada
• Alcance compromiso (sistemas, datos)
• Timeline ataque (primera intrusión hasta detección)
• Malware/herramientas usadas por atacante

Análisis logs SIEM:

import pandas as pd
from datetime import datetime, timedelta

# Cargar logs SIEM (formato genérico)
logs = pd.read_json("siem_logs.json")
logs['timestamp'] = pd.to_datetime(logs['timestamp'])

# Definir ventana análisis (7 días pre-detección)
detection_time = datetime(2026, 1, 15, 12, 0, 0)
analysis_start = detection_time - timedelta(days=7)

relevant_logs = logs[(logs['timestamp'] >= analysis_start) &
                     (logs['timestamp'] <= detection_time)]

# Buscar eventos sospechosos
suspicious_events = relevant_logs[
    (relevant_logs['event_type'].isin(['failed_login', 'privilege_escalation', 'file_access'])) |
    (relevant_logs['src_ip'].isin(KNOWN_MALICIOUS_IPS)) |
    (relevant_logs['user'].str.contains('admin|root|Administrator', na=False))
]

# Timeline construcción
timeline = suspicious_events.sort_values('timestamp')
print("=== TIMELINE INICIAL ===")
for _, event in timeline.iterrows():
    print(f"{event['timestamp']} | {event['src_ip']} | {event['event_type']} | {event['details']}")

# Identificar primera intrusión
first_suspicious = timeline.iloc[0]
print(f"\n[!] Primera actividad sospechosa: {first_suspicious['timestamp']}")
print(f"[!] IP origen: {first_suspicious['src_ip']}")
print(f"[!] Evento: {first_suspicious['event_type']}")

Identificación malware:

# Análisis binarios sospechosos
for file in /suspicious_files/*; do
    echo "Analizando: $file"

    # Hash
    sha256sum "$file"

    # Buscar en VirusTotal
    vt_hash=$(sha256sum "$file" | awk '{print $1}')
    curl -s "https://www.virustotal.com/api/v3/files/$vt_hash" \
         -H "x-apikey: YOUR_API_KEY" | jq '.data.attributes.last_analysis_stats'

    # Strings sospechosas
    strings "$file" | grep -i "password\|credential\|token\|api_key"

    # Análisis estático (si ejecutable)
    file "$file"
    ldd "$file"  # Dependencias
done

Hora 12-24: Erradicación y Recuperación

Hora 24-48: Notificación Legal (RGPD)

Notificación AEPD (dentro 72h desde conocimiento):

# Formulario notificación AEPD
notification_aepd = {
    "responsable": {
        "nombre": "Empresa Tecnología SL",
        "cif": "B12345678",
        "direccion": "Calle Principal 123, Madrid",
        "dpo_nombre": "María García",
        "dpo_email": "dpo@empresatech.com",
        "dpo_telefono": "+34 91 XXX XX XX"
    },
    "incidente": {
        "fecha_ocurrencia": "2026-01-15 10:23:00 UTC",
        "fecha_conocimiento": "2026-01-15 12:00:00 UTC",
        "fecha_notificacion": "2026-01-17 11:45:00 UTC",  # Dentro 72h
        "tipo": "Acceso no autorizado + exfiltración",
        "vector": "Explotación SQL injection",
        "numero_afectados": 45000,
        "categorias_datos": [
            "Identificativos (nombre, email, teléfono)",
            "Ubicación (dirección postal)",
            "Financieros (IBAN parcial, últimos 4 dígitos)"
        ],
        "menores_afectados": False
    },
    "riesgo": {
        "nivel": "ALTO",
        "justificacion": "Datos financieros parciales expuestos, riesgo fraude identidad",
        "consecuencias_probables": [
            "Phishing dirigido",
            "Fraude identidad",
            "Spam/llamadas comerciales no solicitadas"
        ]
    },
    "medidas": {
        "inmediatas": [
            "Servidor vulnerable aislado y parcheado (T+2h)",
            "Credenciales todos los usuarios cambiadas (T+24h)",
            "Auditoría forense iniciada (perito externo)",
            "Notificación 45,000 afectados programada (T+36h)"
        ],
        "futuras": [
            "Implementación SIEM con monitorización 24/7",
            "Pentesting trimestral externo",
            "Formación empleados (phishing awareness)",
            "Implementación MFA obligatorio"
        ]
    }
}

# Notificar a la AEPD por su Sede Electronica (formulario de notificacion de brechas)
# https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-datos-personales-notificacion

Notificación afectados (email masivo):

• Envío progresivo (no colapsar servidores email)
• Idioma claro, no tecnicismos
• Instrucciones accionables (qué hacer)
• Contacto DPO disponible

Hora 48-72: Comunicación Externa y Monitorización

Comunicación pública (si procede):

## COMUNICADO OFICIAL: INCIDENTE SEGURIDAD DATOS

**Madrid, 17 enero 2026**

Empresa Tecnología SL informa que el 15 de enero de 2026 detectamos un
acceso no autorizado a nuestros sistemas que afectó a datos de 45,000 clientes.

DATOS AFECTADOS:
Nombre, email, teléfono, dirección postal, IBAN parcial (últimos 4 dígitos).

MEDIDAS ADOPTADAS:
- Vulnerabilidad corregida inmediatamente
- Notificación AEPD (dentro plazo 72h legal)
- Notificación individual a los 45,000 afectados
- Auditoría forense completa por peritos externos
- Mejoras seguridad implementadas (MFA, SIEM 24/7)

RECOMENDACIONES CLIENTES:
- Cambiar contraseña en nuestra plataforma (obligatorio)
- Revisar movimientos bancarios
- Desconfiar emails sospechosos

TRANSPARENCIA:
Informe forense completo se publicará en 30 días (tras investigación).

CONTACTO:
DPO: dpo@empresatech.com | Tel: 900 XXX XXX
Información: www.empresatech.com/incidente-seguridad

Lamentamos sinceramente este incidente y trabajamos para garantizar que
no vuelva a ocurrir.

[Firma CEO]

Monitorización post-incidente (90 días):

• Dark web monitoring (¿datos vendidos?)
• Phishing campaigns usando datos brecha (informar afectados)
• Intentos acceso anormales (IPs sospechosas)
• Quejas/reportes clientes (fraude identidad)

Lecciones Aprendidas: Casos México → España

Error #1: comunicación tardía y reactiva

Lección España:

• ✅ Notificar AEPD en 72h es LAW, no opcional
• ✅ Comunicación proactiva genera confianza (vs reactiva pierde credibilidad)
• ✅ Transparencia reduce pánico (vs opacidad aumenta especulación)

Escenario ilustrativo: una empresa de retail sufre una brecha que afecta a su base de clientes. Notifica a la AEPD y comunica a los afectados dentro de las primeras 24 horas, con instrucciones claras. Una respuesta rápida y transparente reduce las reclamaciones y protege la reputación mucho mejor que el silencio. (Escenario construido sobre la práctica habitual; no describe un expediente concreto.)

Error #2: Sin Plan IR Pre-Definido

Lección España:

• ✅ Documento IR escrito ANTES de brecha (no improvisar)
• ✅ Roles definidos (quién hace qué, contactos)
• ✅ Simulacros anuales (tabletop exercises)

Plantilla Plan IR básico:

# PLAN RESPUESTA INCIDENTES SEGURIDAD

## 1. EQUIPO RESPUESTA

| Rol | Persona | Tel | Email |
|-----|---------|-----|-------|
| IR Lead | María García | +34 6XX XXX XXX | maria@empresa.com |
| CISO | Juan Pérez | +34 6XX XXX XXX | juan@empresa.com |
| DPO | Ana López | +34 6XX XXX XXX | ana@empresa.com |
| Forense Externo | Perito XYZ | +34 6XX XXX XXX | perito@xyz.com |
| Legal | Abogado ABC | +34 9XX XXX XXX | abogado@abc.com |

## 2. CONTACTOS EXTERNOS

- AEPD: https://www.aepd.es/ | 900 293 183
- INCIBE-CERT: https://www.incibe-cert.es/ | 017
- Policía Nacional BCIT: 091
- Hosting provider: [Contacto]
- Seguro ciberriesgo: [Póliza] [Contacto]

## 3. CHECKLIST PRIMERAS 2 HORAS

- [ ] Confirmar brecha (vs falso positivo)
- [ ] Activar equipo IR (llamadas simultáneas)
- [ ] Aislar sistemas comprometidos
- [ ] Preservar evidencia (imágenes forenses, logs)
- [ ] Contactar perito forense externo
- [ ] Iniciar cronómetro 72h (notificación AEPD)

## 4. CHECKLIST 2-24 HORAS

- [ ] Investigación forense inicial (vector, alcance)
- [ ] Erradicar persistencia atacante
- [ ] Parchear vulnerabilidades explotadas
- [ ] Rotación credenciales masiva
- [ ] Preparar notificación AEPD (borrador)
- [ ] Preparar notificación afectados (borrador)

## 5. CHECKLIST 24-72 HORAS

- [ ] Notificar AEPD (obligatorio dentro 72h)
- [ ] Notificar afectados (si alto riesgo)
- [ ] Comunicado público (si procede)
- [ ] Denuncia Policía Nacional (si delito)
- [ ] Contactar seguro ciberriesgo (cobertura)

## 6. POST-INCIDENTE (7-30 DÍAS)

- [ ] Informe forense completo
- [ ] Lessons learned document
- [ ] Mejoras seguridad implementadas
- [ ] Simulacro IR actualizado
- [ ] Auditoría externa seguridad

Error #3: No Preservación Evidencia Forense

Lección España:

• ✅ Evitar apagar siempre que se pueda (apagar pierde la RAM y las conexiones activas); si no hay más remedio para frenar la propagación, apagar y documentar la pérdida de evidencia volátil
• ✅ Imágenes forenses INMEDIATAMENTE (antes manipulación)
• ✅ Cadena custodia documentada (hashes, timestamps, responsables)

Escenario ilustrativo: una empresa apaga sus servidores al detectar ransomware; al perderse la memoria, resulta mucho más difícil analizar el malware y reconstruir lo ocurrido para una denuncia. Por eso la contención se hace, siempre que se pueda, aislando sin apagar. (Escenario ilustrativo, no un caso concreto.)

Preguntas Frecuentes

¿Cuánto tiempo tengo para notificar una brecha a la AEPD?

72 horas MÁXIMO desde que tienes «constancia» de la brecha (art. 33 RGPD). Según la guía EDPB 9/2022, hay «constancia» cuando el responsable alcanza un grado razonable de certeza de que ha ocurrido una violación que comprometió datos personales; se admite un breve periodo de investigación inicial para llegar a esa certeza.

Ejemplo: si el lunes salta una alerta técnica ambigua y el martes confirmas que hubo una violación que afectó a datos personales, el plazo no arranca automáticamente el lunes: arranca cuando alcanzas ese grado razonable de certeza. Una alerta aislada puede justificar una investigación breve antes de que empiece a contar.

Si excedes 72h: Debes justificar retraso en notificación. Penalización: discrecional AEPD (hasta €10M o 2% facturación).

¿Siempre debo notificar a los afectados?

NO siempre. Solo si brecha “entrañe alto riesgo” para derechos/libertades (Art. 34 RGPD).

Alto riesgo incluye:

• Datos financieros (cuentas, tarjetas)
• Datos salud
• Menores de edad
• Datos sensibles (Art. 9: religión, orientación sexual, etc.)
• Gran volumen de afectados (es un factor a ponderar junto con la naturaleza de los datos, no un umbral automático)

Excepciones (no notificar):

1. Medidas que hacen los datos ininteligibles (p. ej. cifrado con implementación adecuada) y clave no comprometida
2. Medidas posteriores eliminan alto riesgo
3. Esfuerzo desproporcionado (entonces: comunicación pública)

Consultar DPO siempre para evaluar riesgo caso por caso.

¿Qué multa puedo recibir por no notificar una brecha bajo el RGPD?

La falta de notificación es una infracción del art. 33, que va por el art. 83.4.a: hasta 10 millones de euros o el 2 % del volumen de negocio global, el que sea mayor. El tramo de 20 millones o el 4 % del art. 83.5 corresponde a infracciones más graves —los principios del tratamiento, los derechos de los interesados—, que un incidente puede arrastrar además de la falta de notificación.

La cuantía concreta se gradúa con los criterios del art. 83.2: naturaleza, gravedad y duración de la infracción, intencionalidad o negligencia, número de afectados y perjuicio causado, medidas de seguridad adoptadas y grado de cooperación con la Agencia.

Antes de atribuir una cifra concreta de sanción a un caso, conviene comprobar el importe y el motivo exactos en el buscador de resoluciones de la AEPD: los totales que circulan a veces suman varias resoluciones de asuntos distintos.

¿Necesito contratar un perito forense para brechas?

NO obligatorio legalmente, pero ALTAMENTE RECOMENDADO:

Ventajas perito externo:

• ✅ Independencia (credibilidad ante AEPD/tribunales)
• ✅ Experiencia especializada (no improvisas)
• ✅ Preservación evidencia profesional (cadena custodia válida)
• ✅ Informe pericial aceptado judicialmente
• ✅ Defensa ante auditorías AEPD

Cuándo es especialmente aconsejable (no es una obligación legal general):

• Cuando se va a interponer una denuncia penal y conviene una preservación y un análisis sólidos (la denuncia en sí puede hacerse por escrito o de palabra, sin informe pericial — art. 265 LECrim)
• Ante una auditoría o requerimiento de la AEPD, donde un análisis independiente refuerza la posición
• Cuando la póliza de ciberriesgo lo exija: hay que comprobarlo en el condicionado concreto, no darlo por supuesto

Coste: depende de la complejidad del caso y se presupuesta de forma individual. Frente a ese coste, la falta de notificación de una brecha puede sancionarse con hasta 10 M€ o el 2 % del volumen de negocio global (art. 83.4 RGPD).

¿Qué hago si no tengo plan de respuesta a incidentes?

Crear uno AHORA (antes de brecha):

Tiempo de creación: unas pocas horas de trabajo, una inversión mínima frente a improvisar en plena crisis.

Alternativa: contratar una consultoría especializada que elabore el plan y forme al equipo (se presupuesta según el alcance).

¿Cómo saber si mi empresa está preparada para una brecha?

Checklist preparación (10 preguntas críticas):

• ✅ ¿Tenemos plan IR escrito y actualizado?
• ✅ ¿Equipo IR conoce sus roles y tiene contactos actualizados?
• ✅ ¿Realizamos simulacros IR anuales?
• ✅ ¿Tenemos backups offline/offsite (3-2-1 rule)?
• ✅ ¿Backups testeados regularmente (podemos restaurar)?
• ✅ ¿SIEM/EDR activo con alertas monitorizadas 24/7?
• ✅ ¿Segmentación red (VLANs, firewalls internos)?
• ✅ ¿MFA activado para todos los usuarios?
• ✅ ¿Formación empleados (phishing awareness) trimestral?
• ✅ ¿Seguro ciberriesgo contratado?

Score:

• 8-10 ✅: Bien preparado
• 5-7 ⚠️: Preparación media (mejorar)
• 0-4 ❌: Vulnerable (urgente actuar)

¿El seguro ciberriesgo cubre multas RGPD?

Depende de la póliza. Muchas cubren los costes de respuesta, pero no siempre las multas regulatorias; hay que comprobarlo en el condicionado.

Coberturas que suelen incluirse (según póliza):

• ✅ Costes investigación forense
• ✅ Notificaciones afectados (envío emails, call center)
• ✅ Monitorización crédito afectados (1-2 años)
• ✅ Relaciones públicas (gestión crisis)
• ✅ Asesoría legal especializada
• ✅ Recuperación sistemas (restauración backups)

Exclusiones frecuentes (según póliza):

• ❌ Multas RGPD (Art. 83) - consideradas “no asegurables” por muchas aseguradoras
• ❌ Pérdida ingresos (downtime), salvo extensión específica
• ❌ Ransomware (pago rescate), salvo cobertura adicional

Verifica el condicionado de tu póliza antes de una brecha: qué cubre, con qué límites y qué excluye. El coste varía mucho según la cobertura y el perfil de riesgo.

¿Puedo ser responsable personalmente (CEO/CISO) por brecha?

SÍ, potencialmente:

Responsabilidad penal. Aquí hay que deshacer una confusión frecuente: el art. 197 del Código Penal —descubrimiento y revelación de secretos— castiga a quien se apodera de los datos sin autorización para vulnerar la intimidad de otro, es decir, al atacante. Es un delito doloso, y no alcanza al responsable de la empresa que sufre la brecha por no haber protegido bien los sistemas: la mera negligencia en la seguridad no es delito del 197. La vía penal contra el atacante existe y es importante para la denuncia, pero no es una responsabilidad que recaiga sobre el CEO por el hecho de ser víctima.

Responsabilidad civil (CEO/Administradores):

• Acción social de responsabilidad (LSC Art. 236-241)
• Reclamación daños causados por falta diligencia
• Cuantía: Pérdidas empresa + multas RGPD

Protección:

• ✅ Demostrar diligencia debida (auditorías, formación, inversión seguridad)
• ✅ Documentar decisiones (comités, actas)
• ✅ Seguir estándares reconocidos (ISO 27001, ENS)
• ✅ Seguro D&O (Directors & Officers), cuya cobertura de la responsabilidad personal depende del condicionado concreto

Lo que sí existe, y por otra vía, es la responsabilidad por decisiones tomadas alrededor de la brecha: en el conocido caso de Equifax (2017), la brecha derivó en la salida de varios directivos, y un antiguo responsable fue condenado por uso de información privilegiada —haber vendido acciones antes de que la brecha se hiciera pública—, que es un delito distinto de la brecha en sí y ejemplifica bien la diferencia.

Conclusión

El episodio de México de enero de 2026 sirve para repasar los errores clásicos de respuesta a incidentes que cualquier organización debe evitar: el silencio inicial, la ausencia de un plan IR, la falta de preservación de la evidencia y la comunicación reactiva. En España, algunos de esos fallos —el silencio, la falta de notificación en plazo— son infracciones del RGPD con sanciones que, según el precepto incumplido, alcanzan el tramo del art. 83.4 (10 M€ o 2 %) o el del 83.5 (20 M€ o 4 %).

Para empresas españolas: un plan de respuesta a incidentes no es opcional. El art. 33 del RGPD impone la notificación a la AEPD en 72 horas y el art. 34 la comunicación a los afectados cuando el riesgo es alto. Tener el plan escrito, el equipo definido y un perito de contacto acordado antes del incidente cuesta una fracción de lo que cuesta improvisar en plena crisis — no solo en una eventual sanción, sino en el tramo del incidente que se pierde por no saber qué hacer en las primeras horas.

Las primeras 72 horas marcan el resto: preservación de la evidencia (perito forense externo), contención efectiva (aislar y, salvo riesgo de propagación, no apagar los sistemas), notificación legal (AEPD y afectados) y comunicación transparente y proactiva.

Checklist preparación mínima: Plan IR escrito, equipo definido, simulacros anuales, backups offline 3-2-1, SIEM activo, MFA universal, seguro ciberriesgo, contacto perito externo pre-negociado.

Recomendación final: Si aún no tienes plan IR, crear HOY (4-8h inversión mínima). Si ocurre una brecha: el cronómetro de 72 horas arranca cuando alcanzas un grado razonable de certeza de que hubo una violación de datos personales (se admite una investigación inicial breve). Contacta de inmediato con un perito forense y un abogado especializado.

Para una empresa española, la lección no está en la geografía sino en la preparación: el RGPD exige un estándar alto de respuesta y notificación, y cumplirlo no es solo una obligación legal, sino parte de la continuidad del negocio.

Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en respuesta a incidentes y en el análisis de brechas bajo el RGPD. Ex-CTO y arquitecto cloud con más de 20 años en el sector tecnológico y 5 certificaciones AWS, ejerce como perito judicial desde 2025 y aplica metodología ISO 27037 en todas sus investigaciones.

Última actualización: 7 de septiembre de 2026

Referencias y fuentes

• Boletín UNAM-DGCS-011, 7 de enero de 2026 — comunicado oficial de la UNAM sobre el incidente
• Proposición del Senado, 4 de febrero de 2026 — califica de presunto el hackeo a sistemas del gobierno federal
• Guía EDPB 9/2022 — notificación de brechas: cuándo hay «constancia»
• RGPD — Artículo 33: notificación de brechas a la AEPD en 72 horas máximo
• RGPD — Artículo 34: notificación a afectados sin dilación indebida si alto riesgo
• RGPD, art. 83.4 — la falta de notificación de una brecha (art. 33) se sanciona con hasta 10 M€ o el 2 % del volumen global; el art. 83.5 reserva el tramo de 20 M€ o el 4 % a la vulneración de los principios del tratamiento y de los derechos de los interesados. EUR-Lex
• AEPD — Notificación de brechas de datos personales a la Autoridad de Control — separa la guía y el formulario electrónico de la Sede; ver también la Guía para la notificación de brechas
• LFPDPPP (para sujetos privados) y LGPDPPSO (para el sector público, aplicable a la UNAM y a las dependencias del gobierno) — marco mexicano comparado con el RGPD
• ISO/IEC 27035-1:2023 e ISO/IEC 27035-2:2023 — gestión de incidentes de seguridad de la información (la norma monolítica 27035:2011 está retirada)
• NIST SP 800-61 Rev. 3 — respuesta a incidentes; sustituye desde abril de 2025 a la Rev. 2
• INCIBE-CERT — CERT de referencia para ciudadanos y empresas en España
• Código Penal, art. 197 — descubrimiento y revelación de secretos: es el delito doloso que comete quien accede a los datos sin autorización (el atacante), no la empresa que sufre la brecha
• Ley de Sociedades de Capital, artículos 236-241 — Responsabilidad civil de administradores