Preservar evidencias digitales consiste en recogerlas por orden de volatilidad, garantizar su integridad mediante funciones hash, documentar cada acción y mantener la cadena de custodia, conteniendo el incidente sin destruir información. En España, esto condiciona tanto su validez probatoria como el cumplimiento de las obligaciones de notificación.
Cuando ocurre un ciberincidente, la reacción natural es restaurar la actividad cuanto antes: reinstalar el equipo, restablecer la contraseña, borrar el correo malicioso o recuperar desde la copia de seguridad. Cada una de estas acciones, hecha sin método, puede destruir justo la información necesaria para responder a cuatro preguntas críticas:
La calidad de una investigación, y la validez de sus evidencias ante autoridades, aseguradoras y tribunales, se decide en las primeras horas del incidente.
Una evidencia digital es cualquier información almacenada o transmitida en formato digital que puede servir para reconstruir los hechos de un incidente. Incluye el contenido de la memoria, los ficheros, los registros de actividad, el tráfico de red, los correos electrónicos y los logs de servicios en la nube.
Su característica principal es también su mayor debilidad: es volátil, fácil de modificar y fácil de destruir, a menudo sin dejar rastro de la alteración.
Una evidencia mal recogida puede seguir siendo útil para la investigación técnica, pero perder buena parte de su valor como prueba.
Las normas de referencia coinciden en seis principios básicos:
Estos principios se recogen en normas como ISO/IEC 27037 (adoptada en España como UNE-EN ISO/IEC 27037), UNE 71505 (sistema de gestión de evidencias electrónicas), UNE 71506 (metodología para el análisis forense de evidencias electrónicas) y RFC 3227, que establece el orden de volatilidad.
El orden de volatilidad indica que deben recogerse primero las evidencias que desaparecen antes. Apagar un equipo o reiniciar un servicio puede eliminar en segundos información que nunca podrá recuperarse.
| Orden | Evidencia | Por qué es urgente |
|---|---|---|
| 1 | Memoria RAM | Se pierde al apagar; contiene procesos, claves y conexiones activas |
| 2 | Conexiones de red y estado del sistema | Cambian continuamente |
| 3 | Procesos en ejecución | Desaparecen al terminar o reiniciar |
| 4 | Ficheros temporales | El sistema los sobrescribe con el uso |
| 5 | Disco | Persistente, pero se altera con cada escritura |
| 6 | Logs locales y en la nube | Sujetos a rotación y a periodos de retención limitados |
| 7 | Copias de seguridad y archivos | Más estables, pero pueden estar comprometidas o rotar |
En los entornos cloud, el orden clásico necesita un matiz importante. Los logs de servicios en la nube no se pierden al apagar un equipo, pero caducan:
Si el incidente se detecta tarde, la evidencia clave puede estar a punto de desaparecer.
La contención y la preservación no son incompatibles, pero exigen disciplina. Esta es la guía básica para los primeros intervinientes.
Qué hacer:
Qué no hacer:
En equipos y servidores, la prioridad es:
En servidores críticos que no pueden detenerse, se realizan adquisiciones en caliente documentando el impacto. En máquinas virtuales, las instantáneas (snapshots) permiten capturar memoria y disco con menos alteración.
La mayoría de los incidentes actuales empiezan con el compromiso de una identidad. Antes de restablecer contraseñas o eliminar elementos, conviene preservar:
Exportar estos registros antes de aplicar cambios evita perder la secuencia de acciones del atacante. Para profundizar en este escenario, consulta nuestra guía sobre el compromiso de cuentas en Microsoft 365.
En Microsoft 365, gran parte de la evidencia reside en registros cuya disponibilidad depende de la licencia y de la configuración previa al incidente:
La recomendación práctica es exportar y preservar estos registros desde el primer momento, aunque todavía no se sepa si serán necesarios. Lo explicamos en detalle en nuestra guía de análisis forense en Microsoft 365.
Los registros del firewall, el proxy, la VPN, el DNS, el EDR y el SIEM permiten reconstruir los movimientos del atacante entre sistemas y detectar posibles exfiltraciones. Muchos de estos sistemas rotan los logs en días o semanas, así que conviene:
Activa el plan de respuesta a incidentes y designa a un responsable de la investigación. Obtén la autorización de la dirección y, cuando haya datos personales o comunicaciones de empleados implicados, implica al Delegado de Protección de Datos y a la asesoría jurídica.
Antes de tocar nada, documenta el estado del sistema con fotografías, capturas de pantalla y notas: qué se observa, quién lo detectó y cuándo.
A partir de ese momento, registra cada acción con fecha, hora, responsable, herramienta y resultado.
Sigue el orden de volatilidad: memoria, conexiones, procesos y estado del sistema. En paralelo, identifica los logs cloud próximos a caducar y exporta su contenido.
Obtén imágenes forenses completas de los discos afectados, con bloqueadores de escritura cuando sea posible. En la nube, exporta los registros de auditoría, inicios de sesión y buzones mediante herramientas oficiales, documentando los filtros y parámetros utilizados.
Calcula el hash de cada evidencia en el momento de su adquisición y vuelve a comprobarlo antes de cada análisis. Etiqueta cada elemento con un identificador único y guárdalo en un almacenamiento con acceso restringido y registrado.
Para reforzar la integridad, se puede aplicar un sellado de tiempo cualificado conforme al Reglamento eIDAS.
Cada vez que una evidencia cambia de manos (del técnico al analista, al perito o a la autoridad), registra quién entrega, quién recibe, cuándo, por qué y el hash verificado en ese momento.
Organiza las evidencias y la documentación para sus posibles destinos:
Trabaja siempre sobre copias verificadas y conserva los originales intactos.
En España, la valoración de una evidencia digital como prueba corresponde al juez. Hay tres elementos que refuerzan de forma significativa su credibilidad:
En el ámbito civil, la Ley de Enjuiciamiento Civil admite como medios de prueba los instrumentos que permiten archivar y reproducir datos, y contempla su impugnación cuando se cuestiona su autenticidad. En el ámbito penal, la Ley de Enjuiciamiento Criminal regula, desde la reforma de 2015, las diligencias de investigación tecnológica, que en muchos casos requieren autorización judicial.
Hay varias piezas que aportan garantías adicionales:
Dado que cada procedimiento tiene sus particularidades, es recomendable validar con asesoría jurídica la estrategia de recogida desde el inicio del incidente.
La preservación de evidencias está directamente ligada a las obligaciones de notificación: sin evidencias no es posible determinar el alcance del incidente ni informar con precisión a las autoridades.
| Normativa | A quién se notifica | Plazo | Cuándo aplica |
|---|---|---|---|
| RGPD | AEPD | 72 horas desde que se tiene constancia | Brechas de datos personales con riesgo para los derechos de las personas |
| ENS (RD 311/2022) | CCN-CERT | Según la criticidad, conforme a la Guía Nacional de Notificación | Sector público y sus proveedores |
| RDL 12/2018 (NIS1, vigente) | INCIBE-CERT o CCN-CERT y la autoridad competente | Sin dilación indebida | Operadores de servicios esenciales y proveedores de servicios digitales |
| NIS2 (ley en tramitación) | CSIRT y autoridad competente | Aviso en 24 h, notificación en 72 h, informe final en 1 mes | Entidades esenciales e importantes, cuando se apruebe la ley |
| DORA | Banco de España, CNMV o DGSFP | Inicial en 4 h desde la clasificación (máx. 24 h), intermedia en 72 h, final en 1 mes | Entidades financieras ante incidentes TIC graves |
Sobre el estado de NIS2: a octubre de 2026, la Ley de Coordinación y Gobernanza de la Ciberseguridad, que transpone NIS2, sigue en tramitación parlamentaria y no se ha publicado en el BOE. Mientras tanto, sigue aplicándose el Real Decreto-ley 12/2018. Las empresas incluidas en el ámbito de NIS2 deberían preparar ya sus procedimientos de notificación.
El documento operativo de referencia para clasificar y notificar incidentes es la Guía Nacional de Notificación y Gestión de Ciberincidentes. Para obtener orientación, las empresas y los ciudadanos pueden llamar a la línea 017 de INCIBE, gratuita y confidencial.
Un registro de cadena de custodia debería incluir, como mínimo, los siguientes campos:
Restaurar antes de investigar. Recuperar desde una copia de seguridad o reinstalar el sistema elimina las evidencias y puede reintroducir al atacante si no se conoce la vía de entrada.
Apagar el equipo por instinto. Se pierde la memoria, que a menudo contiene la única prueba de un malware que no deja rastro en disco.
Borrar cuentas o correos maliciosos. Eliminar la cuenta comprometida o el correo de phishing destruye la evidencia de lo que ocurrió.
Descubrir tarde que los logs no existían. Muchas organizaciones comprueban la retención de sus logs cloud durante el incidente, cuando ya no hay solución. La auditoría debe estar configurada antes.
No documentar las acciones. Una evidencia sin registro de quién la recogió, cuándo y cómo pierde buena parte de su valor probatorio.
Investigar sobre los originales. Todo análisis debe hacerse sobre copias verificadas mediante hash.
La preservación de evidencias digitales es la base de cualquier investigación de incidentes con garantías. Determina si la empresa podrá:
En España, la combinación de normas técnicas (ISO/IEC 27037, UNE 71505 y UNE 71506), requisitos legales de prueba y obligaciones de notificación (RGPD, ENS, DORA y la futura ley de NIS2) exige que los primeros intervinientes actúen con rigor forense desde el primer minuto. En entornos cloud, donde la evidencia caduca, esa preparación tiene que existir antes del incidente.
ne Digital ayuda a las organizaciones a:
Si el incidente es de tipo ransomware, consulta también nuestra guía de respuesta ante un ataque de ransomware.
Contacte a los expertos de ne Digital para conocer más sobre las buenas prácticas para respuesta a incidentes.