Brecha de datos (data breach)

Brecha de datos (data breach)

72 horas. Ese es el plazo máximo que el artículo 33 del RGPD concede para notificar a la AEPD una brecha de datos personales cuando la notificación es exigible, contadas desde que el responsable tuvo conocimiento de ella — no desde que terminó de investigarla. No toda brecha se notifica: el propio art. 33.1 exceptúa aquella para la que sea improbable que constituya un riesgo para los derechos y libertades de las personas.

Determinar y documentar ese momento puede ser decisivo para acreditar que la notificación se hizo en plazo, y es donde entra el peritaje: acreditar en qué instante exacto la organización supo que había una brecha. La Memoria anual 2023 de la AEPD recoge 2.004 brechas notificadas en el año —un 10 % más que en 2022, y unas dos terceras partes de las 2.933 que llegarían en 2024—, de las que 16 se derivaron a la Subdirección de Inspección de Datos y en 30 el responsable quedó obligado a comunicar el incidente a los afectados.

Definición Técnica

Brecha de datos (data breach) es una violación de seguridad que compromete la confidencialidad, disponibilidad o integridad de datos personales, ya sea por acceso no autorizado, destrucción accidental, pérdida, alteración o divulgación no consentida.

Marco legal:

• RGPD Artículo 4(12): Define “violación de seguridad de los datos personales”
• RGPD Artículo 33: Notificación a autoridad control (AEPD España) en 72 horas
• RGPD Artículo 34: Comunicación afectados “sin dilación indebida” si alto riesgo

Tipos de brechas (clasificación AEPD):

1. CONFIDENCIALIDAD (Breach of Confidentiality):
   Acceso/divulgación no autorizados datos personales
   Ejemplos: Hacking, phishing, empleado malicioso

2. DISPONIBILIDAD (Breach of Availability):
   Pérdida acceso datos (temporal/permanente)
   Ejemplos: Ransomware, borrado accidental, fallo hardware

3. INTEGRIDAD (Breach of Integrity):
   Alteración no autorizada datos personales
   Ejemplos: Modificación registros médicos, falsificación datos

Datos especialmente sensibles (categorías especiales art. 9 RGPD):

• Salud (historiales médicos, recetas, diagnósticos)
• Origen racial/étnico
• Opiniones políticas
• Creencias religiosas/filosóficas
• Afiliación sindical
• Datos genéticos/biométricos
• Orientación sexual
• Que la brecha afecte a estas categorías es uno de los factores que se valoran al graduar una eventual sanción (art. 83.2.g RGPD). El reglamento no fija ningún incremento porcentual automático, y las directrices 04/2022 del CEPD sobre el cálculo de las multas dicen expresamente que los aumentos o reducciones «no pueden predeterminarse mediante tablas o porcentajes»

Umbrales notificación AEPD: El responsable notifica cuando sea probable que la brecha constituya un riesgo para los derechos y libertades de las personas. Si concluye que ese riesgo es improbable, no notifica, pero documenta la brecha, la valoración y las medidas adoptadas (art. 33.5).

Ningún algoritmo funciona como salvoconducto. El cifrado robusto, la custodia de la clave, la autenticación, la existencia de copias de seguridad y las demás circunstancias se valoran en conjunto; y la seudonimización reduce el riesgo pero no exime, porque por definición permite atribuir los datos «utilizando información adicional» (art. 4.5 RGPD).

La AEPD recomienda notificar, en línea con los principios de proactividad y transparencia, cuando subsista la duda tras la evaluación. Eso no sustituye al análisis de riesgo ni implica que la sanción por no notificar sea siempre mayor que la de notificar de más: esa comparación no la publica ninguna fuente.

Timeline notificación RGPD: artículos 33 y 34

Artículo 33 RGPD: Notificación AEPD (72 horas)

Plazo: Máximo 72 horas desde que el responsable tuvo conocimiento de la brecha

“Conocimiento” (interpretación AEPD):

Momento conocimiento = cuando responsable tiene información suficiente para:
  1. Confirmar incidente seguridad ocurrió
  2. Datos personales están involucrados

NO es necesario:
  ❌ Investigación completa
  ❌ Conocer número exacto afectados
  ❌ Identificar causa raíz

Ejemplo:
  Lunes 09:00h: SOC detecta acceso no autorizado servidor
  Lunes 11:30h: Confirma servidor contiene BBDD clientes (120K registros)
  → Conocimiento: Lunes 11:30h
  → Plazo notificación: Jueves 11:30h (72h después)

Contenido mínimo notificación (art. 33.3):

1. Naturaleza violación:
   "Acceso no autorizado base datos clientes vía SQL Injection"

2. Contacto DPO (Delegado Protección Datos):
   Nombre, email, teléfono

3. Consecuencias probables:
   "Exposición datos personales (nombre, DNI, email, teléfono).
    Riesgo phishing, suplantación identidad."

4. Medidas adoptadas/propuestas:
   "Vulnerabilidad parcheada, contraseñas reseteadas, monitorización reforzada."

Las categorías y el número aproximado de afectados y de registros forman parte del primer elemento, no de un quinto: el art. 33.3 tiene cuatro letras. Si no es posible facilitar toda la información a la vez, el art. 33.4 permite aportarla de manera gradual, sin dilación indebida. La guía de la AEPD de junio de 2021 prevé, con carácter general, completar una notificación inicial dentro de los 30 días siguientes.

Notificación tardía (mayor de 72h): Es el art. 33.1 —no el 33.4— el que exige que una notificación presentada después de 72 horas «vaya acompañada de indicación de los motivos de la dilación». El art. 33.4 regula otra cosa: la entrega gradual de la información que no pueda aportarse de una vez.

La AEPD no publica una lista de motivos aceptados y vetados de antemano. Su formulario pide indicar el motivo real y ofrece categorías, entre ellas que el plazo de 72 horas expirase «fuera de la jornada laboral, fin de semana o períodos de vacaciones», junto a problemas en los medios técnicos, una valoración inicial de que el incidente no era notificable, demoras del procedimiento o la necesidad de no interferir en una investigación policial o judicial. Indicar el motivo no elimina el incumplimiento: permite valorarlo.

Artículo 34 RGPD: Comunicación Afectados

La brecha se comunica a las personas afectadas cuando, tras valorar la naturaleza del incidente, las categorías de datos, el volumen, la facilidad de identificación, las consecuencias y los colectivos implicados, sea probable un alto riesgo para sus derechos y libertades (art. 34.1). Las categorías especiales, los datos financieros, las credenciales y el número de afectados son factores de esa evaluación, no umbrales: ni el RGPD ni la AEPD fijan una frontera automática en 10.000 personas ni en ninguna otra cifra.

NO obligatorio SI:
  ❌ Medidas técnicas que hagan los datos ininteligibles para
     quien no esté autorizado (art. 34.3.a) — no basta con
     que estén «cifrados»
  ❌ Medidas inmediatas eliminan riesgo
  ❌ Comunicación supondría esfuerzo desproporcionado
      → Alternativa: Comunicación pública equivalente

Contenido comunicación afectados (art. 34.2):

1. Naturaleza brecha (lenguaje claro, NO técnico):
   ❌ "Exfiltración datos vía SQLi en endpoint REST API"
   ✅ "Acceso no autorizado a información personal de clientes"

2. Contacto DPO:
   Email, teléfono (canal consultas afectados)

3. Consecuencias probables:
   "Sus datos (nombre, DNI, email) pueden ser usados para:
    - Intentos phishing (emails fraudulentos)
    - Llamadas suplantación identidad"

4. Medidas recomendadas afectados:
   ✅ "Cambiar contraseña inmediatamente"
   ✅ "Vigilar movimientos bancarios sospechosos"
   ✅ "No responder emails solicitando datos personales"
   ✅ "Denunciar fraudes a Policía Nacional"

5. Medidas adoptadas responsable:
   "Hemos parcheado vulnerabilidad, reforzado monitorización,
    ofrecemos servicio monitorización identidad 12 meses gratis."

Plazo de comunicación: «sin dilación indebida» y, cuando el riesgo sea alto, a la mayor brevedad posible. La guía de la AEPD es explícita en que el RGPD «no establece un plazo concreto» para comunicar a los afectados. Cualquier retraso debe justificarse.

Análisis forense brecha datos: detección, timeline, evidencias

Fase 1: Detección (MTTR: Mean Time To Respond)

Métodos detección:

1. Monitorización SIEM (Security Information Event Management):

Alertas típicas brecha datos:

SQL Injection:
  - Patrón: SELECT * FROM users WHERE id='1' OR '1'='1'
  - Log: Web server error "SQL syntax error near 'OR'"
  - Volumen: 1,200+ queries similares en 15 min

Data exfiltration:
  - Tráfico saliente inusual: 50 GB en 2 horas (baseline: 2 GB/día)
  - Destino: IP extranjera (ej: Rusia, China, Tor exit nodes)
  - Puerto: 443 (HTTPS) o 9050 (Tor)

Acceso no autorizado:
  - Autenticación éxito cuenta admin (IP desconocida)
  - Geolocalización anómala (usuario España, login desde Nigeria)
  - Horario: 03:47h (fuera horario laboral)

2. Notificación externa:

Investigador seguridad (Responsible Disclosure):
  "He detectado vulnerabilidad IDOR permite acceder expedientes ajenos.
   PoC adjunto. Por favor, parchear en menor de 72h."

Cliente afectado:
  "He recibido email phishing con mis datos personales exactos
   (DNI, dirección, número cuenta). ¿De dónde los han sacado?"

Publicación darknet:
  BBDD empresa aparece venta en RaidForums successor
  Muestra: 1,000 registros (evidencia brecha)

3. Auditoría interna/externa:

Pentesting anual detecta:
  - Vulnerabilidad SQLi en formulario contacto
  - Logs revelan explotación previa (6 meses antes)
  - Evidencia exfiltración datos (traffic analysis)

Fase 2: Contención y Análisis Forense

Timeline investigación forense:

T+0h (Detección):
  SOC detecta anomalía

T+2h (Confirmación):
  ✅ Incidente seguridad confirmado
  ✅ Datos personales involucrados
  → INICIO plazo 72h notificación AEPD

T+4h (Contención inmediata):
  - Aislamiento sistema comprometido (offline)
  - Bloqueo cuentas comprometidas
  - Cambio credenciales administrador
  - Captura memoria RAM (análisis forense volátil)

T+12h (Análisis forense):
  - Adquisición forense discos (imagen dd)
  - Análisis logs (web server, base datos, firewall)
  - Timeline reconstrucción (primer acceso → exfiltración)
  - Identificación vector ataque (SQLi, phishing, credenciales robadas)

T+24h (Cuantificación):
  - Número registros comprometidos (SQL query logs)
  - Tipo datos afectados (DNI, salud, financieros)
  - Identificación afectados (list emails)

T+48h (Notificación AEPD):
  Envío formulario notificación (dentro 72h)

T+72h (Información complementaria — decisión operativa de este
       escenario, no un hito que fije el RGPD):
  Detalles adicionales del análisis forense

Comunicación a los afectados, si procede:
  Sin dilación indebida y, si el riesgo es alto, a la mayor
  brevedad posible. Email/SMS/carta postal según gravedad

Evidencias Forenses Clave

1. Logs acceso web:

## Detectar SQLi (pattern matching)
$ grep -E "(UNION SELECT|OR 1=1|' OR ')" /var/log/apache2/access.log
203.0.113.42 - - [15/Jan/2026:14:23:17] "GET /users?id=1' OR '1'='1" 200 14782

## Cuantificar queries sospechosas
$ grep "OR 1=1" access.log | wc -l
1,847 queries maliciosas (período 3h 12min)

## Identificar IP atacante
$ awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -5
1847 203.0.113.42  (dirección de documentación, RFC 5737)
  23 198.51.100.7   (dirección de documentación, RFC 5737)
  12 192.168.1.50    (Interno, admin)

2. Logs base datos:

-- Queries ejecutadas IP atacante (MySQL general_log)
SELECT * FROM users WHERE id=1;  -- Prueba inicial
SELECT * FROM users WHERE id=1 UNION SELECT null,username,password,null FROM admins;  -- SQLi
SELECT * FROM users INTO OUTFILE '/tmp/users_dump.csv';  -- Volcado local en el propio servidor: posible staging, no prueba de salida

3. Tráfico red (captura paquetes):

## Detectar exfiltración datos (volumen anómalo)
$ tshark -r capture.pcap -qz io,stat,3600
| Interval |  Bytes  |
|    0-1h  |  450 MB |  ← Normal
|    1-2h  |   12 GB |  ← Exfiltración!!!
|    2-3h  |  520 MB |

## Identificar destino exfiltración
$ tshark -r capture.pcap -Y "ip.dst != 10.0.0.0/8" -T fields -e ip.dst | sort | uniq -c
3247 203.0.113.42  (dirección de documentación, RFC 5737)
 412 1.1.1.1          (Cloudflare DNS: legítimo)

4. Archivos temporales:

## Dump base datos generado atacante
$ ls -lh /tmp/users_dump.csv
-rw-r--r-- 1 www-data www-data 2.3G Jan 15 14:47 users_dump.csv

$ wc -l users_dump.csv
127,492 registros (clientes afectados)

## Hash forense (integridad evidencia)
$ sha256sum users_dump.csv
a4f8d2e1... users_dump.csv

Cómo consultar sanciones reales de la AEPD

Las resoluciones sancionadoras de la Agencia son públicas y consultables una a una, y esa es la única fuente válida para citar un importe o un plazo concreto: cada una lleva número de expediente, hechos probados y cuantía motivada.

• Buscador de resoluciones de la AEPD — permite filtrar por artículo del RGPD infringido
• Memoria anual 2023 — más de 2.000 brechas notificadas, 16 derivadas a la Subdirección de Inspección de Datos y 30 con comunicación obligatoria a los afectados

Lo que sí puede afirmarse sin resolución concreta delante es el marco: el artículo 33 del RGPD obliga a notificar sin dilación indebida y, de ser posible, en 72 horas desde que se tuvo conocimiento de la brecha; y en España la falta de notificación se tipifica como infracción grave en el art. 73.r de la LOPDGDD, mientras que la notificación «incompleta, tardía o defectuosa» es leve por el art. 74.m. El art. 83 del RGPD no reparte esas etiquetas: fija condiciones y tramos, y las multas por incumplir los arts. 33 y 34 caen en el del art. 83.4 —hasta 10 millones de euros o el 2 % del volumen de negocio global anual, la mayor de las dos cuantías—, no en el de 20 millones o el 4 %.

Rol perito informático forense en brechas datos

Servicios Periciales

1. Análisis forense post-brecha (urgente 72h):

Contratación: Dentro primeras 12h detección (antes notificación AEPD)

Objetivos:
  ✅ Confirmar brecha ocurrió (evidencia técnica)
  ✅ Identificar vector ataque (SQLi, phishing, IDOR)
  ✅ Cuantificar alcance (número registros, tipo datos)
  ✅ Timeline completo (primer acceso → exfiltración)
  ✅ Informe técnico AEPD (anexo notificación art. 33)

El alcance y el plazo dependen del número de sistemas implicados, del
volumen de registros y de la disponibilidad de los logs. Se presupuesta
caso por caso.

2. Peritaje judicial sanciones AEPD:

Contratación: Cuando empresa impugna sanción AEPD

Perito defiende:
  ✅ Retraso notificación justificado (complejidad técnica)
  ✅ Medidas seguridad eran adecuadas (no negligencia)
  ✅ Cuantificación daños (proporcionalidad sanción)

Lo que el perito acredita es técnico: cuántos sistemas resultaron
afectados, qué volumen de registros hubo que analizar y por qué ese
análisis no podía completarse antes. Si el retraso estaba o no
justificado, y con qué consecuencia sobre la cuantía, lo decide la
Agencia o el tribunal, y solo se puede citar con la resolución delante:
número de expediente o de sentencia, órgano, fecha y ROJ o ECLI.

3. Auditoría preventiva (evitar brechas):

Servicios:
  ✅ Pentesting aplicaciones web (OWASP Top 10)
  ✅ Auditoría configuración servidores/BBDD
  ✅ Revisión procedimientos notificación (art. 33/34)
  ✅ Simulacros brecha datos (tabletop exercises)

Beneficio: reducir la probabilidad y el impacto de un incidente, no
eliminarlos. El alcance se dimensiona según el número de aplicaciones,
servidores y procedimientos a revisar.

4. Testigo experto litigios civiles:

Contexto: Afectados demandan empresa por daños brecha

Perito calcula daños:
  - Tiempo dedicado por los afectados a gestiones y denuncias
  - Daño patrimonial acreditable (fraudes derivados de la brecha)
  - Elementos objetivos que permitan valorar el daño moral

No existe una tarifa jurisprudencial por persona. El TJUE exige tres
requisitos acumulativos —infracción, daño material o inmaterial y nexo
causal (C-300/21, Österreichische Post)— y deja la cuantificación al
derecho nacional: la mera infracción del RGPD no genera por sí sola
derecho a indemnización.

Cuánto cuesta una brecha de datos

No existe una cifra fiable del coste de una brecha para una empresa española que pueda darse como dato de presupuesto: ninguna medición pública ofrece muestra, año, moneda y método aplicables a ese universo. Lo que sí puede afirmarse:

• No se ha localizado una media pública específica para pymes españolas. El coste depende del tamaño, el sector, la interrupción del servicio, los datos afectados, la rapidez de la respuesta, las reclamaciones civiles y una eventual sanción.
• Como referencia internacional no trasladable automáticamente a España, IBM sitúa en 4,99 millones de dólares el promedio global de su muestra en el Cost of a Data Breach Report 2026. Es una media mundial de grandes organizaciones, en dólares, y no dice nada sobre una pyme española.
• Sobre el volumen sancionador, la AEPD publica agregados, no distribuciones: informó de que en 2025 los procedimientos sancionadores o de apercibimiento relacionados con brechas pasaron de 30 en 2024 a 77 en 2025, con 19.836.603 € en sanciones. Esos dos números no permiten calcular una mediana ni percentiles de las multas individuales.

FAQ

P: ¿Qué es exactamente una brecha de datos según RGPD? R: Cualquier incidente seguridad que compromete confidencialidad (acceso no autorizado), disponibilidad (pérdida acceso), o integridad (alteración) de datos personales. Incluye: hacking, ransomware, empleado malicioso, pérdida portátil sin cifrar, email a destinatario equivocado con datos personales.

P: ¿Tengo que notificar AEPD si pierdo un USB con datos? R: la pérdida es una brecha y hay que registrarla y evaluarla en todo caso. Sobre si además se notifica, la AEPD indica que podría no ser necesario cuando concurren varias condiciones a la vez: que el soporte esté cifrado con un algoritmo criptográficamente fuerte, que la clave sea robusta y no esté comprometida, que exista copia de seguridad y que el único riesgo relevante sea el de disponibilidad. Si no concurren, se evalúa el riesgo. No existe una regla «AES-256 o notificación automática», ni al revés.

P: ¿Cuánto cuesta una brecha datos para una pyme? R: no se ha localizado una media pública específica para pymes españolas. Como referencia internacional —global, en dólares y sobre grandes organizaciones—, IBM sitúa el promedio de su muestra de 2026 en 4,99 millones de dólares. Trasladarlo a una pyme española no es una estimación, es una invención.

P: ¿Puedo evitar sanción AEPD si notifico dentro 72h? R: notificar en plazo cumple una obligación, pero no cierra la puerta a que la Agencia valore otras infracciones —medidas de seguridad insuficientes del art. 32, falta de comunicación a los afectados del art. 34—. Tampoco al revés: la propia AEPD advierte de que notificar una brecha «no implica necesariamente la apertura de un procedimiento administrativo». Y conviene no venderlo como atenuante: las directrices 04/2022 del CEPD consideran la notificación obligatoria del art. 33 un factor neutro; solo una cooperación que haya llegado a limitar o evitar consecuencias negativas puede reducir la multa.

P: ¿Necesito contratar perito forense para notificación AEPD? R: no es obligatorio, pero sí muy recomendable. El perito aporta análisis técnico de la evidencia, una cronología acreditada —cuándo ocurrió, desde cuándo se supo, cuántos registros— y un informe utilizable en un procedimiento. Lo que no puede prometerse es una reducción de la sanción: eso depende de la Agencia y de las circunstancias del caso, y ningún porcentaje de rebaja está publicado.

Referencias y Fuentes

1. RGPD. (2016). “Reglamento (UE) 2016/679 - Artículos 33 y 34”. eur-lex.europa.eu

   • Artículo 33: Notificación brecha autoridad control (72h)
   • Artículo 34: Comunicación afectados (sin dilación indebida)

2. AEPD. Memoria anual 2023 (PDF). aepd.es

   • Más de 2.000 brechas de datos personales notificadas en 2023
   • 16 de ellas derivadas a la Subdirección de Inspección de Datos para investigación
   • En 30 casos, el responsable quedó obligado a comunicar la brecha a los afectados
   • Estadística mensual detallada: notificaciones de brechas a la AEPD

3. AEPD. Guía para la notificación de brechas de datos personales (PDF, v. junio de 2021, 48 pp.)

   • Procedimiento de notificación del artículo 33
   • Criterios de comunicación a los afectados del artículo 34
   • Contiene ejemplos didácticos, no casos reales anonimizados: la propia guía advierte de que «se circunscriben a las circunstancias y situaciones específicas» y «no constituyen en ningún caso reglas de aplicación general»

4. ENISA. Threat Landscape 2024 (PDF). enisa.europa.eu

   • Siete amenazas principales identificadas; las amenazas contra la disponibilidad encabezan la lista, seguidas del ransomware y de las amenazas contra los datos
   • En el sector de administración pública de la UE, las amenazas contra los datos son el segundo tipo más frecuente: brechas de datos 17,4 % y exposiciones 1 %
   • Landscape sectorial de administración pública: 586 incidentes reportados públicamente en 2024, con DDoS al 60 % y ransomware al 10 %

5. IBM Security — Cost of a Data Breach Report. Cada edición se cita por separado, porque la URL genérica ibm.com/reports/data-breach sirve siempre la última y una cifra anclada ahí cambia sola:

   • Edición 2026: coste medio global 4,99 millones de dólares
   • Edición 2025: 4,44 millones de dólares y 241 días de media para identificar y contener una brecha
   • Edición 2024: 4,88 millones de dólares
   • ⚠️ Todas esas cifras están en dólares y son medias globales: el informe no desglosa España en sus resúmenes públicos, y la versión completa se descarga tras formulario.

6. INCIBE. (2025). Balance de ciberseguridad 2024. Nota de prensa oficial

   • 97.348 incidentes gestionados en 2024, un 16,6 % más que en 2023
   • Malware 42.136 · fraude online más de 38.000, con phishing a la cabeza (21.571)
   • Intrusiones e intentos de acceso no autorizado: 7.470
   • 98.546 consultas atendidas por «Tu Ayuda en Ciberseguridad» (+21,8 %)

7. OCU. Derechos del consumidor y garantías de compra — página general de derechos y garantías del consumidor. Se enlaza como recurso divulgativo general: no documenta ninguna acción colectiva por brechas de datos.

8. CCN-CERT. Guía CCN-STIC 817: Esquema Nacional de Seguridad — Gestión de Ciberincidentes (PDF). ccn-cert.cni.es

   • Tipifica 36 clases de ciberincidente y fija cinco niveles de peligrosidad
   • Establece la metodología de notificación al CCN-CERT según el momento y la tipología
   • Dirigida al sector público: equipos de respuesta y responsables de seguridad
   • Ojo: el plazo de 72 horas del artículo 33 del RGPD es obligación frente a la AEPD, no un plazo de esta guía. Son marcos distintos y conviven
   • El enlace directo al PDF devuelve 403 a clientes automatizados (es un WAF, no un enlace roto): abre con normalidad en navegador. Como respaldo estable, la ficha del CCN-CERT sobre gestión de ciberincidentes en el sector público confirma los 36 tipos y los cinco niveles

Última actualización: 4 de septiembre de 2026 Categoría: Análisis (ANA-003) Nivel técnico: Medio Relevancia forense: MUY ALTA (análisis post-brecha, peritajes sanciones AEPD) Marco legal: RGPD artículos 33-34 (notificación 72 horas)