Moncloa, 100 días sin soporte anti-APT: el hueco fue real, la filtración vino por otra vía

Durante casi 100 días, entre noviembre de 2025 y febrero de 2026, la Presidencia del Gobierno operó con un sistema anti-APT sin soporte del fabricante. En paralelo, y por una vía distinta, circularon datos personales del presidente Pedro Sánchez, ministros, el Jefe del Estado Mayor de la Defensa (JEMAD), el fiscal general del Estado y miembros del Consejo de Seguridad Nacional.

El resultado: Moncloa ha invertido más de 2 millones de euros en refuerzo de ciberseguridad, la UE investiga a España por no transponer la Directiva NIS2 y el panorama de ciberseguridad institucional español queda en entredicho ante la comunidad internacional.

Como perito informático forense que analiza brechas en organizaciones públicas y privadas, este incidente confirma un patrón que llevo documentando en mis informes periciales desde hace años: las organizaciones más sensibles a menudo descubren sus brechas cuando ya es demasiado tarde, especialmente cuando la cadena de suministro tecnológica falla en el momento crítico. Lo que paso en Moncloa no es un caso aislado. Es la consecuencia previsible de un modelo de gestión de la ciberseguridad que prioriza los contratos sobre la continuidad operativa.

Voy a ser directo porque la situación lo merece, pero también preciso: dejar tres meses sin soporte el sistema que protege Presidencia es un fallo de gestión, y merece explicarse aunque no haya causado esta filtración. Que nadie entrara por esa puerta no la vuelve menos abierta. Y 100 días sin actualizaciones de seguridad en la Presidencia del Gobierno es una puerta abierta con un cartel de bienvenida.

En este análisis detallo la cronología completa del incidente día a día, la técnica probable del ataque con reconstrucción del ciclo APT, las implicaciones para la seguridad nacional española (incluyendo riesgos de segundo y tercer orden que aun no se han materializado), el contexto europeo y el procedimiento de infracción de la UE contra España, la comparación con los modelos de ciberseguridad gubernamental de Francia, Alemania, Reino Unido y Estonia, la fragmentación de la gobernanza de ciberseguridad en España, el coste real de la brecha frente al coste de la prevención, y las lecciones concretas que toda organización puede extraer de este caso.

Todo ello desde mi perspectiva profesional como perito forense que ha investigado decenas de brechas similares en el sector privado, con opiniones críticas fundamentadas en mi experiencia directa.

Este es, probablemente, el análisis más detallado publicado hasta la fecha sobre el caso Moncloa desde una perspectiva forense independiente.

Qué ocurrió: cronología del episodio de Moncloa

Entre el 26 de febrero y el 4 de marzo de 2026 se publicaron datos personales de altos cargos del Estado español, compuestos a partir de brechas previas de terceros. La filtración no fue un evento aislado sino una secuencia de exposiciones escalonadas que afectaron a distintos niveles del aparato gubernamental, cada día más profundas y más daninas.

He reconstruido la cronología completa a partir de las publicaciones de El Español, The Objective, Voz Populi y Esdiario, cruzando fechas con los timestamps de los dumps publicados en foros de la dark web. Como perito forense, es importante entender que este tipo de filtraciones escalonadas no son aleatorias: los atacantes publican datos de forma progresiva para maximizar el impacto mediático y presionar a la víctima.

Cronología extendida día a día

Conviene resistir la lectura que se impuso en aquellos días, porque es la que este artículo tuvo que corregir: la de un atacante dentro de la red durante los 100 días, exfiltrando sin que nadie lo detecte. Ese patrón existe y es frecuente en peritajes de intrusión, pero no es el de este caso. Aquí el hueco de protección y la publicación de datos son dos hechos que coinciden en el tiempo y no en la causa, y la coincidencia temporal es exactamente lo que hizo verosímil una explicación equivocada.

Hay un detalle de la cronología que en su día pareció significativo: el contrato de sustitución se formalizó a mediados de febrero y la primera publicación fue el 26. Se leyó como una secuencia —el atacante publica al perder el acceso—, y es precisamente el tipo de inferencia que hay que resistir: dos fechas próximas no acreditan una relación. Si los datos procedían de brechas ajenas acumuladas durante años, el momento de la publicación no dice nada sobre el estado de las defensas de Presidencia.

El patrón de filtración escalonada

Un aspecto que no se ha analizado suficientemente en la cobertura mediatica es la estrategia de publicación escalonada que siguieron los atacantes. Esto no es aleatorio. En mi experiencia como perito forense, las filtraciones escalonadas cumplen múltiples propositos:

1. Presión creciente: Cada nueva oleada de datos aumenta la presión sobre la víctima para negociar, pagar o ceder ante las demandas del atacante
2. Demostración de capacidad: Publicar datos de cargos cada vez más sensibles (primero ministros, luego JEMAD, luego Consejo de Seguridad Nacional) demuestra que el atacante tiene acceso profundo y amplio
3. Manipulación mediatica: Cada oleada genera un nuevo ciclo de noticias, manteniendo el incidente en primera plana durante días en lugar de horas
4. Desgaste institucional: La gestión continua de la crisis durante una semana completa consume recursos, atención y credibilidad de forma acumulativa
5. Ocultación del alcance real: Mientras los medios y la opinion pública se centran en los datos publicados, el atacante puede estar vendiendo o explotando datos adicionales que no ha hecho públicos

He visto este mismo patrón en ataques de ransomware contra empresas españolas: el atacante pública primero una muestra pequeña de datos, espera la reacción, y si la víctima no paga, pública progresivamente más información sensible. La diferencia es que en el caso de Moncloa, los datos tienen implicaciones de seguridad nacional que multiplican el impacto de cada oleada.

Cargos afectados

La filtración comprometio datos de los niveles más altos del Estado:

• Presidente del Gobierno: Pedro Sánchez
• Varios ministros del Consejo de Ministros
• JEMAD: Jefe del Estado Mayor de la Defensa
• Fiscal General del Estado
• Miembros del Consejo de Seguridad Nacional
• Agentes de la Policía Nacional y la Guardia Civil
• Personal de la Fiscalía General del Estado
• Secretarios de Estado y altos cargos de diversos ministerios
• Personal de apoyo y administrativo

En todos los casos, datos personales: nombre, documento de identidad, domicilio, teléfono, fecha de nacimiento y contraseñas antiguas de servicios privados. (La lista incluía antes «personal cuyas credenciales proporcionan acceso a sistemas internos»: no consta que se publicara ninguna credencial operativa.)

La gravedad no reside solo en la cantidad de datos expuestos, sino en la naturaleza de los afectados: se trata de las personas que gestionan la seguridad nacional del país. Un atacante con los datos personales del JEMAD o de miembros del Consejo de Seguridad Nacional —domicilio, teléfonos, fechas de nacimiento— tiene lo necesario para localizarlos o suplantarlos, que es un riesgo distinto y más directo que el acceso a un sistema.

Para dimensionar la magnitud, es útil comparar con otras filtraciones gubernamentales recientes en Europa. El hackeo al Bundestag aleman en 2015 (atribuido al grupo APT28/Fancy Bear) comprometio 16 GB de datos de parlamentarios, pero no incluia credenciales de las fuerzas de seguridad ni datos de cargos de defensa. El ataque al sistema informático del Parlamento noruego en 2020 afecto a cuentas de email de parlamentarios pero no alcanzo a cargos ejecutivos. La comparación, sin embargo, no es homogénea: aquellos fueron intrusiones en los sistemas de las instituciones, y este caso no lo es. Lo singular aquí no es el volumen ni el vector, sino la selección deliberada del objetivo: componer la ficha personal del nivel ejecutivo más alto del Estado, del mando militar y del fiscal general a partir de brechas ajenas que nadie controla.

Desglose detallado de los datos expuestos y sus riesgos

En mis peritajes siempre insisto en que no todos los datos tienen el mismo valor para un atacante. Un nombre y un DNI no es lo mismo que unas credenciales de acceso a un sistema policial. Para entender la verdadera magnitud de esta brecha, hay que analizar cada tipo de dato y lo que un adversario sofisticado puede hacer con el.

Datos personales identificativos

Como perito que ha documentado casos de SIM swapping en España, puedo afirmar que con el nombre completo, DNI, fecha de nacimiento y número de teléfono de una persona, un atacante competente puede clonar su línea telefónica en menos de 24 horas. El proceso es sencillo: el atacante llama a la operadora de telefonía suplantando la identidad de la víctima (con los datos filtrados puede superar cualquier verificación de identidad telefónica), solicita un duplicado de SIM alegando pérdida o robo, y en cuanto la nueva SIM se activa, recibe todos los SMS y llamadas de la víctima, incluyendo los códigos de verificación de doble factor.

Si ese dato pertenece a un ministro o al JEMAD, las consecuencias van desde el acceso a comunicaciones privadas hasta la interceptación de códigos de autenticación de sistemas gubernamentales. Y este es solo uno de los muchos vectores de ataque que los datos filtrados de Moncloa habilitan.

Credenciales de acceso

Este es, en mi opinion profesional, el dato más crítico de toda la filtración.

El escalado en cadena a partir de una credencial filtrada es un patrón real y frecuente en el sector privado: se entra por una cuenta, se extraen credenciales con más privilegios y en horas se alcanza el administrador de dominio. Que ese escenario no se materializara aquí es precisamente lo que distingue este caso, y conviene decirlo con la misma claridad con la que se dijo lo contrario en las primeras horas.

Lo que se pudo inferir, y lo que no se publicó

Esta sección enumeraba «información clasificada y de seguridad nacional» como si hubiera sido exfiltrada. No lo fue. Lo que sigue describe lo que un analista puede inferir cruzando los datos personales publicados con fuentes abiertas —que es un riesgo real y merece explicarse—, no un inventario de documentos filtrados.

En mi experiencia como perito, cuando una organización me contrata para analizar una brecha, lo primero que evaluo es la “cadena de explotación”: que puede hacer un atacante combinando los distintos tipos de datos filtrados. En el caso de Moncloa, la combinación de datos personales, credenciales y datos de seguridad nacional crea una cadena de explotación de una gravedad sin precedentes en la historia reciente de España.

Un escenario realista de explotación combinada

Para que se entienda la gravedad real, voy a describir un escenario de explotación completamente realista basado en los tipos de datos filtrados. No es especulación: es exactamente lo que un actor estatal hostil con estos datos podría ejecutar.

Paso 1 - Reconocimiento: Con los datos personales del JEMAD (nombre, DNI, dirección, teléfono), el atacante elabora un perfil completo: rutinas, contactos frecuentes, viajes, reuniones programadas.

Paso 2 - Ampliación del perfil: el atacante completa la ficha con lo que hay en fuentes abiertas y en otras filtraciones — actos públicos, matriculaciones, registros mercantiles, redes sociales de su entorno. (Aquí figuraba el uso de «las credenciales de un agente de la Guardia Civil filtradas en la brecha» para consultar sistemas policiales: no consta que se publicaran credenciales operativas, y ese paso convertía el escenario en algo que no ocurrió.)

Paso 3 - Spear phishing personalizado: Con toda esa información, el atacante envía un email al JEMAD desde una cuenta que simula ser la de un ministro (cuyo email institucional también fue filtrado), adjuntando un documento que aparenta ser un informe del Consejo de Seguridad Nacional. El documento contiene un exploit que instala un implante en el dispositivo del JEMAD.

Paso 4 - Acceso persistente: El implante da acceso a las comunicaciones del JEMAD: emails, mensajes, documentos clasificados, calendarios, contactos. El atacante ahora tiene visibilidad directa sobre la toma de decisiones de seguridad nacional de España.

Paso 5 - Exfiltración estratégica: Durante semanas, el atacante extrae documentos sobre posiciones diplomaticas, planes militares, evaluaciones de amenazas y comunicaciones con aliados de la OTAN. La información se envía a un servidor C2 en un país sin acuerdo de extradicion con España.

Este escenario no requiere tecnología avanzada: le basta con los datos personales ya publicados y con paciencia. Y ésa es la conclusión incómoda del caso — el riesgo de que un alto cargo sea localizado o suplantado no depende de lo bien protegida que esté la red de su organismo, sino del rastro que haya dejado en decenas de servicios privados a lo largo de años. (Aquí se sugería que el escenario «puede que ya se haya ejecutado durante los 100 días de exposición»: eso volvía a atar la publicación al hueco de soporte, que es justo el vínculo que este artículo corrige en su cabecera.)

Análisis técnico profundo: como fallo la protección de Moncloa

Qué es un sistema anti-APT y por qué es crítico

Un sistema anti-APT (Advanced Persistent Threat) es la línea de defensa más sofisticada contra ciberataques dirigidos por actores estatales o grupos de cibercrimen avanzado. No es un antivirus. No es un firewall. Es un ecosistema completo de detección que combina múltiples tecnologías para identificar amenazas que ninguna herramienta individual detectaria.

Para entender por que 100 días sin actualizaciones es catastrofico, primero hay que entender como funciona un sistema anti-APT:

La diferencia crítica: detección por firmas vs detección por comportamiento

Esta distinción es fundamental para entender la gravedad de lo que paso en Moncloa. En mi trabajo como perito forense, cuando analizo una brecha, lo primero que verifico es que capas de detección estaban activas y cuales estaban degradadas.

Detección basada en firmas: funciona como una lista negra. Si el malware coincide con una firma conocida, se bloquea. Es rápida, eficiente y tiene muy pocos falsos positivos. Pero es completamente ciega ante malware nuevo. Si la última firma se actualizo en noviembre de 2025, cualquier malware creado desde diciembre es invisible para el sistema.

Detección por comportamiento: funciona observando que hacen los procesos, no como se llaman. Un proceso que cifra archivos masivamente es sospechoso independientemente de su firma. Esta capa es más resiliente a la falta de actualizaciones, pero también se degrada: los atacantes sofisticados saben como hacer que su malware se comporte de forma “normal” durante las primeras horas, realizando acciones daninas de forma gradual para no disparar alertas conductuales.

La combinación de ambas es lo que hace eficaz a un sistema anti-APT. Sin actualizaciones, la detección por firmas muere inmediatamente. La detección por comportamiento sobrevive parcialmente pero se degrada en semanas. Después de 100 días, la capacidad de detección del sistema esta, en términos prácticos, muerta.

En mi opinion profesional, esto no debería haber ocurrido porque cualquier responsable de ciberseguridad con experiencia sabe que un sistema de detección sin actualizaciones durante más de 30 días es un punto ciego crítico. Mantenerlo operativo durante 100 días da una falsa sensación de seguridad que es peor que no tener ningun sistema: al menos si no tienes sistema sabes que no estas protegido.

Por que 100 días sin actualizaciones es catastrofico

Para ponerlo en perspectiva con datos concretos:

100 días son suficientes para que un atacante sofisticado complete todo el ciclo de un APT: reconocimiento, acceso inicial, establecimiento de persistencia, movimiento lateral, descubrimiento de datos, exfiltración y borrado de huellas. Con un sistema de detección actualizado, al menos una de estas fases debería haber disparado una alerta. Sin actualizaciones, el atacante opera con total impunidad.

El ciclo de ataque que se dio por hecho, y que no ocurrió

Cómo hay que leer lo que sigue. Ésta es la reconstrucción que se hizo en aquellos días asumiendo que la filtración había salido de las redes de Presidencia. No es lo que pasó —no consta intrusión alguna—, y se mantiene por dos motivos: porque explica bien qué habría permitido el hueco de soporte si alguien lo hubiera aprovechado, y porque es un ejemplo útil de cómo una hipótesis coherente puede ser falsa. Todas sus fases encajaban con la cronología conocida. Ninguna ocurrió.

Fase 1 - Reconocimiento (noviembre 2025): Los atacantes detectan que el sistema anti-APT de Moncloa ha dejado de actualizarse. Esto puede hacerse de múltiples formas: escaneo de red que identifica versiones de software, análisis de los headers de las comunicaciones salientes del sistema, o simplemente información privilegiada de alguien con acceso a la cadena de suministro del fabricante. En mi experiencia, los grupos APT monitorizan activamente las cadenas de suministro de los fabricantes de seguridad y están atentos a cambios en las políticas de soporte.

Fase 2 - Acceso inicial (noviembre-diciembre 2025): Con el conocimiento de que el sistema anti-APT esta desactualizado, los atacantes preparan un payload que sería detectado por las firmas de noviembre 2025 pero no por las anteriores. Envian un email de spear-phishing a un funcionario de Moncloa con un adjunto que contiene un exploit para una vulnerabilidad publicada después de la última actualización del sistema. El anti-APT no lo detecta porque no tiene la firma correspondiente. El exploit se ejecuta y establece una conexión de comando y control (C2) con un servidor externo.

Fase 3 - Establecimiento de persistencia (diciembre 2025): Una vez dentro, el atacante instala mecanismos de persistencia: tareas programadas, servicios de Windows, claves de registro, o incluso implantes en el firmware si tiene acceso físico indirecto. La persistencia garantiza que el atacante pueda volver a entrar incluso si se reinician los sistemas o se detecta y elimina el acceso inicial.

Fase 4 - Movimiento lateral (diciembre 2025 - enero 2026): Desde el primer equipo comprometido, el atacante se mueve a otros sistemas de la red interna de Moncloa. Utiliza técnicas living-off-the-land (PowerShell, WMI, PsExec) que no generan alertas porque son herramientas legítimas del sistema. Cada nuevo sistema comprometido amplía el acceso y revela nuevas credenciales, documentos y datos.

Fase 5 - Descubrimiento y exfiltración: con acceso amplio a la red, el atacante mapearía los datos disponibles y sacaría los más valiosos de forma gradual, en paquetes pequeños, para no disparar alertas volumétricas. Es aquí donde la hipótesis se rompe contra los hechos: los datos que se publicaron eran trámites administrativos personales y contraseñas de servicios privados —cosas que Presidencia no custodia—, no documentos internos. Una exfiltración desde sus redes habría producido un material distinto.

Fase 6 - Publicación (26 febrero - 4 marzo 2026): Los atacantes deciden publicar los datos, bien porque han obtenido todo lo que buscaban, porque han sido detectados por el nuevo sistema anti-APT que se despliega a mediados de febrero, o porque la publicación es en si misma parte de su objetivo (desestabilizacion, presión política, demostración de capacidad).

Y ésa es la lección de método que deja el caso. El ciclo de arriba es coherente con la cronología, encaja con los patrones documentados de APT contra gobiernos europeos y tiene una explicación para cada fecha conocida. Era la hipótesis más probable, y era falsa. Lo que la descartó no fue un análisis más fino de la hipótesis, sino mirar el material publicado: cuando aparecen trámites personales que la institución no conserva, el origen está fuera. Contrastar la hipótesis con la evidencia, y no consigo misma, es lo único que la habría desmontado antes.

Las técnicas de evasión que el sistema obsoleto no podía detectar

Para entender la inutilidad práctica de un sistema anti-APT sin actualizaciones durante 100 días, hay que considerar las técnicas específicas que los atacantes pudieron usar sabiendo que el sistema estaba desactualizado:

Living-off-the-land binaries (LOLBins): Herramientas legítimas del sistema operativo (PowerShell, certutil, bitsadmin, mshta) utilizadas para ejecutar código malicioso. Estas técnicas se actualizan constantemente en el framework MITRE ATT&CK y los sistemas anti-APT necesitan reglas nuevas para detectar usos anómalos de estas herramientas. Sin actualizaciones, usos sospechosos de LOLBins pasan completamente desapercibidos.

Fileless malware: Malware que no escribe archivos en disco sino que se ejecuta completamente en memoria. Los sistemas anti-APT detectan fileless malware mediante análisis de comportamiento de procesos en memoria, pero las técnicas de evasión evolucionan rápidamente. Un sistema con firmas de noviembre 2025 no reconoceria las variantes de fileless malware publicadas en diciembre, enero o febrero.

DLL sideloading y DLL hijacking: Técnicas que explotan el orden de carga de librerias dinamicas de Windows para ejecutar código malicioso en el contexto de un proceso legítimo. Los fabricantes de anti-APT anadon continuamente nuevas detecciones para variantes de estas técnicas. Sin esas detecciones, el atacante puede ejecutar su payload como si fuera parte de un proceso confiable.

Abuso de servicios cloud: Uso de servicios cloud legítimos (OneDrive, Google Drive, Azure Blob Storage, AWS S3) como infraestructura de comando y control. El tráfico parece normal porque se dirige a dominios de Microsoft, Google o Amazon. Los sistemas anti-APT actualizados tienen reglas para identificar patrones sospechosos en el uso de estos servicios. Sin actualizaciones, este tráfico C2 se mezcla con el tráfico legítimo y pasa desapercibido.

Tunneling DNS: Exfiltración de datos codificando la información en consultas DNS. Es una técnica antigua pero que sigue siendo efectiva porque muchas organizaciones no monitorizan el tráfico DNS de forma adecuada. Los sistemas anti-APT actualizados tienen modelos de detección de anomalias DNS que identifican patrones de tunneling. Sin actualizaciones, esos modelos no incorporan las últimas técnicas de ofuscación de tunneling DNS.

Cualquiera de estas técnicas habría pasado desapercibida durante los 100 días: el sistema estaba físicamente presente y funcionalmente ciego. Que nadie las usara no cambia el diagnóstico del hueco — el riesgo era real aunque no se materializara, y es la razón por la que el fallo de contratación merece contarse por sí mismo.

En una analogía que suelo usar con mis clientes para explicar la gravedad de la situación: imagina que tienes un sistema de alarma en tu casa, pero las cámaras graban en blanco y negro, los sensores de movimiento solo detectan objetos de más de 100 kilos, y la central de alarmas no recibe la señal desde hace tres meses. La alarma “funciona” técnicamente: enciende una luz cuando la activas, suena cuando pulsas el boton de pánico. Pero no detecta nada real. Eso es exactamente lo que le paso al sistema anti-APT de Moncloa: seguía ejecutándose, generaba dashboards, mostraba graficas. Pero su capacidad real de detección se había degradado hasta la irrelevancia.

Implicaciones para la seguridad nacional de España

Los riesgos de segundo y tercer orden que nadie esta discutiendo

La cobertura mediatica se ha centrado en el hecho de la filtración y en la identidad de los afectados. Pero como perito forense, lo que más me preocupa son los riesgos de segundo y tercer orden que aun no se han materializado pero que son prácticamente inevitables.

Riesgo 1: reutilización de contraseñas antiguas. Entre los datos publicados figuraban contraseñas antiguas procedentes de brechas de servicios privados. No abren ningún sistema del Estado, pero sí abren cualquier cuenta personal donde su titular las haya reutilizado sin cambiarlas — y desde ahí, un correo o un teléfono válidos bastan para intentar un fraude por suplantación contra terceros.

Riesgo 2: inteligencia por agregación, no por intrusión. Los datos del JEMAD y de los miembros del Consejo de Seguridad Nacional no son datos personales ordinarios, pero conviene precisar qué permiten y qué no. Permiten confeccionar un objetivo: quién ocupa cada puesto, dónde vive, con qué número se le localiza. No permiten saber qué se decide en ese consejo ni qué posición se defiende ante la OTAN — eso vive en comunicaciones que no se filtraron. (Aquí figuraba lo segundo como si fuera consecuencia de lo primero.) El valor para un servicio hostil es real y es el del primer tipo: un directorio de objetivos con su dirección.

Riesgo 3: localización física de un objetivo identificado. El dato más sensible de una ficha de este tipo no es una contraseña, sino el domicilio. Frente a un mando policial o militar identificado por su cargo, la publicación de su dirección particular convierte un cargo público en un objetivo localizable, y eso no se revierte cambiando credenciales.

Riesgo 4: presión sobre personas, no acceso a expedientes. Lo publicado sobre personal de la Fiscalía eran datos personales, no información procesal: no hay investigaciones en curso ni estrategias procesales entre lo difundido. (Aquí se afirmaba lo contrario.) El riesgo que sí queda es distinto y no menor: conocer el domicilio y el teléfono de quien instruye un asunto habilita la presión directa sobre esa persona, que es una vía que no necesita acceder a ningún sistema.

Riesgo 5: el daño reputacional depende de que se explique bien lo ocurrido. Este es el riesgo que más se ha exagerado y el más fácil de contener. Si un aliado entiende que hubo una intrusión en los canales españoles, es razonable que reduzca lo que comparte; si entiende que se agregaron filtraciones de operadoras y comercios, el asunto no afecta a la confianza en la infraestructura. La diferencia entre las dos lecturas la marca la comunicación institucional, y en aquellos días fue tardía y ambigua.

Riesgo 6: efecto demostración, pero de una técnica al alcance de cualquiera. El mensaje que envió el episodio no fue «los sistemas españoles son vulnerables», sino algo más incómodo: que se puede confeccionar la ficha completa de un alto cargo sin tocar ningún sistema, solo con paciencia y repositorios de filtraciones antiguas al alcance de cualquiera. Lo demostró después la propia investigación, con la detención de un menor en Granada. Ese efecto de imitación es más difícil de contener que el otro, porque no depende del presupuesto de seguridad de nadie.

La respuesta: un refuerzo cuya cifra conviene tomar con cautela

Se publicó que Moncloa reforzó su ciberseguridad con más de 2 millones de euros. La cifra procede de un único medio digital y no está contrastada con fuente oficial, así que se recoge como lo que es. El detalle de las medidas tampoco se hizo público; lo que sigue es la respuesta que corresponde a un hueco de soporte, que es el problema acreditado:

(Aquí figuraban además un «análisis forense completo de todos los sistemas comprometidos durante la ventana de exposición» y una «rotación de credenciales de todos los usuarios en todos los sistemas gubernamentales». Son la respuesta a una intrusión, y no consta que la hubiera.)

Como analizo más adelante en la sección de respuesta a incidentes, estas medidas son necesarias pero insuficientes si no van acompanadas de cambios estructurales en la gobernanza.

Hay un aspecto económico que merece mención: 2 millones de euros suena a mucho dinero, pero en el contexto de la ciberseguridad gubernamental de un país del G20, es una cantidad modesta. Francia invierte más de 100 millones de euros anuales en la ANSSI. Alemania invierte más de 200 millones en el BSI. Incluso Estonia, con una población de 1,3 millones de personas, invierte más de 10 millones anuales en ciberseguridad gubernamental. Los 2 millones de euros de Moncloa son un parche de emergencia, no una solución estructural. Si esta inversión no se acompaña de un incremento sostenido del presupuesto de ciberseguridad gubernamental, estaremos ante la misma situación en dos o tres años.

El problema de la cadena de suministro: dependencia crítica de un único proveedor

Vendor lock-in en ciberseguridad gubernamental

Lo que ocurrio en Moncloa no es solo un fallo técnico. Es un fallo estructural del modelo de gestión de la ciberseguridad gubernamental española. He visto este mismo patrón en empresas que perito: el proveedor deja de dar soporte y nadie se entera hasta que es demasiado tarde. En el caso de Moncloa, la dependencia de un único fabricante de sistemas anti-APT creo un punto único de fallo que comprometio toda la postura de seguridad de la Presidencia del Gobierno.

El vendor lock-in en ciberseguridad gubernamental funciona así:

1. Contratación inicial: Un organismo público lícita un contrato de ciberseguridad. El fabricante ganador despliega su solución propietaria, con sus propios formatos de logs, sus propias reglas de detección, su propia consola de gestión
2. Dependencia progresiva: Con el tiempo, toda la operativa de seguridad se construye alrededor del sistema del fabricante. Los analistas aprenden su interfaz, las alertas se integran en el SIEM, los procedimientos de respuesta a incidentes se basan en las capacidades del sistema
3. Coste de sustitución creciente: Cambiar de fabricante implica reentrenar al personal, rehacer las integraciones, reescribir los procedimientos y asumir un periodo de transicion con cobertura reducida
4. Asimetría de poder: El fabricante sabe que sustituirlo es costoso y complejo. Esto le da capacidad de negociación sobre precios, condiciones de soporte y plazos

En el caso de Moncloa, cuando el fabricante dejo de proporcionar actualizaciones en noviembre de 2025, el Gobierno se encontro con que no tenía alternativa inmediata. El proceso de contratación pública para sustituir el sistema tardo meses. Mientras tanto, la Presidencia del Gobierno estuvo sin protección avanzada contra amenazas.

Lo que exige NIS2 sobre cadena de suministro

La Directiva NIS2 incluye, en su artículo 21.2.d, la seguridad de la cadena de suministro entre las medidas de gestión de riesgos que deben adoptar las entidades de su ámbito (Directiva (UE) 2022/2555, EUR-Lex). Es una de las áreas que la UE considera críticas, dada la dependencia de proveedores tecnológicos.

El artículo 21.2.d se refiere a una categoría de medida, no a una lista literal de obligaciones; su concreción depende de la transposición nacional, y que una administración pública central quede dentro del ámbito lo define cada Estado en su anexo (el art. 2.7 excluye además determinadas actividades de seguridad nacional). En la práctica, la gestión de la cadena de suministro suele traducirse en medidas como:

• Evaluación de riesgos de proveedores: Analizar la postura de seguridad de cada proveedor crítico, incluyendo su capacidad para mantener la continuidad del servicio
• Cláusulas contractuales de seguridad: Los contratos con proveedores deben incluir requisitos de ciberseguridad, obligaciones de notificación de incidentes y garantías de continuidad de servicio
• Monitorización continua de proveedores: No basta con evaluar al proveedor al inicio del contrato. Hay que monitorizar su estado de seguridad durante toda la relación contractual
• Planes de contingencia: Procedimientos documentados para actuar cuando un proveedor falla, incluyendo alternativas precontratadas o medidas compensatorias temporales
• Diversificacion de proveedores críticos: Evitar puntos únicos de fallo. Si un proveedor falla, debe existir una alternativa que pueda activarse en un plazo razonable
• Cláusulas de salida y portabilidad: Los contratos deben garantizar que al finalizar la relación, los datos, logs y configuraciones pueden migrarse a la nueva solución sin pérdida de información ni de continuidad operativa

En mi experiencia pericial, una buena gestión de la cadena de suministro es justo lo que falló en Moncloa. No es un requisito abstracto: es una práctica operativa que, de haberse aplicado, podría haber reforzado la continuidad del sistema y hecho menos probable un hueco de tres meses. No puede afirmarse que lo hubiera impedido con certeza —eso sería un contrafactual indemostrable—, pero sí que habría reducido el riesgo.

Si España hubiera transpuesto NIS2 a tiempo (antes de octubre de 2024), el marco habría empujado a las entidades de su ámbito a dotarse de planes de contingencia para escenarios como éste. No es una relación mecánica —un marco vigente no impide por sí solo cada incidente—, pero sí eleva el nivel exigible de gestión del riesgo.

Puntos únicos de fallo en la ciberseguridad española

El caso Moncloa no es un incidente aislado. Es sintomatico de un problema más amplio en la gestión de la ciberseguridad gubernamental española: la concentración de capacidades críticas en un número reducido de proveedores.

En mis peritajes para empresas del sector público, he identificado repetidamente este patrón:

• Un único fabricante de anti-APT protege múltiples ministerios y organismos
• Un único integrador de seguridad gestiona los SOC de varias administraciones públicas
• Un único proveedor de cloud aloja los sistemas críticos de varias entidades
• Escasez de personal especializado que dificulta la diversificacion y la supervisión independiente

Cuando cualquiera de estos puntos falla, el impacto se multiplica. Y como he visto en mis investigaciones, los atacantes lo saben: identifican al proveedor común y dirigen sus ataques a ese punto de concentración para comprometer múltiples objetivos con un solo ataque.

He peritado un caso que ilustra perfectamente este riesgo. Una empresa de servicios gestionados de ciberseguridad (MSSP) que proporcionaba SOC a 23 PYMEs fue comprometida a traves de una vulnerabilidad en su plataforma de gestión remota. El atacante no tuvo que hackear 23 empresas: hackeo una y obtuvo acceso a las 23. En 48 horas, desplegó ransomware en los sistemas de 17 de los 23 clientes, porque las credenciales de administración remota del MSSP daban acceso directo a todos ellos.

El paralelo con Moncloa es evidente: si un único fabricante protege la Presidencia del Gobierno y otros ministerios, y ese fabricante falla o deja de dar soporte, todos los organismos protegidos por ese fabricante quedan simultáneamente expuestos. La diversificacion no es un lujo: es una necesidad operativa.

El dilema de la contratación pública en ciberseguridad

Hay un aspecto del vendor lock-in gubernamental que es específico del sector público y que rara vez se discute: la Ley de Contratos del Sector Público (Ley 9/2017) impone procedimientos de contratación que, aunque necesarios para la transparencia y la competencia, pueden ser incompatibles con la velocidad que requiere la ciberseguridad.

Un procedimiento abierto de contratación pública tarda entre 3 y 6 meses desde la publicación del pliego hasta la adjudicacion del contrato. Si le sumamos el periodo de preparación del pliego (1-2 meses), las posibles impugnaciones (2-3 meses adicionales) y el despliegue de la nueva solución (1-2 meses), el tiempo total puede superar los 12 meses.

Esto significa que si una organización pública necesita sustituir un sistema de ciberseguridad crítico, necesita empezar el proceso al menos 12 meses antes de que el sistema actual deje de recibir soporte. Si el fabricante anuncia el fin de soporte con 6 meses de antelacion (que ya es poco habitual), la organización pública no tiene tiempo suficiente para completar el proceso de contratación antes de quedarse sin protección.

Existen mecanismos de contratación de emergencia (artículo 120 de la Ley 9/2017) para supuestos tasados —acontecimientos catastróficos, situaciones de grave peligro o necesidades de la defensa nacional—. Determinar si ese cauce era aplicable a la sustitución de un sistema cuyo fin de soporte se conocía con antelación exige un análisis del expediente que este artículo no aporta; en cualquier caso, una urgencia previsible encaja mal con el supuesto de emergencia.

Este dilema no tiene solución fácil, pero si tiene una solución práctica: anticipación. Las cláusulas contractuales de todos los sistemas de seguridad críticos deberían incluir:

• Obligación del fabricante de comunicar cualquier cambio en la política de soporte con un mínimo de 18 meses de antelacion
• Cláusulas de continuidad que obliguen al fabricante a mantener actualizaciones durante el periodo de transicion
• Contratos marco preaprobados con fabricantes alternativos que puedan activarse de forma rápida en caso de necesidad
• Evaluación anual del ciclo de vida de todos los productos críticos con alerta automática a 18, 12 y 6 meses del fin de soporte

Comparación internacional: como protegen otros países europeos a sus gobiernos

Para entender la magnitud del fallo de Moncloa, es útil comparar como gestionan otros países europeos la ciberseguridad de sus gobiernos. España no esta sola en enfrentar amenazas, pero si esta significativamente por detras de sus pares en capacidad de respuesta y gobernanza.

Modelos de referencia en Europa

Francia - ANSSI (Agence Nationale de la Securite des Systemes d’Information)

La ANSSI francesa es, en mi opinion profesional, el modelo de referencia en Europa para la ciberseguridad gubernamental. Depende directamente del Primer Ministro a traves de la Secretaría General de Defensa y Seguridad Nacional. Cuenta con más de 600 empleados especializados y un presupuesto anual de más de 100 millones de euros. La ANSSI tiene autoridad para imponer requisitos de seguridad a todos los ministerios y puede intervenir directamente en la respuesta a incidentes. Su modelo de “calificación” de productos de seguridad obliga a los organismos públicos a usar solo soluciones certificadas, lo que reduce el riesgo de vendor lock-in al existir múltiples productos calificados.

Alemania - BSI (Bundesamt fur Sicherheit in der Informationstechnik)

El BSI aleman tiene un enfoque más técnico y normativo. Con más de 1.500 empleados, el BSI pública estándares de seguridad (IT-Grundschutz) que son obligatorios para toda la administración federal. El BSI opera un CERT gubernamental dedicado con capacidad de respuesta 24/7 y mantiene un catálogo de productos de seguridad aprobados con múltiples proveedores por categoría. Alemania aprobó su ley de transposición de NIS2 (NIS2UmsuCG), que entró en vigor el 6 de diciembre de 2025 (Gobierno federal alemán).

Reino Unido - NCSC (National Cyber Security Centre)

El NCSC britanico, parte del GCHQ, combina inteligencia de señales con capacidad operativa de ciberseguridad. El programa Active Cyber Defence protege automáticamente millones de conexiones gubernamentales. El NCSC pública guías prácticas (como el Cyber Essentials) y opera un servicio de alerta temprana que notifica a las organizaciones cuando detecta amenazas dirigidas contra ellas. Su modelo de “seguridad por defecto” significa que los ministerios reciben protección base sin necesidad de contratarla individualmente.

Estonia - RIA (Riigi Infosusteem Amet)

Incluyo a Estonia porque, a pesar de ser un país pequeño, es el referente europeo en ciberseguridad gubernamental desde que sufrio los ciberataques masivos de 2007 atribuidos a Rusia. Tras esos ataques, Estonia creo un ecosistema de ciberseguridad que incluye: una infraestructura digital distribuida (X-Road) diseñada para ser resiliente a ataques, un sistema de respaldo completo de datos gubernamentales en una “embajada de datos” en Luxemburgo, ejercicios anuales de ciberdefensa a gran escala (Locked Shields, organizados por el NATO CCDCOE con sede en Tallin), y una obligación legal de que todos los sistemas gubernamentales cumplan con el estándar ISKE (equivalente estonio del ENS pero con auditorias de cumplimiento más rigurosas y frecuentes).

Lo que Estonia demostro es que el tamaño del país no determina la calidad de su ciberseguridad. Lo que determina es la voluntad política y la priorizacion de recursos. Estonia invierte el 0,5% de su PIB en ciberseguridad gubernamental, un porcentaje significativamente mayor que el de España. Y lo más relevante: Estonia sufrio un ciberataque catastrofico en 2007 y lo uso como catalizador para transformar completamente su postura de ciberseguridad. La pregunta es si España hará lo mismo con el caso Moncloa, o si este incidente se olvidará en semanas y nada cambiará estructuralmente.

Países Bajos - NCSC-NL

Otro modelo relevante es el de los Países Bajos. Su NCSC-NL tiene una particularidad interesante: pública informes detallados de incidentes de ciberseguridad en organismos gubernamentales, incluyendo las causas raiz y las medidas adoptadas. Esta transparencia no debilita la seguridad: la refuerza, porque permite que otros organismos aprendan de los errores ajenos. Si España adoptara un modelo similar de transparencia, el caso Moncloa podría servir para mejorar la ciberseguridad de toda la administración pública. Sin transparencia, cada organismo esta condenado a cometer los mismos errores.

Tabla comparativa: España vs pares europeos

La diferencia es notable. Mientras Francia, Alemania y el Reino Unido tienen agencias autónomas con autoridad directa sobre la seguridad de sus gobiernos, presupuestos dedicados y capacidad operativa propia, España depende de un modelo fragmentado donde el CCN-CERT opera bajo el paraguas del CNI con recursos limitados y sin autoridad para imponer estándares a otros ministerios.

Lo que España podría aprender de cada modelo

De Francia: La autoridad de imposición. Cuando la ANSSI detecta una vulnerabilidad crítica en un sistema de un ministerio, puede ordenar su remediación inmediata. No necesita pedir permiso ni coordinar con nadie. Si la ANSSI hubiera tenido jurisdicción sobre Moncloa, habría obligado a sustituir el sistema anti-APT el mismo día que el fabricante dejo de actualizarlo, o habría impuesto medidas compensatorias inmediatas. En España, el CCN-CERT puede recomendar pero no puede obligar. Y las recomendaciones, como hemos visto, no siempre se siguen.

De Alemania: El marco normativo obligatorio. El IT-Grundschutz del BSI no es una guía de buenas prácticas: es un estándar obligatorio para toda la administración federal. Cada organismo debe certificar su cumplimiento periódicamente. Si Moncloa estuviera sujeta a un estándar equivalente, la obsolescencia del sistema anti-APT habría sido detectada en la auditoría de cumplimiento trimestral. En España, el Esquema Nacional de Seguridad (ENS) existe pero su cumplimiento y auditoría son desiguales entre organismos.

Del Reino Unido: La protección automática y centralizada. El programa Active Cyber Defence del NCSC protege automáticamente a todos los dominios gubernamentales (.gov.uk) contra amenazas comunes: phishing, malware, DNS malicioso. Los ministerios reciben esta protección sin necesidad de contratarla ni gestionarla individualmente. Si España tuviera un programa equivalente, habría proporcionado una capa base de protección durante los 100 días sin anti-APT, reduciendo significativamente la superficie de ataque.

En mi opinion profesional, España necesita una agencia de ciberseguridad gubernamental con tres características que hoy no tiene: autonomia organizativa (no depender del CNI), autoridad de imposición (poder obligar a los organismos a cumplir estándares de seguridad) y presupuesto dedicado y suficiente (no sujeto a las restricciones presupuestarias de otros organismos). Sin estas tres condiciones, seguiremos viendo incidentes como el de Moncloa.

Análisis político e institucional: quien es responsable

La fragmentación de la ciberseguridad española

Uno de los problemas estructurales que este incidente pone de manifiesto es la fragmentación de competencias en materia de ciberseguridad en España. No existe un único organismo con autoridad clara y recursos suficientes para proteger toda la administración pública.

CCN-CERT (Centro Criptológico Nacional): Depende del CNI y es el CERT de referencia para las administraciones públicas. Pero su capacidad operativa esta limitada por el hecho de que depende del Centro Nacional de Inteligencia, cuya prioridad es la inteligencia, no la ciberseguridad operativa de los ministerios. El CCN-CERT emite guías y alertas, pero no tiene autoridad para imponer medidas a Moncloa o a cualquier otro ministerio.

DTIC (Departamento de Tecnologías de la Información y las Comunicaciones): Dependiente de Presidencia del Gobierno, es el organismo que gestiona la infraestructura tecnológica de Moncloa. Es, presumiblemente, quien contrato el sistema anti-APT que dejo de funcionar y quien debería haber detectado la caducidad del soporte. La pregunta obvia es: sabia DTIC que el sistema llevaba 100 días sin actualizaciones y, si lo sabia, por que no activo un plan de contingencia?

DSN (Departamento de Seguridad Nacional): Asesora al Presidente del Gobierno en materia de seguridad nacional. Debería haber sido alertado de que un sistema crítico de ciberseguridad de Moncloa estaba degradado. Si no fue informado, hay un fallo de comunicación interna grave. Si fue informado y no actuo, hay un fallo de gobernanza aun más grave.

INCIBE: Dependiente del Ministerio de Transformación Digital, es el CERT de referencia para ciudadanos y empresas, no para la administración pública. No tiene competencia directa sobre la ciberseguridad de Moncloa.

Mando Conjunto del Ciberespacio (MCCE): Dependiente del Ministerio de Defensa, es responsable de la ciberdefensa militar. Su competencia se limita al ámbito de las Fuerzas Armadas, aunque la filtración de datos del JEMAD debería haberlo involucrado.

Esta fragmentación es, en mi opinion profesional, la raiz del problema. No existe un único responsable con autoridad, presupuesto y capacidad operativa para garantizar la ciberseguridad de toda la administración pública española. Cada organismo depende de un ministerio diferente, con prioridades diferentes y sin obligación de coordinarse de forma efectiva.

La brecha entre la retórica y la realidad

España ha publicado dos Estrategias Nacionales de Ciberseguridad (2013 y 2019) y ha participado activamente en foros europeos de ciberseguridad. Pero la brecha entre la retórica institucional y la realidad operativa es enorme. Un gobierno que no es capaz de mantener actualizado su propio sistema anti-APT durante 100 días no esta en posición de liderar la ciberseguridad europea ni de exigir a las empresas privadas que cumplan con estándares que el mismo incumple.

Este no es un problema nuevo. En los últimos 18 meses hemos visto una serie de incidentes que demuestran un patrón sistemático de debilidad en la ciberseguridad institucional española:

• La brecha de datos de la Policía Nacional que expuso información de unidades antiterroristas
• La multa de 10.043.002 euros de la AEPD a AENA por el uso de reconocimiento facial en aeropuertos sin haber hecho la evaluación de impacto (art. 35 RGPD)
• El ciberataque a la bolsa de vivienda de Barcelona que expuso 6.800 datos personales
• El hackeo al sistema de la Comisión Nacional del Mercado de Valores que obligo a suspender operaciones durante horas

Cada uno de estos incidentes se presento como un caso aislado. Pero cuando los analizas en conjunto, como hago en mis informes periciales, el patrón es claro: falta de inversión, fragmentación de competencias, ausencia de un marco legal actualizado y una cultura institucional que trata la ciberseguridad como un gasto y no como una inversión.

La responsabilidad política

Una pregunta que nadie ha planteado públicamente pero que como perito considero fundamental: quien tomo la decisión de no activar un plan de contingencia cuando el sistema anti-APT dejo de recibir actualizaciones en noviembre de 2025? Alguien en la cadena de mando tuvo que saber que el sistema estaba degradado. O peor: nadie lo supo, lo que significaria que no había ningun mecanismo de supervisión operativa sobre los sistemas de seguridad de la Presidencia del Gobierno.

En cualquiera de los dos escenarios, hay una responsabilidad política que no se puede eludir. Si alguien sabia y no actuo, hay negligencia. Si nadie sabia, hay incompetencia organizativa. Y en ambos casos, los ciudadanos españoles cuya seguridad nacional depende de estos sistemas merecen una explicación pública y un plan concreto para que no vuelva a ocurrir.

La necesidad de un CISO nacional

Una de las conclusiones más claras de este incidente es que España necesita un responsable nacional de ciberseguridad con autoridad ejecutiva real. Actualmente, las competencias de ciberseguridad están repartidas entre el CCN-CERT (CNI), el INCIBE (Ministerio de Transformación Digital), el MCCE (Ministerio de Defensa) y el DSN (Presidencia del Gobierno). Ninguno tiene autoridad sobre los otros. Ninguno tiene un presupuesto dedicado suficiente. Y como demuestra el caso Moncloa, ninguno fue capaz de prevenir una brecha en la máxima institucion del Estado.

Lo que España necesita es una figura equivalente al National Cyber Director de Estados Unidos o al directeur general de la ANSSI francesa: un responsable único con autoridad sobre la ciberseguridad de toda la administración pública, con acceso directo al Presidente del Gobierno y con un presupuesto dedicado que no dependa de las prioridades presupuestarias de otros ministerios.

Esta figura debería tener la capacidad de:

• Imponer estándares mínimos de seguridad a todos los organismos públicos
• Auditar el cumplimiento de esos estándares de forma periódica e independiente
• Activar protocolos de emergencia cuando detecte situaciones de riesgo como la que precedio a la brecha de Moncloa
• Coordinar la respuesta a incidentes de seguridad nacional a traves de todos los organismos afectados
• Representar a España en foros internacionales de ciberseguridad con autoridad y credibilidad

Sin esta figura, seguiremos dependiendo de un modelo de coordinacion voluntaria donde cada organismo gestiona su ciberseguridad de forma independiente y donde nadie tiene la autoridad para imponer medidas cuando un sistema crítico esta en riesgo. El resultado de ese modelo es exactamente lo que hemos visto en Moncloa: 100 días sin protección avanzada y una exposición de datos personales de altos cargos.

La investigación de la UE: procedimiento de infracción por NIS2

Qué significa la investigación de la UE

Este incidente no ocurre en el vacio. La UE ya estaba investigando a España por no transponer la Directiva NIS2, la normativa europea de ciberseguridad que debería haberse incorporado al ordenamiento jurídico español antes de octubre de 2024. España acumula más de 16 meses de retraso en una de las directivas más críticas para la seguridad digital del continente.

El procedimiento de infracción paso a paso

La Comisión Europea ha abierto un procedimiento de infracción contra España (y contra otros 22 Estados miembros) por no transponer NIS2 en plazo. Este es el proceso y lo que puede pasar:

El endurecimiento frente a los retrasos de transposición

La Comisión Europea ya no es tolerante con los retrasos en la transposición: en los últimos años ha llevado ante el TJUE a Estados que no incorporaron directivas en plazo, y el Tribunal puede imponer una suma a tanto alzado y una multa coercitiva diaria. No se reproducen aquí importes de precedentes concretos que no puedan enlazarse a su asunto y sentencia.

En el caso de NIS2, la Comisión ya acordó remitir a España al TJUE el 8 de julio de 2026 (Comisión Europea), de modo que el procedimiento ya está en su fase judicial.

Las sanciones que puede imponer el TJUE

El cálculo de las sanciones del TJUE combina la gravedad de la infracción, su duración y la capacidad de pago del Estado. La Comisión publica cada año los parámetros actualizados, así que no hace falta un cálculo casero a partir del PIB:

Conviene subrayar que no es una deuda ya devengada: la Comisión propone y el Tribunal decide si impone sanción y en qué cuantía. No procede sumar un «total» como si la multa se acumulara día a día.

El estado del anteproyecto español

España esta trabajando en la Ley de Coordinación y Gobernanza de la Ciberseguridad, que transpondria NIS2 al ordenamiento jurídico español. El anteproyecto fue aprobado por el Consejo de Ministros pero sigue pendiente de tramitación parlamentaria. Dadas las dinamicas políticas actuales, con un gobierno en minoría, no hay garantía de que la ley se apruebe en los próximos meses.

La ironia es que esta ley habría obligado a Moncloa a implementar exactamente las medidas que habrían prevenido esta brecha: gestión de riesgos en la cadena de suministro, continuidad de los sistemas de detección, planes de contingencia para proveedores críticos y notificación temprana de incidentes.

El caso Moncloa y el procedimiento de infracción

El caso Moncloa se ha leído a menudo como un agravante del retraso español en NIS2. Conviene ser preciso: lo ocurrido fue una publicación de datos por agregación, no una intrusión en las redes de Presidencia, y no consta que esté causalmente ligado a las carencias que NIS2 pretende cubrir. Lo que sí ilustra el hueco de soporte anti-APT es el tipo de riesgo de gestión que un marco como NIS2 busca reducir.

La Comisión Europea no ha relacionado públicamente el episodio con el procedimiento de infracción, y no debería inferirse esa relación: presentar el caso como la «materialización» del riesgo de NIS2 sería justo el vínculo causal que este artículo corrige.

El retraso en la transposición, por sí mismo, sostiene los argumentos habituales de la Comisión ante el TJUE:

1. Urgencia de la transposición: el marco lleva más de año y medio sin incorporarse, en un ámbito que la UE considera crítico
2. Necesidad de sanciones disuasorias: una multa significativa incentiva que España y otros Estados rezagados prioricen la transposición

Lo que no cabe usar como argumento es presentar el episodio de Moncloa como «daño causado por la no transposición»: su origen —agregación de brechas de terceros— no está ligado a las carencias que NIS2 cubre.

5 lecciones detalladas para organizaciones, desde la experiencia pericial

Llevo años elaborando informes periciales para empresas que han sufrido brechas similares. El caso Moncloa ofrece lecciones directamente aplicables a cualquier organización que dependa de sistemas de ciberseguridad gestionados por terceros. Lo que le ha pasado al Gobierno de España le puede pasar a cualquier PYME que deje caducar su antivirus.

Lección 1: La cadena de suministro tecnológica es un vector crítico

Si el fabricante de tu solución de seguridad deja de dar soporte, tu organización queda expuesta. He peritado el caso de una empresa de logística en Andalucía que sufrio un ransomware tres semanas después de que su proveedor de EDR fuera adquirido por otra empresa y cesara temporalmente las actualizaciones. Nadie en la empresa sabia que el sistema estaba degradado. El ransomware cifro todos los servidores de producción y la empresa perdio dos semanas de facturación.

Lo que las empresas deben hacer:

• Monitorizar el ciclo de vida de todos los productos de seguridad desplegados. Configurar alertas para 12 meses, 6 meses y 3 meses antes del fin de soporte anunciado
• Planificar la sustitución con al menos 6 meses de antelacion al fin de soporte. No esperar a que el fabricante deje de actualizar para empezar a buscar alternativas
• Diversificar proveedores para evitar puntos únicos de fallo. Si tu anti-APT es de un fabricante, tu EDR debería ser de otro. Si ambos son del mismo, un único fallo compromete ambas capas
• Incluir cláusulas de transicion en los contratos: el fabricante debe mantener actualizaciones hasta que el sustituto este completamente operativo
• Mantener un registro centralizado de todos los productos de seguridad con sus fechas de fin de soporte, responsable asignado y plan de sustitución documentado

He elaborado un modelo de hoja de seguimiento que recomiendo a todos mis clientes de peritaje preventivo:

Si Moncloa hubiera tenido esta tabla actualizada, el “0 meses restantes” del anti-APT habría disparado una alarma inmediata. El hecho de que no la tuvieran (o de que la tuvieran y la ignoraran) es en si mismo un indicador de la falta de madurez en la gestión de ciberseguridad.

Lección 2: La continuidad contractual no es negociable

El gap entre el fin de soporte del fabricante y la formalización del nuevo contrato fue la causa directa de la exposición en Moncloa. He visto este patrón en al menos cinco peritajes en los últimos dos años: el contrato de seguridad caduca, el departamento de compras tarda semanas o meses en formalizar la renovación o la sustitución, y durante ese periodo la empresa esta desprotegida.

En un caso que perite para un despacho de abogados de Madrid, el contrato de su firewall de nueva generación caduco en agosto. El proveedor dejo de actualizar las firmas. El departamento de IT no se dio cuenta hasta octubre, cuando un phishing sofisticado comprometio las credenciales de dos socios. El atacante accedio a expedientes de clientes durante tres semanas antes de que se detectara la intrusión. El despacho se enfrento a reclamaciones de sus clientes por violación de la confidencialidad abogado-cliente, una reclamación ante la AEPD y un daño reputacional que le costo varios clientes importantes.

En otro caso, una empresa del sector energetico en Andalucía tenía un contrato de mantenimiento de su SIEM con una empresa de servicios gestionados. El contrato vencio en diciembre y la renovación se retraso por una disputa sobre el precio. La empresa de servicios gestionados dejo de monitorizar las alertas el 1 de enero. Durante los 45 días que tardo en resolverse la disputa, un atacante comprometio la red OT (Operational Technology) de la empresa, que controla infraestructura crítica. El incidente pudo haber tenido consecuencias físicas además de digitales. Cuando me contrataron para el peritaje, determine que el atacante había entrado el 8 de enero, solo una semana después de que cesara la monitorización. La evidencia sugeria que el atacante había estado esperando exactamente ese momento.

La lección para las empresas es clara: si un despacho de abogados de Madrid y una empresa del sector energetico de Andalucía pueden sufrir brechas por gaps contractuales, cualquier organización puede. Y el patrón es siempre el mismo: el contrato vence, hay un periodo sin cobertura, y el atacante lo aprovecha. La solución no es tecnológica: es contractual y organizativa.

Los contratos de ciberseguridad deben incluir:

• Cláusulas de continuidad de servicio hasta la transicion efectiva a la nueva solución, con SLA mínimo de respuesta ante amenazas críticas durante la transicion
• Penalizaciones económicas por interrupcion unilateral del soporte sin preaviso suficiente (mínimo 12 meses de preaviso para contratos anuales, 18 meses para contratos plurianuales)
• Planes de contingencia documentados y probados al menos una vez al año, que incluyan escenarios de pérdida total de soporte del proveedor
• Derecho de auditoría sobre el estado de las actualizaciones del proveedor, ejercitable sin previo aviso al menos una vez por trimestre
• Cláusula de notificación inmediata si el proveedor sufre un incidente de seguridad que pueda afectar a la protección del cliente

Lección 3: La detección debe ser continua, sin excepciones

Un sistema anti-APT sin actualizaciones es como no tener sistema. Peor aun: es como tener un sistema que te da una falsa sensación de seguridad. La falsa sensación de seguridad es, en mi experiencia profesional, más peligrosa que la ausencia total de protección, porque lleva a comportamientos de riesgo que no se adoptarian si se supiera que no hay protección.

He peritado un caso donde una empresa de comercio electrónico tenía un SIEM que llevaba meses sin recibir logs de uno de sus servidores críticos porque la integración se rompio tras una actualización del sistema operativo. Nadie verifico que los logs seguian llegando. Cuando un atacante comprometio ese servidor, no hubo ninguna alerta porque el SIEM simplemente no lo estaba monitorizando. El atacante estuvo dentro 4 meses, exfiltro datos de 23.000 clientes incluyendo tarjetas de crédito, y la empresa se entero cuando Visa les contacto por un patrón de fraude anormalmente alto en tarjetas de sus clientes.

En otro caso, una clinica dental en Valencia tenía un antivirus que había dejado de actualizarse porque la tarjeta de crédito asociada al pago anual había caducado. El proveedor envio tres avisos por email, pero iban al buzón de la persona que había configurado la cuenta y que ya no trabajaba en la clinica. El antivirus mostro un aviso en pantalla durante dos semanas, pero el personal lo ignoro pensando que era publicidad. Un ransomware cifro todos los historiales clinicos de 8.000 pacientes. La clinica pago un rescate de 12.000 euros y aun así perdio los datos de los últimos 3 meses porque los backups también estaban en la misma red y fueron cifrados.

Las organizaciones deben verificar de forma continua:

• Que las actualizaciones de firmas e IoC se aplican diariamente. Configurar alertas si las actualizaciones no se reciben en 24 horas
• Que los feeds de inteligencia de amenazas están activos y proporcionando datos actualizados
• Que el personal de seguridad recibe alertas operativas del sistema. Si las alertas dejan de llegar, no significa que no haya amenazas: puede significar que el sistema ha dejado de funcionar
• Que los dashboards de monitorización se revisan diariamente. Un dashboard vacio no es un dashboard sano: puede ser un dashboard desconectado
• Que existe un mecanismo de “dead man’s switch”: si el sistema de seguridad no reporta actividad durante más de 24 horas, se genera automáticamente una alerta de nivel crítico

El concepto de “dead man’s switch” es algo que recomiendo a todos mis clientes. La idea es simple: si tu sistema de seguridad esta funcionando correctamente, debería estar generando alertas, logs y reportes de forma continua. Si deja de hacerlo, no significa que no haya amenazas: significa que algo esta mal con el sistema. Configurar una alerta que se dispare cuando el sistema deja de reportar es una medida simple que habría detectado la obsolescencia del sistema anti-APT de Moncloa en las primeras 24 horas, no 100 días después.

Lección 4: El presupuesto de ciberseguridad no puede ser reactivo

Moncloa invirtio más de 2 millones de euros después del incidente. El coste de haber mantenido la continuidad del sistema anti-APT habría sido una fracción de esa cifra.

En mi experiencia como perito, las empresas que invierten reactivamente siempre pagan más. He visto a empresas gastar 10 veces más en la respuesta a un incidente de lo que habría costado prevenirlo. Y no me refiero solo al coste técnico: el coste reputacional, el coste legal, las horas de trabajo perdidas, la interrupcion del negocio y el daño a la confianza de los clientes multiplican el impacto económico por un factor de 3 a 5 veces sobre el coste técnico directo.

Los informes del sector coinciden en que una brecha cuesta bastante más que la prevención que la habría evitado, aunque las cifras varían por metodología y no siempre aíslan el sector público con la precisión que se les atribuye. El principio se sostiene sin necesidad de una cifra concreta: mantener un sistema de detección con soporte activo cuesta una fracción de lo que cuesta responder a un incidente grave.

Un ejemplo concreto de mi práctica profesional: una empresa industrial de Jaen me contrato para peritar un incidente de ransomware. El atacante había entrado por una vulnerabilidad conocida en un servidor VPN que llevaba 8 meses sin parchear. El parche estaba disponible desde el día siguiente a la publicación de la vulnerabilidad. Aplicarlo habría costado 2 horas de trabajo de un técnico. En cambio, la empresa gasto más de 180.000 euros en respuesta al incidente, perdio 12 días de producción y sufrio un daño reputacional que le costo dos contratos con clientes importantes. Dos horas de trabajo preventivo habrían evitado 180.000 euros de daño. Ese es el ratio real de la prevención.

Lección 5: La respuesta a incidentes debe estar preparada antes del incidente

El análisis forense digital posterior a un ataque solo puede recuperar evidencia que se haya preservado. Sin sistemas de detección activos durante 100 días, la cantidad de evidencia forense disponible se reduce drásticamente.

He peritado casos donde la empresa afectada no tenía logs de red de los 90 días previos al incidente porque su sistema de retención de logs estaba configurado con un periodo de 30 días. Cuando el atacante fue detectado tras 4 meses de permanencia, solo teniamos visibilidad del último mes. Los 3 meses anteriores eran un agujero negro forense. No pudimos determinar por donde entro el atacante, que datos exfiltro durante los primeros meses, ni cuantos sistemas comprometio antes de ser detectado.

He peritado un caso donde una empresa de servicios financieros sufrio una brecha y me llamo 72 horas después del incidente. Para entonces, el equipo interno de IT ya había reinstalado los servidores comprometidos “para volver a la normalidad lo antes posible”. Al reinstalar, destruyeron la evidencia forense: imágenes de disco, memoria RAM, artefactos del atacante, logs locales. Mi capacidad para determinar el vector de entrada, el alcance real del compromiso y los datos exfiltrados quedo severamente limitada. El informe pericial que pude emitir fue mucho menos concluyente de lo que habría sido si me hubieran llamado antes de tocar los sistemas. La empresa termino pagando la multa máxima de la AEPD porque no pudo demostrar que había tomado medidas adecuadas para proteger los datos.

Las organizaciones necesitan:

• Un plan de respuesta a incidentes documentado y ensayado al menos dos veces al año, que incluya explícitamente la instrucción de NO reinstalar ni modificar los sistemas comprometidos hasta que un forense los haya analizado
• Retenciones de logs configuradas a un mínimo de 12 meses. Para datos críticos, 24 meses. Almacenados en un sistema independiente que el atacante no pueda alcanzar
• Contacto previo con un perito informático forense para activar en caso de incidente. Buscar un perito después de sufrir la brecha implica perder horas críticas en las que la evidencia se degrada
• Backups inmutables verificados periódicamente. Los atacantes sofisticados buscan y destruyen los backups antes de activar el ransomware. Los backups deben estar en un sistema desconectado o inmutable (write-once, read-many)
• Segmentación de red que limite el movimiento lateral del atacante. Si cada departamento esta en su propia VLAN con controles de acceso entre ellas, comprometer un segmento no da acceso automático a todos los demas

Qué debería hacer Moncloa ahora: respuesta a incidentes basada en ISO 27035 y NIST CSF

Basandome en mi experiencia pericial y en los marcos de referencia ISO 27035 (gestión de incidentes de seguridad de la información) y NIST Cybersecurity Framework, estas son las 8 acciones que Moncloa debería ejecutar de forma inmediata. Algunas es probable que ya esten en marcha, pero como perito, considero crítico que se completen todas:

Mi valoración personal de la respuesta de Moncloa

Siendo directo: la inversión de 2 millones de euros en refuerzo de ciberseguridad es necesaria pero insuficiente si no va acompanada de un cambio estructural en la gobernanza de la ciberseguridad gubernamental. He visto a empresas gastar cantidades similares tras un incidente para comprar tecnología nueva, sin cambiar los procesos ni las personas que permitieron que el incidente ocurriera. Seis meses después, sufren otra brecha porque la tecnología nueva se gestiona con los mismos procesos defectuosos.

Lo que necesita Moncloa no es solo un nuevo sistema anti-APT. Necesita:

• Un responsable de ciberseguridad (CISO) con autoridad real y acceso directo al Presidente, no enterrado bajo tres niveles de burocracia en el DTIC
• Auditorias de seguridad trimestrales independientes, no realizadas por el mismo equipo que gestiona los sistemas
• Simulacros de incidentes (tabletop exercises) al menos dos veces al año, con participación de los altos cargos afectados
• Un protocolo de escalado automático cuando un sistema crítico de seguridad pierde actualizaciones durante más de 7 días
• Cláusulas contractuales con todos los proveedores de seguridad que incluyan obligaciones de continuidad y penalizaciones por interrupcion

Sin estos cambios estructurales, la inversión de 2 millones de euros solo compra tiempo hasta el próximo incidente.

Qué deben aprender las empresas: checklist de gestión de proveedores de seguridad

El caso Moncloa tiene implicaciones directas para cualquier empresa que dependa de proveedores de ciberseguridad. Esta checklist resume las acciones concretas que toda organización debería implementar:

Gestión del ciclo de vida de productos de seguridad

En mi práctica profesional, he desarrollado un sistema de gestión del ciclo de vida de productos de seguridad que recomiendo a todas las organizaciones que me consultan. No es complicado, pero requiere disciplina y un responsable claramente asignado:

• Mantener un inventario actualizado de todos los productos de seguridad desplegados, con su versión, fecha de instalación y fecha de fin de soporte. Este inventario debe revisarse al menos trimestralmente
• Configurar alertas automáticas para 18, 12, 6 y 3 meses antes del fin de soporte de cada producto. La alerta de 18 meses es crítica para administraciones públicas que necesitan tiempo para completar procesos de contratación
• Asignar un responsable para cada producto crítico que verifique mensualmente que las actualizaciones se están aplicando. Este responsable debe firmar un check mensual que queda documentado
• Documentar un procedimiento de sustitución para cada producto, con alternativas preaprobadas y tiempos estimados de transicion. El procedimiento debe incluir medidas compensatorias para el periodo de transicion
• Realizar un test de funcionamiento trimestral: ejecutar una muestra de malware conocido en un entorno controlado para verificar que el sistema lo detecta. Si no lo detecta, investigar inmediatamente

Cláusulas contractuales obligatorias

• Obligación del proveedor de notificar con 12 meses de antelacion cualquier cambio en el ciclo de soporte del producto
• Cláusula de continuidad: el proveedor debe mantener actualizaciones hasta que la transicion al sustituto este completamente operativa
• Derecho de auditoría: la empresa debe poder verificar en cualquier momento que el proveedor esta cumpliendo con sus obligaciones de actualización
• Penalizaciones económicas por interrupcion unilateral del soporte sin preaviso suficiente
• Cláusula de acceso a datos: en caso de terminación del contrato, el proveedor debe facilitar la exportación de logs, configuraciones y datos en formato estándar

Redundancia en sistemas de seguridad

• Nunca depender de un único fabricante para la detección de amenazas. Si el anti-APT es del fabricante A, el EDR debe ser del fabricante B
• Mantener un SIEM independiente que agregue logs de todas las fuentes, de modo que si un sistema falla, los logs siguen estando disponibles
• Implementar al menos dos capas de detección independientes para cada vector de ataque crítico (email, endpoint, red, identidad)
• Probar periódicamente que cada capa funciona de forma independiente, simulando el fallo de las otras capas

Monitorización proactiva del estado de los sistemas de seguridad

He visto demasiadas empresas que asumen que sus sistemas de seguridad funcionan correctamente porque “no reciben alertas”. La ausencia de alertas no significa ausencia de amenazas. Puede significar que el sistema ha dejado de funcionar.

Cada organización debería implementar lo que yo llamo “verificación de pulso” de sus sistemas de seguridad:

Si Moncloa hubiera tenido esta tabla implementada y verificada, la caducidad del sistema anti-APT se habría detectado en la verificación diaria de actualizaciones. No 100 días después, cuando los datos ya estaban en la dark web.

Protocolo de actuación cuando un sistema de seguridad falla

Basandome en mi experiencia como perito y en las mejores prácticas del NIST Cybersecurity Framework, he desarrollado un protocolo de actuación inmediata que toda organización debería tener preparado para cuando un sistema de seguridad crítico falle o deje de recibir soporte:

Primeras 24 horas:

• Evaluar el impacto: que sistemas y datos quedan sin protección
• Notificar al responsable de seguridad y a la dirección
• Activar medidas compensatorias inmediatas: restricción de accesos remotos, monitorización manual reforzada, aumento de la frecuencia de backups
• Contactar al proveedor para negociar un periodo de transicion con soporte mínimo
• Documentar la situación y las medidas adoptadas

Primera semana:

• Desplegar herramientas de seguridad alternativas temporales (open source o versiones de evaluación de otros fabricantes)
• Intensificar la monitorización de logs: revisar manualmente los eventos de seguridad que el sistema obsoleto podría no estar detectando
• Realizar un escaneo de vulnerabilidades para identificar posibles compromisos ocurridos desde que el sistema dejo de actualizarse
• Iniciar el proceso de contratación urgente del sistema sustituto

Primer mes:

• Ejecutar un threat hunting básico: buscar indicadores de compromiso conocidos en los sistemas protegidos por el sistema obsoleto
• Considerar la contratación temporal de un servicio de monitorización externo (SOC as a Service) para cubrir el gap
• Verificar que todos los usuarios con acceso a los sistemas afectados tienen autenticación multifactor activa
• Preparar un informe de riesgos para la dirección que cuantifique el impacto potencial de una brecha durante el periodo de exposición

Si Moncloa hubiera seguido este protocolo desde noviembre de 2025, los 100 días de exposición se habrían reducido a semanas, y las medidas compensatorias habrían limitado significativamente la superficie de ataque disponible para los atacantes.

El coste de la inaccion: prevención vs respuesta

Una de las preguntas que más me hacen como perito es: “cuanto cuesta realmente protegerse, y merece la pena la inversión?”. La respuesta es siempre la misma: la prevención cuesta una fracción de lo que cuesta la respuesta a un incidente. En el caso Moncloa, la inversión de emergencia posterior superó con creces lo que habría costado mantener el sistema con soporte.

No existe una tabla pública fiable de costes de brecha por tamaño de organización que pueda citarse dato a dato: las cifras que circulan mezclan muestras, geografías y metodologías distintas, y no se sostiene atribuir una segmentación así a IBM, ENISA o Accenture, que no la publican en esos términos. Lo que sí es consistente en sus informes es el orden de magnitud: la prevención cuesta una fracción de la respuesta.

Lo que estos números no capturan es el coste intangible: la pérdida de confianza de los ciudadanos en la capacidad del Gobierno para proteger sus datos, el daño a la posición de España en foros internacionales de ciberseguridad, y el efecto sobre los cargos públicos que descubren que su domicilio circula sin que su organización pudiera evitarlo.

En mi experiencia como perito, el ratio real de coste prevención vs coste brecha suele ser aun mayor que 1:10, porque las empresas tienden a subestimar los costes indirectos de una brecha: horas de trabajo desviadas de tareas productivas, oportunidades de negocio perdidas mientras se gestiona la crisis, y el incremento permanente de las primas de ciberseguro tras un incidente.

El coste real: por qué no se puede cifrar aquí

Circuló un «desglose» que sumaba entre 3 y 5 millones de euros de coste del episodio. Se retira: la mayoría de sus partidas —análisis forense de los sistemas, expulsión de un atacante, rotación masiva de credenciales, defensa ante reclamaciones de afectados— presuponen una intrusión que no consta, y ninguna se apoya en contratos, facturas o resoluciones públicas. Lo único acreditado es el contrato de sustitución (175.811 €) y una inversión de refuerzo de más de 2 millones publicada por un solo medio sin confirmación oficial. Cualquier total global más allá de eso sería inventado.

Lo que sí puede afirmarse sin cifra es el argumento de fondo, y no lo necesita: mantener la continuidad de un sistema de detección cuesta mucho menos que gestionar las consecuencias de quedarse sin él. Ese es el motivo por el que un hueco de soporte de tres meses en una institución crítica no es un ahorro, sino un riesgo asumido.

Qué puede hacer un perito informático forense en estos casos

En incidentes de esta magnitud, el perito informático forense cumple funciones críticas tanto para la organización afectada como para los individuos cuyos datos han sido expuestos. He participado en la investigación de brechas que, salvando las distancias, comparten características con el caso Moncloa: datos sensibles expuestos, sistemas de protección degradados y periodos prolongados de exposición sin detección.

Para organizaciones afectadas

• Determinar si hubo intrusión, que es la primera pregunta y no siempre la que se encarga: en este episodio, comprobar el origen de los datos publicados habría descartado el compromiso de sistemas en cuestión de horas — basta con encontrar entre ellos un trámite personal que la institución no custodia. Cuando sí hay intrusión, el trabajo es determinar el vector de entrada, el alcance del compromiso y los datos efectivamente exfiltrados. En un caso típico de brecha como la de Moncloa, esto implica analizar imágenes forenses de los sistemas comprometidos con herramientas como Volatility (memoria RAM), Wireshark (tráfico de red), y Autopsy o EnCase (discos). El análisis debe reconstruir la timeline completa del atacante: por donde entro, que hizo, cuanto tiempo estuvo, que datos accedio y como los exfiltro
• Preservación de evidencia: asegurar la cadena de custodia digital siguiendo las directrices de ISO/IEC 27037 (identificación, recogida, adquisición y preservación). Cada imagen forense se documenta con hashes SHA-256, actas de intervención con fecha y hora, y un registro completo de quién ha accedido a la evidencia. Refuerza la integridad y la trazabilidad de la prueba; su admisión y valoración corresponden al tribunal
• Informe pericial judicial: documentar técnicamente el incidente para procedimientos regulatorios (AEPD) o judiciales. El informe debe recoger lo que exige el artículo 478 de la LECrim —descripción del objeto, operaciones realizadas y resultados, y conclusiones—; cumplir esos requisitos formales no garantiza por sí solo la admisión, que decide el órgano judicial. Debe detallar la metodología utilizada, los hallazgos técnicos, la cronología y las conclusiones profesionales del perito
• Evaluación de daños y cuantificacion del impacto: Cuantificar el impacto real de la brecha en términos de datos comprometidos, sistemas afectados, riesgo residual y coste económico. Esta evaluación es fundamental para las reclamaciones de responsabilidad patrimonial y para las negociaciones con aseguradoras
• Asesoría durante la respuesta al incidente: Orientar al equipo de IT durante la contención y remediación para que no destruyan evidencia forense en el proceso de “volver a la normalidad”. En mi experiencia, las primeras horas tras la detección son críticas: las decisiones que se toman en ese periodo determinan cuanta evidencia se preserva y cuanta se pierde irremediablemente

Para individuos afectados

Quien vea sus datos personales publicados en una recopilación de este tipo es víctima directa con derecho a reclamación frente a la entidad de la que salió cada dato. Un perito informático forense puede ayudarle de las siguientes formas:

• Verificación de exposición: Determinar si tus credenciales o datos aparecen en las filtraciones publicadas en la dark web. Esto incluye la búsqueda en bases de datos de brechas conocidas, foros de la dark web y mercados de credenciales robadas. El resultado se documenta en un informe pericial que puede usarse como prueba en una reclamación
• Peritaje de daños: Documentar el perjuicio sufrido para reclamaciones por responsabilidad patrimonial de la administración. El informe pericial debe cuantificar el daño: datos personales expuestos, riesgo de suplantación de identidad, coste de las medidas de protección que el afectado ha tenido que adoptar (cambio de cerraduras si la dirección fue expuesta, monitorización de crédito, etc.)
• Monitorización forense de dispositivos: Analizar si tus dispositivos personales han sido comprometidos como consecuencia de la filtración. Si un atacante tiene tus credenciales, puede haber intentado acceder a tus cuentas personales, y si tuvo éxito, puede haber instalado malware en tus dispositivos
• Asesoramiento técnico personalizado: Recomendar medidas de protección personal inmediatas y a largo plazo. Cada caso es diferente: un ministro necesita medidas de protección distintas a las de un agente de la Guardia Civil, y ambos necesitan medidas distintas a las de un funcionario administrativo

Preguntas frecuentes

¿Pueden los ciudadanos reclamar por la filtración de datos de cargos públicos?

Si la brecha afecto también a datos de ciudadanos (por ejemplo, credenciales de agentes que interactuan con bases de datos de la población), los afectados podrían presentar una reclamación ante la AEPD al amparo del RGPD y solicitar una indemnización por daños y perjuicios. En cualquier caso, la responsabilidad patrimonial de la Administración Pública (artículo 32 de la Ley 40/2015) permite reclamaciones cuando un funcionamiento anormal del servicio público causa un daño efectivo. Un perito informático puede documentar el daño sufrido y emitir un informe pericial que sustente la reclamación.

¿Qué diferencia hay entre un sistema anti-APT y un antivirus convencional?

Un antivirus convencional detecta malware conocido mediante firmas estaticas. Un sistema anti-APT combina análisis de comportamiento, sandboxing, inteligencia de amenazas en tiempo real y correlación de eventos para detectar ataques dirigidos y sofisticados (como los de actores estatales) que un antivirus no identificaria. Cuando un sistema anti-APT deja de recibir actualizaciones, pierde progresivamente su ventaja sobre un antivirus básico: la detección basada en firmas se queda ciega enseguida frente al malware nuevo, y la detección por comportamiento se degrada más despacio pero también se resiente. El ritmo exacto depende del producto, su configuración y las medidas compensatorias —no hay un umbral universal de días—, pero cuanto más se prolonga el hueco, mayor es el punto ciego.

¿Qué debe hacer una empresa si su proveedor de ciberseguridad deja de dar soporte?

Lo prioritario es activar el plan de contingencia:

Un perito informático forense puede verificar que no se hayan producido intrusiones durante la ventana sin cobertura y emitir un informe pericial que acredite el estado de seguridad de los sistemas.

¿Qué es el dwell time y por que importa en este caso?

El dwell time es el tiempo que un atacante permanece dentro de una red comprometida antes de ser detectado. Según el informe M-Trends 2025 de Mandiant, la mediana global de dwell time es de 11 días (y de 10 días cuando es la propia organización la que detecta la actividad). Sin sistemas de detección funcionales, ese tiempo puede extenderse a meses. Esto significa que los atacantes podrían haber estado dentro de los sistemas de Moncloa durante semanas o meses, exfiltrando datos de forma progresiva sin ser detectados. Cuanto mayor es el dwell time, mayor es el daño potencial y menor es la cantidad de evidencia forense disponible para la investigación posterior.

¿Puede un atacante usar las credenciales filtradas para acceder a otros sistemas gubernamentales?

No, y conviene decirlo con claridad porque fue lo que más se especuló. No se filtraron credenciales de acceso a sistemas del Estado: lo publicado eran datos personales y contraseñas antiguas de servicios privados. Ninguna de ellas abre las bases policiales ni las plataformas de cooperación europea. El riesgo real de una contraseña antigua es la reutilización en cuentas personales de su titular, y se neutraliza cambiándola donde siga en uso.

¿Qué sanciones podría enfrentar España por no transponer NIS2?

El procedimiento de infracción de la UE puede resultar en una sentencia del Tribunal de Justicia de la Unión Europea (TJUE) con sanciones económicas: una suma a tanto alzado (la actualización anual de 2026 sitúa el mínimo general para España en 7,943 M€) y una multa coercitiva diaria, ambas fijadas por el Tribunal caso por caso —la nota del procedimiento no publica importe—. Además, NIS2 prevé sanciones para las entidades que incumplan (hasta 10 millones de euros o el 2 % de la facturación global anual). Ahora bien, que una directiva permita multar administraciones no es automático: cada Estado decide si lo hace y en qué medida (art. 34.7 NIS2).

¿Qué papel juega el CCN-CERT en la protección de Moncloa?

El CCN-CERT (Centro Criptológico Nacional - Computer Emergency Response Team) es el CERT de referencia para las administraciones públicas españolas. Depende del Centro Nacional de Inteligencia (CNI) y proporciona guías de seguridad, alertas de amenazas y apoyo en la respuesta a incidentes. Sin embargo, el CCN-CERT tiene un rol de coordinacion y asesoramiento, no de imposición. No puede obligar a Moncloa a sustituir un sistema anti-APT obsoleto ni tiene autoridad para auditar directamente los contratos de seguridad de la Presidencia del Gobierno. Esta limitación de autoridad es uno de los factores estructurales que contribuyeron a la brecha.

¿Se puede saber si alguien llegó a entrar en los sistemas durante los 100 días?

Es la pregunta correcta, y la respuesta pública es que no consta que nadie entrara: lo publicado no salió de esas redes. Dicho eso, la pregunta de fondo —cómo se descarta una intrusión pasada— tiene interés propio y es difícil de responder. Un análisis forense completo puede identificar indicadores de persistencia: backdoors, cuentas de usuario no autorizadas, tareas programadas sospechosas, certificados digitales comprometidos, modificaciones en las políticas de grupo. Pero los atacantes sofisticados (APTs) utilizan técnicas de persistencia avanzadas que son extremadamente difíciles de detectar: rootkits de firmware, implantes en el BIOS/UEFI, modificaciones del MBR, o persistencia a nivel de hypervisor. Reducir esa incertidumbre exige, según el alcance y las hipótesis del caso, un barrido de los sistemas —incluido, cuando procede, el firmware— y una monitorización reforzada durante un periodo suficiente. No hay un umbral universal de días: lo fijan el análisis de riesgo, la telemetría disponible y la retención de logs.

¿Qué debería hacer alguien cuyas contraseñas antiguas aparecen en una publicación así?

Conviene precisar de qué contraseñas hablamos: las difundidas procedían de brechas de servicios privados, no de sistemas corporativos. Lo inmediato: cambiarlas en todos los servicios donde se hayan utilizado esas mismas o una similar. Activar autenticación multifactor en todos los servicios que lo permitan. Contactar con el departamento de seguridad de su unidad para verificar si su cuenta ha sido utilizada de forma no autorizada. Monitorizar sus cuentas bancarias y solicitar alertas de crédito para detectar posibles intentos de suplantación de identidad. Documentar cualquier actividad sospechosa (emails extraños, llamadas inusuales, intentos de phishing) y reportarla tanto a sus superiores como al CCN-CERT. Un perito informático forense puede analizar sus dispositivos personales para verificar que no han sido comprometidos como consecuencia de la filtración.

¿Pueden los medios de comunicación publicar los datos filtrados?

Es una cuestion jurídica compleja. El derecho a la información (artículo 20 de la Constitución) protege la publicación de información de interes público, y un hackeo a la Presidencia del Gobierno indiscutiblemente lo es. Sin embargo, la publicación de datos personales concretos (DNI, direcciones, credenciales) de las personas afectadas podría vulnerar su derecho a la protección de datos (RGPD) y, en el caso de agentes de seguridad, poner en riesgo su integridad física. Los medios que han informado sobre la brecha han optado, correctamente, por revelar la existencia y magnitud de la filtración sin publicar los datos concretos de las personas afectadas. Publicar las credenciales de agentes de las fuerzas de seguridad sería, además de ilegal, potencialmente peligroso.

¿Este incidente podría haberse evitado con un antivirus normal?

No. Un antivirus convencional no habría bastado frente a un ataque dirigido de este tipo. Los atacantes que tienen como objetivo la Presidencia del Gobierno de un país de la OTAN no utilizan malware que un antivirus básico detectaría. Utilizan herramientas personalizadas, técnicas living-off-the-land que emplean herramientas legítimas del sistema operativo, y malware sin archivos (fileless) que se ejecuta solo en memoria. Para detectar estas amenazas se necesita exactamente lo que Moncloa tenía y dejo de funcionar: un sistema anti-APT con análisis de comportamiento, sandboxing e inteligencia de amenazas actualizada. La pregunta no es si un antivirus habría bastado (no habría bastado), sino por que se permitio que el sistema correcto dejara de funcionar durante 100 días.

¿Qué pasa con los datos una vez publicados en la dark web?

Una vez que los datos se publican en la dark web, es prácticamente imposible eliminarlos. Los datos se replican, se descargan, se venden, se comparten y se incorporan a bases de datos de inteligencia de amenazas. Los datos personales de los altos cargos de Moncloa estarán circulando en la dark web indefinidamente. Esto significa que el riesgo de explotación no se limita al periodo inmediato posterior a la filtración: puede materializarse meses o años después, cuando un atacante diferente encuentre los datos y los utilice para un propósito distinto. He peritado un caso donde los datos de una brecha de 2022 se utilizaron para un ataque de spear phishing en 2025. Los datos no caducan en la dark web.

¿Podría haber un actor estatal detras de este ataque?

Es una posibilidad que no se puede descartar. Los datos filtrados (altos cargos del Gobierno, JEMAD, Consejo de Seguridad Nacional, agentes de las fuerzas de seguridad) son exactamente el tipo de información que un servicio de inteligencia extranjero buscaria. Los actores estatales tienen la motivación, la capacidad técnica y la paciencia para explotar una ventana de 100 días sin detección. Según el Threat Landscape 2025 de ENISA, la administración pública es el sector más atacado de la UE, con el 38 % de los incidentes registrados — y sigue siendo el primero, con un aumento notable respecto al año anterior debido sobre todo a los DDoS de grupos hacktivistas. ⚠️ Aquí figuraba que «las campañas APT contra gobiernos europeos aumentaron un 38 %»: ese 38 % es una cuota de reparto, no una tasa de crecimiento. Sin embargo, la atribución de ciberataques a actores estatales es extremadamente difícil y requiere un análisis forense completo de las herramientas, técnicas y procedimientos utilizados, que solo las agencias de inteligencia con acceso a los sistemas comprometidos pueden realizar.

Lo que este incidente significa para el ciudadano medio

Una pregunta que me hacen a menudo cuando comento incidentes de ciberseguridad gubernamental es: “esto me afecta a mi?”. La respuesta es si, y de formas que quizás no son evidentes.

Tus datos en manos del Estado también están en riesgo

Si los sistemas de la Presidencia del Gobierno no estuvieron adecuadamente protegidos durante 100 días, es legítimo preguntarse que nivel de protección tienen tus datos en otras administraciones públicas: tu historial medico en el sistema de salud, tus datos fiscales en la AEAT, tus antecedentes en los sistemas policiales, tu información catastral, tus expedientes educativos.

No estoy diciendo que todos estos sistemas esten comprometidos. Pero si que el caso Moncloa demuestra que las administraciones públicas españolas no son inmunes a brechas de seguridad, y que la ausencia de un marco legal actualizado (NIS2 sin transponer) significa que no hay mecanismos de supervisión efectivos para garantizar que tus datos están protegidos adecuadamente.

Cómo puedes protegerte

Aunque no puedes controlar la seguridad de los sistemas gubernamentales, si puedes tomar medidas para reducir tu exposición:

• Minimiza los datos que proporcionas: No des más información de la estrictamente necesaria en formularios gubernamentales. Si un campo es opcional, dejalo vacio
• Activa la autenticación reforzada: Utiliza Cl@ve PIN o Cl@ve Permanente con verificación en dos pasos para tus trámites con la administración. Si tus credenciales se filtran, el segundo factor bloquea el acceso
• Monitoriza tu identidad digital: Configura alertas de Google para tu nombre completo y DNI. Si aparecen en una filtración, lo sabras rápidamente. Servicios como haveibeenpwned.com te avisan si tu email aparece en brechas conocidas
• Ejerce tus derechos: El RGPD te da derecho a saber que datos tiene cada administración sobre ti (derecho de acceso, artículo 15), a solicitar su corrección (artículo 16) y a reclamar ante la AEPD si consideras que no se están protegiendo adecuadamente (artículo 77)

Tu derecho a una administración segura

Como ciudadano, tienes derecho a que la administración pública gestione tus datos con las medidas de seguridad adecuadas. El ENS (Esquema Nacional de Seguridad) lo exige. El RGPD lo exige. La futura transposición de NIS2 lo exigira de forma aun más estricta. Cuando una administración falla en esta obligación y tus datos se ven comprometidos, tienes derecho a reclamar una indemnización por responsabilidad patrimonial (artículo 32 de la Ley 40/2015).

Un perito informático forense puede ayudarte a documentar el daño sufrido y a elaborar el informe técnico necesario para sustentar la reclamación. No es un proceso sencillo, pero es un derecho que cada vez más ciudadanos están ejerciendo.

La brecha de confianza digital

Más allá de los riesgos técnicos y legales, el caso Moncloa tiene un impacto en la confianza de los ciudadanos en la administración digital. España ha apostado fuertemente por la digitalización de los servicios públicos: la Cl@ve digital, la Sede Electrónica, el certificado digital, la carpeta ciudadana. Todos estos servicios dependen de que los ciudadanos confien en que sus datos están seguros en manos de la administración.

Cuando se difunde que circulan datos personales del presidente, sus ministros y sus agentes de seguridad —aunque procedan de brechas de terceros y no de las redes del Gobierno—, la pregunta que se instala es: “si esto le pasa al presidente, como van a proteger los mios?”. Esta pregunta no tiene una respuesta fácil, y el daño a la confianza digital puede ser duradero.

En mis peritajes para empresas, he observado que las brechas de datos tienen un impacto en la adopción de servicios digitales que va más alla de la organización afectada. Cuando una empresa sufre una brecha conocida, sus competidores también ven una caída temporal en la adopción de sus servicios digitales, porque los usuarios generalizan la desconfianza al sector completo. Lo mismo puede ocurrir con la administración pública: una brecha en Moncloa puede reducir la adopción de servicios públicos digitales en general, revirtiendo años de esfuerzo en digitalización.

La única forma de mitigar este daño es la transparencia: explicar que paso, por que paso, que se ha hecho para que no vuelva a ocurrir y que medidas de protección adicionales se han implementado. El silencio institucional no protege la confianza: la destruye.

Conclusión: un incidente que no debería haber ocurrido

Después de analizar en profundidad todos los aspectos de este caso, mi conclusión como perito informático forense es clara: el hueco de protección de Moncloa era evitable. No estamos ante un ataque de sofisticación extraordinaria que superó defensas razonables, sino ante un fallo en la gestión de la cadena de suministro tecnológica que dejó la Presidencia del Gobierno sin protección avanzada durante casi tres meses. La publicación de datos que coincidió en el tiempo vino, además, por otra vía.

Los hechos son inequivocos:

1. El fabricante del sistema anti-APT dejó de actualizar en noviembre de 2025
2. Nadie activó un plan de contingencia durante 100 días
3. El contrato de sustitución no se formalizó hasta el 13 de febrero de 2026
4. En paralelo, y por una vía distinta, se publicaron datos personales del presidente, ministros, el JEMAD, el fiscal general y miembros del Consejo de Seguridad Nacional
5. No consta que nadie aprovechara el hueco: los datos publicados procedían de filtraciones anteriores de terceros, no de las redes de Presidencia

(El punto 4 decía antes: «durante ese periodo, los atacantes accedieron a los datos más sensibles del Estado español». Presentaba como inequívoco justo lo que este artículo corrige en su primer párrafo.)

Cada uno de estos puntos es un fallo individual. Juntos, representan un fracaso sistémico de la gobernanza de la ciberseguridad en la máxima institucion del Estado español. Y lo que es peor: este fracaso ocurre en el mismo periodo en el que España debería estar transponiendo la Directiva NIS2, diseñada precisamente para prevenir este tipo de incidentes.

La pregunta que debemos hacernos no es solo “como paso esto”, sino “cuantas instituciones más están en la misma situación ahora mismo”. Porque si la Presidencia del Gobierno, con sus recursos y su perfil de amenaza, no fue capaz de mantener su sistema de seguridad actualizado, es razonable suponer que ministerios, comunidades autónomas y ayuntamientos con menos recursos están en una situación igual o peor.

Como perito, mi recomendación final es la misma que doy a todas las organizaciones que me consultan tras un incidente: no esperes a que te pase a ti. Revisa tus sistemas de seguridad hoy, verifica que están actualizados, confirma que tus contratos de soporte están vigentes y asegurate de que tienes un plan B para cuando un proveedor falle. Porque los proveedores fallan. Siempre.

Si al leer este artículo te has dado cuenta de que tu organización tiene un sistema de seguridad sin actualizaciones, un contrato de soporte a punto de vencer o un plan de contingencia que nunca se ha probado, actua hoy. No mañana. No la próxima semana. Hoy. El caso Moncloa demuestra que un hueco de tres meses en la protección de una institución crítica es un riesgo que no puede permitirse, lo aproveche o no un atacante. Y tu organización no tiene los recursos de la Presidencia del Gobierno para invertir 2 millones de euros en recuperarse después del desastre.

Si necesitas ayuda para evaluar el estado de seguridad de tu organización, para verificar que tus sistemas de protección están correctamente configurados y actualizados, o para preparar un plan de respuesta a incidentes que puedas activar cuando lo necesites, estoy disponible para una consulta inicial gratuita. Mejor prevenir que peritar.

El caso Moncloa pasará a la historia de la ciberseguridad española como un punto de inflexión. La pregunta es si será el punto de inflexion que provoco un cambio real en la gobernanza de la ciberseguridad del Estado, o el punto de inflexion que demostro que ni siquiera una brecha de seguridad nacional es suficiente para cambiar las cosas en España. Como profesional de la ciberseguridad, espero sinceramente que sea lo primero. Como observador realista de la política española, me temo que pueda ser lo segundo.

Preguntas relacionadas

Si te interesa este tema, estos artículos de nuestro blog profundizan en aspectos directamente relacionados:

• Ley de Ciberseguridad NIS2 en España 2026: obligaciones para empresas y administraciones - Todo lo que NIS2 exige y que Moncloa no cumplio
• Brecha de datos en la Policía Nacional: información antiterrorista expuesta - Otro incidente grave en instituciones españolas en 2026
• Que hace un perito informático forense: servicios de análisis forense digital - Como un perito puede ayudarte tras una brecha de seguridad
• Balance de ciberseguridad INCIBE 2025: 122.223 incidentes en España - El contexto general de la ciberseguridad en España
• Ransomware en PYMEs: solo el 10 % de las organizaciones atacadas recupera casi todos sus datos - Cuando la falta de prevención lleva al peor escenario
• Fraude BEC contra PYMEs: la Guardia Civil alerta del aumento de estafas por email - Otro ejemplo de como las credenciales filtradas se explotan

Fuentes consultadas:

• The Objective — «Moncloa renovó su sistema de ciberseguridad meses después de que quedara obsoleto» (18 de febrero de 2026) — el origen del dato de los ~100 días sin soporte: fin de vida útil en noviembre de 2025 y contrato de sustitución (175.811 €) firmado el 13 de febrero de 2026
• INCIBE — «No, INCIBE no ha sido víctima de un ciberataque. ¿Qué es el doxing y cómo INCIBE se ha visto afectado por esta práctica?» — el desmentido institucional, y la explicación de por qué la aparición de datos de una persona no acredita una brecha en la entidad donde trabaja
• EscudoDigital — «Filtran datos de directivos del INCIBE y de la Policía sin vulnerar los sistemas de estas instituciones» (26 de febrero de 2026) — el modus operandi: agregación de filtraciones antiguas de terceros, atribuida a Police-ESP-Doxed
• Buena parte de la cobertura de aquellos días encuadró el caso como un «ciberataque a la Presidencia del Gobierno». Ese encuadre no se sostuvo, y por eso no se enlazan aquí piezas que sostienen lo contrario de lo que resultó ser: el desmentido del INCIBE y la reconstrucción de EscudoDigital explican por qué
• Directiva NIS2 (UE) 2022/2555 - Texto completo EUR-Lex
• Esquema Nacional de Seguridad - Real Decreto 311/2022 (BOE)
• RGPD - Reglamento (UE) 2016/679
• CCN-CERT — series CCN-STIC de guías de seguridad del ENS
• Mandiant M-Trends 2026 - Dwell time, métricas de detección y tendencias APT
• IBM Cost of a Data Breach Report 2025 - Coste medio de brechas por sector
• INCIBE - Balance de ciberseguridad 2025: 122.223 incidentes gestionados
• Ley 40/2015 de Régimen Jurídico del Sector Público (BOE)
• ENISA — Threat Landscape 2025 (octubre de 2025) — la administración pública es el sector más atacado de la UE, con el 38,2 % de los incidentes registrados
• Verizon Data Breach Investigations Report (DBIR) 2025 - Reutilización de credenciales
• CrowdStrike Global Threat Report 2026 — de donde sale el 82 % de detecciones malware-free de 2025. (URL de marca: sirve siempre la última edición.)
• AV-TEST Institute - Estadísticas de nuevas muestras de malware diarias
• ANSSI (Francia) — Rapports d’activité; la agencia ha migrado su web a cyber.gouv.fr
• BSI (Alemania) — IT-Grundschutz, su marco de seguridad de referencia
• NCSC (Reino Unido) — Active Cyber Defence

Nota del autor: Este artículo representa mi análisis profesional independiente del incidente de Moncloa, basado en la información publicada por fuentes periodísticas y en mi experiencia como perito informático forense. No he tenido acceso a los sistemas comprometidos ni a información clasificada. Las hipótesis técnicas que presento están basadas en los patrones documentados de ataques similares y en mi experiencia peritando brechas de seguridad en organizaciones públicas y privadas. Las opiniones expresadas son estrictamente profesionales y no tienen motivación política.

Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en análisis de brechas de seguridad, respuesta a incidentes y peritajes judiciales sobre protección de datos. Ex-CTO con 5 certificaciones AWS, aplica metodología ISO 27037 en todas sus investigaciones. Si tu organización ha sufrido o sospecha una brecha de seguridad, puedes solicitar una consulta inicial gratuita.

Última actualización: 6 de septiembre de 2026

Referencias y fuentes

• EscudoDigital — «Filtran datos de directivos del INCIBE y de la Policía sin vulnerar los sistemas de estas instituciones» (26 de febrero de 2026) — el INCIBE y la Policía descartan la intrusión y sitúan el origen en brechas previas de terceros
• The Objective — «Moncloa renovó su sistema de ciberseguridad meses después de que quedara obsoleto» (18 de febrero de 2026) — el origen del dato de los ~100 días sin soporte y del contrato de 175.811 €
• INCIBE — «No, INCIBE no ha sido víctima de un ciberataque» — el desmentido institucional del encuadre de «ciberataque»
• Directiva NIS2 (UE) 2022/2555 — EUR-Lex — Directiva europea de ciberseguridad que España no ha transpuesto
• Esquema Nacional de Seguridad — Real Decreto 311/2022 (BOE) — Marco normativo de seguridad para la administración pública española
• RGPD — Reglamento (UE) 2016/679 — Obligaciones de notificación de brechas (Art. 34)
• CCN-CERT — series CCN-STIC — guías de seguridad del ENS
• IBM Cost of a Data Breach Report 2025 — Coste medio de brechas en sector público y tiempo de detección
• Mandiant M-Trends 2026 — Métricas de dwell time y tendencias APT
• Verizon — Data Breach Investigations Report 2025 (PDF) — 12.195 brechas confirmadas de 22.052 incidentes en 139 países; elemento humano en torno al 60 %, participación de terceros del 15 % al 30 %, y el 46 % de los equipos con credenciales corporativas en volcados de infostealer eran dispositivos no gestionados
• ENISA — Threat Landscape 2025 — la administración pública es el sector más atacado de la UE (38,2 % de los incidentes)
• AV-TEST Institute — más de 450.000 nuevas muestras de malware y aplicaciones no deseadas registradas cada día, que es la cifra que publica el instituto
• ANSSI (Francia) — Rapports d’activité — modelo de ciberseguridad gubernamental con autoridad de imposición
• BSI (Alemania) — IT-Grundschutz — marco de seguridad de referencia para la administración federal
• NCSC (Reino Unido) — Active Cyber Defence
• INCIBE — Balance de ciberseguridad 2025 — 122.223 incidentes gestionados en España
• Norma ISO 27037 — Estándar de preservación de evidencia digital y cadena de custodia
• Norma ISO 27035 — Gestión de incidentes de seguridad de la información