Te han hackeado: guía de respuesta para empresas en España

Las primeras horas, por orden

El orden importa más que la velocidad. Estos son los pasos que evitan que un incidente contenible se convierta en uno que no lo es.

• 1. Contén sin destruir. Aísla lo afectado de la red, pero no lo apagues ni lo reinstales todavía. Apagar borra lo que solo existe en memoria, y eso es a menudo la única forma de saber qué se llevaron. La diferencia entre "nos atacaron" y "nos atacaron y sabemos qué se fue" se decide en esta hora.
• 2. Deja de usar las credenciales que puedan estar comprometidas, y no entres en los equipos afectados con cuentas de administración. Es el error más caro y el más frecuente: quien va a arreglarlo le entrega sus permisos al que está dentro.
• 3. Abre un registro con horas. Qué se ha visto, cuándo, quién lo vio, qué se ha tocado. Ese documento es después la base de la notificación, del informe al seguro y de la denuncia, y no se puede reconstruir de memoria.
• 4. Preserva las evidencias antes de recuperar. Copias de los discos y de los registros, y los registros de todo lo que caduque pronto, que suele ser lo que más falta hace. Esto es análisis forense y conviene que lo dirija alguien que lo haya hecho antes.
• 5. Decide quién decide. Antes de comunicar nada hacia fuera, que esté claro quién manda: quién autoriza apagar producción, quién habla con clientes y quién firma la notificación a la autoridad. Si esto se improvisa, se improvisa mal.
• 6. Recupera con criterio. Restaurar sobre lo mismo por donde entraron es volver a empezar en dos semanas. Antes de devolver un sistema a producción hay que saber cómo entraron, o al menos haber cerrado la vía más probable.

Un playbook escrito de antemano convierte estos seis pasos en algo que se ejecuta en vez de discutirse. Y los indicadores de compromiso que salgan sirven para buscar en el resto de la red: si estaba en un equipo, la pregunta es en cuántos más está.

El reloj: 72 horas, y empieza antes de lo que crees

Este es el dato que la versión anterior de este artículo no daba, y es el que va a buscar quien llega.

Si el incidente afecta a datos personales y supone un riesgo para las personas, hay que notificarlo a la autoridad de control sin dilación indebida y, a más tardar, dentro de las 72 horas siguientes a tener constancia de la brecha. En España esa autoridad es la AEPD. Y si el riesgo para las personas es alto, además hay que informar a los propios afectados. El marco es el RGPD, con la LOPDGDD encima para lo que corresponde al derecho español.

Dos malentendidos que cuestan caro:

• 72 horas no son 72 horas para terminar la investigación. Son el plazo para notificar con lo que se sepa, y ampliar después. Esperar a tenerlo todo claro es la forma habitual de llegar tarde.
• El reloj arranca cuando tienes constancia, no cuando ocurrió el ataque. Lo que convierte esto en un problema técnico y no jurídico: si no detectas, te enteras tarde, y eso es cómodo justo hasta que alguien pregunta cuánto tiempo llevaban dentro.

El procedimiento y el formulario están en la propia página de la AEPD sobre comunicación de brechas de datos, y el texto de la ley española en el BOE. Somos una empresa de seguridad y no un despacho: aquí decimos dónde está la obligación y qué reloj corre, y la interpretación concreta de tu caso la firma tu asesor.

Y si se te aplica NIS2 o DORA, el reloj es otro y va antes

Mucha empresa española asume que lo único que corre es el plazo de protección de datos. Desde 2024 hay dos calendarios más, y uno de ellos es más corto.

NIS2 es la Directiva (UE) 2022/2555, y su artículo 23 fija tres hitos ante un incidente significativo: una alerta temprana en 24 horas, una notificación del incidente en 72 y un informe final en un mes. Veinticuatro horas es poco tiempo para organizar nada que no estuviera organizado. Y ojo con darse por fuera del alcance por intuición: la lista de sectores incluye fabricación, alimentación, residuos, servicios postales y proveedores de servicios gestionados, y además una entidad dentro del alcance empuja obligaciones a sus proveedores por contrato.

DORA es el Reglamento (UE) 2022/2554 y afecta al sector financiero y a sus proveedores de servicios de tecnología. Obliga a clasificar los incidentes y a notificar los graves a la autoridad competente con su propio calendario de informe inicial, intermedio y final. Los plazos exactos están en las normas técnicas de desarrollo del reglamento y no los reproducimos aquí: si se te aplica DORA, esa tabla la tiene que tener tu equipo de cumplimiento por escrito y antes de necesitarla.

La consecuencia práctica de los tres relojes juntos es la misma: un deber de notificar es un deber de detectar. No se puede cumplir un plazo que empieza a contar cuando te enteras si no tienes forma de enterarte.

Qué hacemos nosotros, y qué no

Dicho claro, porque esta página la lee gente con un problema encima y merece una respuesta recta: Asperis no vende respuesta a incidentes ni peritaje judicial. Si el incendio está ahora mismo, lo que necesitas es un equipo de respuesta y, según el caso, denuncia ante las autoridades policiales. No te vamos a vender otra cosa por estar en esta página.

Lo nuestro es la parte de antes y la de después, que es donde se decide cómo va a ir el día del incidente.

• Antes. Un ejercicio de brecha asumida parte de que alguien ya está dentro y mide hasta dónde llega y en cuánto tiempo se le ve. Es la forma barata de descubrir que la detección no cubría lo que se creía, sin que sea de verdad. Un ejercicio de red team responde a la misma pregunta contra un equipo de defensa que no sabe que es un ejercicio, que es lo más parecido a un ensayo general.
• Después. Cuando el incidente ya pasó, la pregunta útil es si lo que se arregló está de verdad arreglado. Eso es un retest: volver sobre los hallazgos y comprobar uno a uno que la corrección funciona, en vez de confiar en que el ticket se cerró.
• Y el marco. Si el incidente ha dejado a la vista que faltaba estructura, es cuando tiene sentido montar el sistema de gestión de ISO 27001, el Esquema Nacional de Seguridad si trabajas con administración pública, o el cumplimiento de protección de datos. Sobre la gestión de incidentes como disciplina, en el glosario está el resumen.

Lo que se prepara hoy y se agradece ese día

Casi todo lo que sale mal durante un incidente no sale mal por falta de tecnología. Sale mal porque nadie había decidido antes cuatro cosas.

Quién decide. Un nombre y un suplente, con autoridad para parar producción a las tres de la mañana sin pedir permiso.

Cómo os comunicáis si el correo no está disponible. Un canal alternativo acordado, con los teléfonos en algún sitio que no dependa del sistema que puede estar comprometido. Coordinar un incidente por el mismo correo que está leyendo el atacante es más frecuente de lo que parece.

Qué copias de seguridad tenéis y cuándo se probó restaurar. No cuándo se hizo la copia: cuándo se restauró de verdad y cuánto se tardó. Son dos preguntas distintas y solo la segunda sirve.

Y a quién llamáis. Con nombre, teléfono y, si hay contrato, número de contrato. Buscar proveedor de respuesta a incidentes mientras el incidente ocurre es la peor negociación posible.

Nada de esto cuesta dinero. Cuesta una reunión de una hora y escribirlo en un sitio que no sea la intranet que podría estar caída.

Última revisión: 3 de agosto de 2026. Publicada originalmente el 23 de enero de 2024.