Cumplimiento en ciberseguridad 2026: una brecha, muchos plazos de notificación

Piensa en una empresa SaaS europea con clientes en la UE, Estados Unidos, Brasil e India. Una sola intrusión puede poner en marcha un plazo de seis horas en India, uno de 24 horas con NIS2, uno de 72 horas con el RGPD, uno de tres días hábiles en Brasil y plazos de 30 días en varios estados de EE. UU., cada uno con su propio disparador, destinatario y contenido.

A continuación: esos plazos en un solo sitio y, después, lo que tiene que existir antes: marcas de tiempo demostrables, triaje, una matriz de notificación, gestión de evidencias y un ensayo. Esto es una guía de ingeniería, no asesoramiento jurídico: es tu asesor legal quien decide si, cuándo y qué notificar.

Primera pregunta: ¿de quién es el plazo?

La mayor parte de los datos que guarda una empresa SaaS B2B pertenece a sus clientes. Para esos datos eres encargado del tratamiento (RGPD), operador (LGPD) o asociado comercial (HIPAA), y los plazos ante los reguladores son de tus clientes. Tu trabajo es avisarles a tiempo:

• Artículo 33(2) del RGPD: notifica al responsable del tratamiento sin dilación indebida. El Comité Europeo de Protección de Datos considera que el responsable tiene conocimiento en cuanto se lo comunicas, así que tu retraso se come sus 72 horas.
• HIPAA: notifica a la entidad cubierta sin demora injustificada y dentro de los 60 días naturales siguientes al descubrimiento.
• DORA: nunca informas a un supervisor, pero los contratos con entidades financieras deben obligarte a prestar asistencia en los incidentes de TIC (artículo 30(2)(f)), y tu cliente puede tener cuatro horas desde que lo clasifica como grave.
• Tus acuerdos de encargo del tratamiento: muchos fijan un número de horas. Ese número es tu plazo real.

Para tus propios datos (contactos de cuentas, facturación, empleados, leads) eres el responsable del tratamiento, y los plazos de abajo son tuyos. Un régimen ignora esa división: las preguntas frecuentes de CERT-In dicen que cualquier entidad que detecte un incidente debe notificarlo, y que esa obligación no se puede transferir por contrato.

Los plazos de la UE: RGPD, NIS2 y DORA

Artículo 33 del RGPD, la autoridad de control. El disparador es tener conocimiento de una violación de la seguridad de los datos personales, que el CEPD interpreta como un grado razonable de certeza de que se han visto comprometidos datos personales, tras una breve investigación inicial. Notifica sin dilación indebida y, si es posible, en un plazo de 72 horas, salvo que sea improbable que la violación suponga un riesgo para las personas. Contenido: la naturaleza de la violación, el número aproximado de personas y de registros, un punto de contacto, las consecuencias probables y las medidas adoptadas. La información puede facilitarse por fases.

Artículo 34 del RGPD, las personas afectadas. Cuando el riesgo es alto, sin dilación indebida y en lenguaje claro; no es obligatorio si los datos eran ininteligibles para el atacante, por ejemplo porque estaban cifrados.

Artículo 23 de NIS2. Se aplica a las entidades esenciales e importantes: sobre todo organizaciones medianas o mayores de los sectores de los anexos I y II. Los considerandos de la directiva incluyen el SaaS entre los modelos de servicio de computación en nube, así que una empresa SaaS de ese tamaño puede estar dentro del ámbito. Ante un incidente significativo, el CSIRT nacional o la autoridad competente recibe:

• Una alerta temprana en 24 horas desde que tienes conocimiento: ¿se sospecha una acción maliciosa?, ¿puede haber impacto transfronterizo?
• Una notificación del incidente en 72 horas: evaluación inicial de la gravedad y el impacto, indicadores de compromiso.
• Un informe final en el plazo de un mes desde la notificación del incidente: causa raíz, mitigación, impacto transfronterizo.

Para los proveedores de nube, el Reglamento de Ejecución (UE) 2024/2690 considera significativo cualquier compromiso de los datos del servicio causado por una presunta acción maliciosa, y que un servicio esté totalmente indisponible durante más de 30 minutos. La transposición debía completarse antes del 17 de octubre de 2024; en julio de 2026 la Comisión llevó a cuatro Estados miembros ante el Tribunal de Justicia por no haber notificado la transposición completa. Los portales y formularios dependen de la ley nacional.

DORA, para entidades financieras desde el 17 de enero de 2025. Ante un incidente grave relacionado con las TIC: notificación inicial en las cuatro horas siguientes a clasificarlo como grave y, como máximo, 24 horas después de tener conocimiento; informe intermedio en las 72 horas siguientes a la notificación inicial; informe final en el plazo de un mes desde el último informe intermedio.

Brasil, India y Estados Unidos

Brasil: artículo 48 de la LGPD y Resolución CD/ANPD n.º 15/2024. El controlador notifica a la ANPD y a los titulares afectados en un plazo de tres días hábiles desde que sabe que el incidente afectó a datos personales. Esto se aplica cuando puede afectar de forma significativa a los derechos de las personas e implica datos sensibles, datos de niños, adolescentes o personas mayores, datos financieros o de autenticación, datos protegidos por secreto legal o profesional, o una gran escala. El formulario electrónico de la ANPD, que presenta el encargado (el DPO) o un representante, cubre doce puntos y puede completarse en un plazo de 20 días hábiles. Todos los incidentes, notificados o no, van a un registro que se conserva al menos cinco años.

India: Directrices de CERT-In del 28 de abril de 2022. Notifica en las seis horas siguientes a detectar un incidente o a que te informen de él. El anexo I enumera veinte tipos, desde el acceso no autorizado hasta los ataques a sistemas en la nube; las preguntas frecuentes citan las brechas y fugas de datos entre los que deben cumplir las seis horas. Envía lo que sepas y completa el resto después, por correo electrónico (incident@cert-in.org.in), teléfono o fax. Las preguntas frecuentes aplican las Directrices a cualquier entidad en materia de ciberincidentes.

India: Ley DPDP de 2023 y Reglamento DPDP de 2025. La regla 7 exige informar sin demora a cada titular de datos afectado y al Data Protection Board, y enviar al Board un informe detallado en 72 horas. Tal como se publicó en noviembre de 2025, la regla 7 entra en vigor dieciocho meses después de su publicación, en mayo de 2027. Hasta entonces, el plazo de India lo marca CERT-In.

Estados Unidos. No hay una ley federal única sobre brechas; cada estado protege a sus residentes, esté donde esté tu empresa:

• Washington, Nueva York, Florida: notifica a los residentes sin demora injustificada y en un plazo de 30 días desde el descubrimiento (en Florida, desde que se determina la brecha).
• Utah: sin demora injustificada, sin un número fijo de días.
• Reguladores: el fiscal general de Washington a partir de 500 residentes y el Departamento de Asuntos Legales de Florida desde 500, ambos en 30 días; el fiscal general de Utah desde 500; el fiscal general, el Departamento de Estado y la Policía Estatal de Nueva York; una copia de la notificación al fiscal general de California por encima de 500.

Por sector:

• Formulario 8-K de la SEC, punto 1.05: una empresa cotizada en EE. UU. decide sobre la materialidad sin demora injustificada tras el descubrimiento y, después, presenta el formulario en cuatro días hábiles. Los emisores privados extranjeros usan el formulario 6-K.
• HIPAA: a las personas en un plazo de 60 días naturales desde el descubrimiento, y al HHS al mismo tiempo cuando hay 500 o más personas afectadas.
• Safeguards Rule de la FTC: las entidades financieras no bancarias notifican a la FTC en 30 días desde que descubren una obtención no autorizada de datos sin cifrar de 500 o más consumidores.
• CIRCIA: 72 horas para los incidentes cubiertos cuando entre en vigor la norma final de CISA; en noviembre de 2026 todavía no lo ha hecho, así que aún no hay nada que notificar.

Cuándo empieza el plazo y cómo lo demuestras

El RGPD y NIS2 hablan de «tener conocimiento», CERT-In de «detectar», la ANPD de saber que se vieron afectados datos personales, HIPAA y la FTC del «descubrimiento» por parte de cualquier empleado, y HIPAA incluye lo que una diligencia razonable habría revelado. La SEC empieza a contar en la decisión sobre la materialidad, y DORA en la clasificación. Cada uno debe ser una marca de tiempo defendible:

• Una sola base de tiempo. Guarda en UTC. CERT-In exige relojes que no se desvíen de los servidores de hora nacionales de India, acepta UTC y pide que registres la zona horaria; el Reglamento de Ejecución (UE) 2024/2690 pide fuentes de tiempo sincronizadas. Crea una alerta para cualquier host en el que timedatectl show -p NTPSynchronized --value deje de imprimir yes.
• Un único registro del incidente, con un campo por disparador y por envío, porque el informe final de NIS2 y los informes posteriores de DORA cuentan desde lo que enviaste:

# all times UTC, from NTP-synchronized hosts
id: INC-2026-0142
declared_at: 2026-11-17T10:05:00Z
triggers:
  first_alert_at: 2026-11-17T09:12:44Z          # explain any gap to noticed_at
  noticed_at: 2026-11-17T09:40:00Z              # CERT-In
  aware_significant_at: 2026-11-17T11:15:00Z    # NIS2
  aware_personal_data_at: 2026-11-17T14:30:00Z  # GDPR, LGPD, US states
  classified_major_at: null                     # DORA, financial entities
  materiality_determined_at: null               # SEC, if US-listed
submitted:
  certin_report_at: null
  nis2_early_warning_at: null
  nis2_notification_at: null                    # final report due one month later
  controller_notices: []                        # per customer: deadline, sent_at

Las autoridades preguntarán por el intervalo entre first_alert_at y noticed_at. Si las alertas esperan a la mañana, las seis horas se han ido antes de que nadie las lea; cerrar ese intervalo es para lo que existen las operaciones de NOC 24/7.

Triaje: ¿qué plazos están corriendo?

Hazlo en la primera hora y cada vez que cambien los hechos:

1. 1¿Hay que notificar algo? El acceso no autorizado está en la lista de CERT-In. Las entidades sujetas a NIS2 revisan los criterios de significatividad.
2. 2¿Hay datos personales afectados? Confidencialidad, integridad o disponibilidad. Algunos incidentes ni siquiera tocan tu infraestructura, como los datos de clientes pegados en un chatbot de IA gratuito.
3. 3¿En qué papel? Contenido de clientes (encargado) o tus propios datos (responsable).
4. 4¿Dónde viven las personas? Necesitas un mapa de datos por país, y por estado en EE. UU., hecho de antemano. Sin él, todas las jurisdicciones entran en juego.
5. 5¿Qué sectores? Clientes que son entidades financieras, sanidad en EE. UU., prestamistas no bancarios, y si eres una entidad sujeta a NIS2.
6. 6¿Cotizas en EE. UU.? Pon en marcha el proceso de materialidad.

El resultado son los plazos en curso, con su vencimiento en UTC. Calcúlalos, no lo hagas a mano bajo presión:

#!/usr/bin/env bash
# clocks.sh: first-wave deadlines, an estimate counsel confirms.
# Needs GNU date; the holiday file has one YYYY-MM-DD per line.
set -euo pipefail

NOTICED_AT="2026-11-17T09:40:00Z"             # CERT-In
AWARE_SIGNIFICANT_AT="2026-11-17T11:15:00Z"   # NIS2
AWARE_PERSONAL_DATA_AT="2026-11-17T14:30:00Z" # GDPR, LGPD, US states
BR_HOLIDAYS="holidays-br.txt"
[[ -r "$BR_HOLIDAYS" ]] || { echo "missing $BR_HOLIDAYS" >&2; exit 1; }

plus_hours() {
  date -u -d "@$(( $(date -u -d "$1" +%s) + $2 * 3600 ))" +%Y-%m-%dT%H:%MZ
}

# Count from the next local day in the regulator's time zone,
# skipping weekends and listed holidays.
plus_business_days() {
  local day n=0
  day=$(TZ="$3" date -d "$1" +%F)
  while (( n < $2 )); do
    day=$(date -u -d "$day +1 day" +%F)
    (( $(date -u -d "$day" +%u) >= 6 )) && continue
    grep -qx "$day" "$4" && continue
    n=$((n + 1))
  done
  echo "$day (end of day, $3)"
}

echo "CERT-In report          $(plus_hours "$NOTICED_AT" 6)"
echo "NIS2 early warning      $(plus_hours "$AWARE_SIGNIFICANT_AT" 24)"
echo "NIS2 notification       $(plus_hours "$AWARE_SIGNIFICANT_AT" 72)"
echo "GDPR authority          $(plus_hours "$AWARE_PERSONAL_DATA_AT" 72)"
echo "LGPD ANPD and subjects  $(plus_business_days "$AWARE_PERSONAL_DATA_AT" 3 America/Sao_Paulo "$BR_HOLIDAYS")"
echo "WA, NY, FL residents    $(plus_hours "$AWARE_PERSONAL_DATA_AT" $((30 * 24)))"

Ejemplo práctico: con estos datos de entrada, CERT-In vence a las 15:40 UTC del mismo martes y el RGPD el viernes a las 14:30 UTC. La fecha de la LGPD es el lunes 23 de noviembre, porque el viernes 20 de noviembre es festivo nacional en Brasil. Tu asesor legal confirma cómo se cuentan los días hábiles.

La matriz de notificación, escrita de antemano

Una entrada por destinatario, acordada antes de cualquier incidente, en este orden: plazo, disparador, contenido mínimo, quién la envía, plantilla.

• Clientes cuyos datos tratas: las horas de cada acuerdo de encargo, desde que confirmas que sus datos se vieron afectados; qué pasó, qué tenants y conjuntos de datos, la ventana de tiempo, las medidas, un contacto; customer success; un aviso por tenant.
• Clientes que son entidades financieras: horas contractuales dimensionadas según sus límites de DORA; los hechos que necesita su notificación inicial; el responsable de la cuenta; una ficha de hechos.
• CERT-In: seis horas desde la detección; lo que sabes hasta ese momento; tu punto de contacto designado; el formulario de notificación de CERT-In.
• Autoridad de NIS2: 24 y 72 horas desde que tienes conocimiento y, después, un mes desde la notificación; el contenido del artículo 23(4); el responsable de seguridad; el portal nacional.
• Autoridad de control principal del RGPD: 72 horas desde que tienes conocimiento; el contenido del artículo 33(3); el DPO; el formulario en línea de la autoridad.
• ANPD: tres días hábiles desde que sabes que se vieron afectados datos personales; los doce puntos; el encargado; el formulario electrónico de la ANPD.
• Personas afectadas: con el RGPD, cuando el riesgo es alto; con la LGPD, en tres días hábiles; en los estados de EE. UU., dentro de sus límites; avisos en lenguaje claro en cada idioma, aprobados por el asesor legal.
• Reguladores de EE. UU.: los fiscales generales según exija cada estado; la SEC en cuatro días hábiles desde una decisión de materialidad.

¿No sabes cuáles de estos plazos podrías cumplir hoy? Solicita una evaluación gratuita de preparación ante incidentes: hacemos el triaje sobre tu mapa de datos, comprobamos las marcas de tiempo y la retención de logs frente a tus plazos y te entregamos una matriz de notificación con las carencias señaladas.

Logs y evidencias que debes tener listos ya

La retención que fijan las normas:

• CERT-In: logs de todos los sistemas TIC durante 180 días móviles. La Directriz dice que dentro de la jurisdicción india; las preguntas frecuentes permiten guardarlos en el extranjero si puedes entregarlos en un plazo razonable.
• Brasil, artículo 15 del Marco Civil de Internet: los proveedores de aplicaciones que operan como empresa conservan los registros de acceso (fecha, hora, dirección IP) durante seis meses.
• ANPD: el registro de incidentes, al menos cinco años.
• Artículo 33(5) del RGPD: documenta todas las violaciones, notificadas o no.
• HIPAA: la documentación obligatoria, seis años.
• Reglamento DPDP, regla 6: logs durante un año, a partir de mayo de 2027.

Cuando empieza un incidente, copia antes de que nadie limpie nada:

#!/usr/bin/env bash
# preserve.sh INCIDENT_ID PATH...: copy, timestamp and hash evidence on first touch.
set -euo pipefail
id="$1"; shift
dest="${EVIDENCE_ROOT:-/srv/evidence}/$id/$(date -u +%Y%m%dT%H%M%SZ)-$(hostname -s)"
mkdir -p "$dest"
{
  echo "incident: $id"
  echo "host: $(hostname -f 2>/dev/null || hostname)"
  echo "collected_by: $(id -un)"
  echo "collected_at_utc: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo "ntp_synchronized: $(timedatectl show -p NTPSynchronized --value 2>/dev/null || echo unknown)"
} > "$dest/MANIFEST"
for src in "$@"; do
  tar -C "$(dirname "$src")" -czf "$dest/$(basename "$src").tar.gz" "$(basename "$src")"
done
(cd "$dest" && sha256sum -- * > SHA256SUMS)
chmod -R a-w "$dest"
echo "$dest"

Después envíalo a un almacenamiento de objetos con bloqueo de retención en una cuenta separada, el mismo patrón que mantiene las copias de seguridad y la recuperación ante desastres fuera del alcance de un atacante. Más tarde, sha256sum -c SHA256SUMS demuestra que nada ha cambiado.

Un ejercicio de mesa de 90 minutos contra el reloj

Usa tu registro, tu matriz y tus plantillas reales, y un secretario que anote en UTC la hora de cada decisión. Cada inyección hace avanzar el reloj:

1. 1Minutos 0-20, T+0: una tarea de exportación se ejecutó durante la noche con una cuenta de servicio que nunca exporta; 4 GB salieron hacia una dirección desconocida. Esperado: declarar el incidente, abrir el registro, preservar evidencias, hacer el triaje, decidir sobre CERT-In.
2. 2Minutos 20-40, T+6h: el análisis forense confirma que la exportación contenía nombres, correos electrónicos y hashes de contraseñas de usuarios de Alemania, Brasil, India y el estado de Washington. Esperado: CERT-In ya notificado (¿lo estaba?), avisos a clientes redactados, la fecha de la LGPD calculada.
3. 3Minutos 40-60, T+24h: un cliente bancario lo ha clasificado como grave y quiere hechos; llama un periodista. Esperado: alerta temprana de NIS2 enviada si estás en el ámbito, una única ficha de hechos aprobada.
4. 4Minutos 60-75, T+72h: aparece una muestra en un sitio de filtraciones. Esperado: notificación de NIS2 presentada, la del RGPD a punto de vencer en unas horas (su plazo empezó en T+6h), el artículo 34 y los criterios de la LGPD reevaluados (los datos de autenticación son uno de ellos), avisos de EE. UU. planificados.
5. 5Minutos 75-90, revisión: compara cada plazo con el momento en que su borrador estuvo listo. Cada incumplimiento se convierte en un ticket con responsable.

Una única base de controles para varios regímenes

Los plazos cambian; los controles, apenas. Relojes sincronizados, logs centralizados con retención, control de acceso, restauraciones probadas, un plan de incidentes ensayado y contratos con cláusulas de notificación sirven para todos los regímenes anteriores. Nuestro playbook de SOC 2 para startups convierte cada control en una tarea de ingeniería con su evidencia; en Kubernetes, consulta cómo automatizar las evidencias de cumplimiento en Kubernetes.

Evaluación gratuita de preparación ante incidentes

Si tus clientes están en varias jurisdicciones, nuestro equipo de ciberseguridad comprobará sin coste si podrías cumplir todos los plazos. Cubre:

• Triaje y mapa de datos: qué regímenes se aplican a qué conjuntos de datos y en qué papel.
• Marcas de tiempo y logs: la sincronización de relojes, el registro del incidente y la retención frente a cada régimen.
• Preparación para notificar: la matriz, las plantillas y las horas contractuales, probadas en una línea de tiempo comprimida.

Recibes una lista escrita de las carencias entre tu configuración y los plazos que te aplican, sin ningún compromiso. Solicita tu evaluación gratuita de preparación ante incidentes o consulta nuestras operaciones de NOC 24/7.