Inteligencia sobre amenazas de ISO 27001 para NIS2 y DORA
A las 07:42 de un martes por la mañana, el director de seguridad de la información (CISO) de una fintech europea recibe cuatro mensajes antes del café.
El primero es una alerta de un CERT nacional que advierte de que una vulnerabilidad de acceso remoto está siendo explotada activamente. El segundo es un boletín de un proveedor que confirma que el componente afectado se utiliza dentro de un servicio gestionado de transferencia de archivos. El tercero es una notificación del servicio MDR (detección y respuesta gestionadas) que señala tráfico saliente inusual desde una subred no productiva. El cuarto procede del CFO: “¿Afecta esto a nuestro paquete de preparación para DORA y tenemos que notificar a alguien conforme a NIS2?”
Este es el problema de la inteligencia sobre amenazas en 2026. No se trata de recopilar más fuentes. Se trata de demostrar que la inteligencia sobre ciberamenazas relevante se recibe, valida, enruta, trata y convierte en evidencia de riesgo, detección, vulnerabilidades, incidentes, proveedores y consejo de administración.
Muchas organizaciones ya están suscritas a avisos de proveedores, alertas de CISA, actualizaciones de ENISA, avisos de CERT nacionales, boletines de ISAC, notificaciones de seguridad de proveedores de servicios en la nube, fuentes CVE, informes MDR, bases de datos de explotabilidad y supervisión de la web oscura. Sin embargo, cuando llega un aviso real, los equipos siguen improvisando. El SOC redacta una regla de detección. Infraestructura busca en inventarios de activos que quizá no estén actualizados. Cumplimiento pregunta si el evento afecta a NIS2 o DORA. La dirección quiere una respuesta clara antes incluso de que la organización sepa si el componente vulnerable está en producción.
El problema no es la falta de datos. Es la ausencia de un modelo operativo auditable.
Una fuente de amenazas que nadie utiliza no es un control. Un aviso de vulnerabilidad que no modifica la prioridad de parcheo no es evidencia. Una notificación de proveedor que nunca llega al registro de riesgos no es seguridad de la cadena de suministro. Una alerta de CSIRT que no actualiza la supervisión, el triaje de incidentes o la información a la dirección es solo ruido en la bandeja de entrada.
El enfoque de Clarysec es sencillo: la inteligencia sobre amenazas debe convertirse en un sistema operativo para las decisiones de riesgo. Debe integrarse en el alcance del SGSI, la evaluación de riesgos, la Declaración de Aplicabilidad, los procedimientos de respuesta a incidentes, el triaje de vulnerabilidades, el registro y la supervisión, la gobernanza de proveedores, la información a la dirección y el paquete de evidencia de auditoría.
Por qué la inteligencia sobre amenazas es ahora un control a nivel del consejo de administración
NIS2 cambió el tono de la gobernanza de la ciberseguridad. Incluye en el alcance a muchos proveedores SaaS, proveedores de servicios en la nube, proveedores de servicios gestionados, proveedores de servicios de seguridad gestionados, organizaciones de infraestructura digital y proveedores de servicios digitales como entidades esenciales o importantes, en función del sector, el tamaño y la designación del Estado miembro.
NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos. Estas incluyen análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento, incluida la gestión y divulgación de vulnerabilidades, evaluación de la eficacia, higiene cibernética básica y formación, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos y MFA o autenticación continua cuando proceda.
NIS2 Article 20 también exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su aplicación y reciban formación. Para las entidades esenciales, la multa administrativa máxima puede alcanzar al menos 10 millones de euros o el 2 % del volumen de negocios anual mundial, la cifra que sea mayor. Para las entidades importantes, puede alcanzar al menos 7 millones de euros o el 1,4 %.
Para la inteligencia sobre amenazas, la pregunta a nivel del consejo de administración pasa a ser: ¿cómo sabemos que las amenazas emergentes están modificando nuestros controles antes de convertirse en incidentes?
DORA añade otra capa para las entidades financieras y los proveedores terceros de TIC pertinentes. Es aplicable desde el 17 de enero de 2025 y exige un marco de gestión del riesgo de las TIC sólido, integral y bien documentado, integrado en el sistema general de gestión de riesgos. El marco de DORA espera que las organizaciones identifiquen y clasifiquen funciones y activos de negocio soportados por TIC, protejan y prevengan, detecten actividad anómala, respondan y se recuperen, gestionen copias de seguridad y restauración, aprendan de los incidentes de TIC, comuniquen durante crisis y gestionen el riesgo de terceros proveedores de TIC.
DORA también exige gestión, clasificación y notificación de incidentes relacionados con las TIC. Articles 17, 18 y 19 cubren los procesos de gestión de incidentes, la clasificación de incidentes relacionados con las TIC y ciberamenazas, y la notificación de incidentes importantes relacionados con las TIC. Article 10 se centra en la detección de actividades anómalas. Articles 6 a 11 describen el marco de gestión del riesgo de las TIC y las expectativas de identificación, protección, prevención, detección, respuesta y recuperación.
En términos sencillos, DORA espera resiliencia informada por amenazas. No resiliencia estática. No resiliencia basada en políticas anuales. Resiliencia informada por amenazas.
ISO/IEC 27001:2022 proporciona el motor del sistema de gestión que conecta estas expectativas. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto interno y externo, las partes interesadas, las obligaciones legales y reglamentarias, el alcance del SGSI, las dependencias y los procesos que interactúan. Las cláusulas 6.1.1 a 6.1.3 exigen un proceso repetible de evaluación y tratamiento de riesgos, selección de controles, comparación con el Anexo A, una Declaración de Aplicabilidad, planificación del tratamiento y aprobación del riesgo residual por el propietario del riesgo.
La inteligencia sobre amenazas pertenece ahí, no como un panel lateral, sino como entrada para el contexto, el riesgo, la selección de controles, el tratamiento, la supervisión, la revisión por la dirección y la mejora continua.
La trampa del cumplimiento: fuentes de amenazas sin trazabilidad de decisiones
El patrón de fallo más común es engañosamente simple: la organización recibe inteligencia sobre amenazas, pero no puede demostrar cómo modifica las decisiones.
Una cadena de evidencia débil suele tener este aspecto:
| Señal recibida | Respuesta débil | Preocupación del auditor |
|---|---|---|
| Alerta CERT sobre explotación activa | Reenviada al buzón de TI | Sin evidencia de evaluación de riesgos, responsabilidad o acción |
| Boletín de proveedor sobre parche crítico | Añadido a la cola de tickets | Sin priorización basada en criticidad del activo o actividad de explotación |
| Detección MDR de línea de comandos sospechosa | Cerrada como falso positivo | Sin criterios de triaje documentados ni ciclo de aprendizaje |
| Notificación de proveedor sobre dependencia comprometida | Archivada en la carpeta de compras | Sin actualización del riesgo de proveedores ni revisión de controles compensatorios |
| Aviso de ISAC sobre campaña sectorial | Mencionado en una reunión del SOC | Sin actualización de supervisión, concienciación o procedimiento de respuesta a incidentes |
Aquí es donde el método de implantación de Clarysec ayuda a las organizaciones a pasar de “recibimos inteligencia” a “operativizamos la inteligencia”.
En Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint, la fase Controles en acción convierte explícitamente la inteligencia sobre amenazas en una práctica auditable. El paso 22, Controles organizativos, establece:
Establezca una lista documentada de fuentes de inteligencia de amenazas (5.7), procedentes de proveedores, ISAC o fuentes abiertas, y determine cómo se valida la inteligencia y cómo se integra en la toma de decisiones. Defina quién recibe las actualizaciones de amenazas y cómo se aplican (por ejemplo, priorización de parches, formación en concienciación). Cree un breve informe de tendencias de amenazas para distribuirlo trimestralmente a las partes interesadas clave.
Esa instrucción es el puente entre los datos de amenazas y la evidencia de cumplimiento. Un registro de inteligencia sobre amenazas no es solo una lista de fuentes. Demuestra relevancia, titularidad, validación, enrutamiento, integración y uso por parte de la organización.
Lógica de control de ISO 27001: la cadena de inteligencia sobre amenazas
El control 5.7 de ISO/IEC 27002:2022, Inteligencia sobre amenazas, exige que las organizaciones recopilen y analicen información relativa a amenazas contra la seguridad de la información y la utilicen para producir inteligencia sobre amenazas. En Zenith Controls: guía de cumplimiento transversal Zenith Controls, el control 5.7 se clasifica como preventivo, detectivo y correctivo. Respalda la confidencialidad, la integridad y la disponibilidad, se alinea con los conceptos de ciberseguridad Identificar, Detectar y Responder, y se sitúa dentro de la gestión de amenazas y vulnerabilidades como una capacidad operativa.
Esa clasificación importa. La inteligencia sobre amenazas previene al informar el endurecimiento, la aplicación de parches, la formación y los controles de proveedores. Detecta al orientar la supervisión, las reglas SIEM y las tareas de búsqueda proactiva de amenazas. Corrige al mejorar la respuesta a incidentes, las lecciones aprendidas y el tratamiento de riesgos.
Zenith Controls también mapea el control 5.7 de ISO/IEC 27002:2022 con controles de soporte:
| Relación con controles ISO/IEC 27002:2022 | Por qué importa en la práctica |
|---|---|
| 5.6 Contacto con grupos de interés especial | Los ISAC, CERT, foros profesionales y comunidades sectoriales son fuentes de inteligencia, no actividades accesorias de networking |
| 8.7 Protección contra el software malicioso | Los indicadores de compromiso, URL maliciosas, hashes, infraestructura de mando y control y patrones de ataque actualizan las defensas de endpoints y correo electrónico |
| 8.8 Gestión de vulnerabilidades técnicas | La inteligencia sobre exploits activos cambia la prioridad de las vulnerabilidades y la urgencia del parcheo |
| 8.15 Registro de eventos | Los registros proporcionan el registro fáctico necesario para buscar indicadores y reconstruir la actividad |
| 8.16 Actividades de supervisión | La inteligencia sobre amenazas indica al SOC qué supervisar, mientras que la supervisión produce inteligencia interna |
| 5.25 Evaluación y decisión sobre eventos de seguridad de la información | El triaje apoyado en inteligencia ayuda a decidir si un evento es un incidente de seguridad |
La conexión con las vulnerabilidades es especialmente importante. Zenith Controls trata el control 8.8, Gestión de vulnerabilidades técnicas, como preventivo y directamente conectado con el control 5.7 porque la inteligencia sobre amenazas del mundo real informa qué vulnerabilidades están siendo explotadas activamente. También conecta 8.8 con 8.16, Actividades de supervisión, porque los intentos de explotación observados deben escalar la urgencia del parcheo.
Esto crea una cadena práctica de inteligencia sobre amenazas:
- Llega inteligencia externa o interna.
- La relevancia se valida frente a activos, proveedores, geografía, sector, servicios de negocio y datos.
- Se actualiza el riesgo.
- Cambian las prioridades de parches y configuración.
- Se ajusta la lógica de detección.
- Se revisan los procedimientos de respuesta a incidentes y los umbrales de clasificación.
- Se comprueban las dependencias de proveedores y servicios en la nube.
- La dirección recibe informes de tendencias.
- Se conserva evidencia para auditores, reguladores y clientes.
Políticas que convierten la inteligencia en conductas responsables
Las políticas son el punto en el que la lógica de control se convierte en responsabilidad basada en roles. Los conjuntos de políticas para pymes y empresas de Clarysec incluyen puntos de integración de inteligencia sobre amenazas en gestión de riesgos, protección de endpoints, gestión de vulnerabilidades, registro, supervisión y evidencia de auditoría.
Para pymes, la Política de Protección de Endpoints contra Malware Política de Protección de Endpoints contra Malware - pyme establece una expectativa directa en la cláusula 5.4.1 de Requisitos de gobernanza:
El Proveedor de soporte de TI debe supervisar fuentes creíbles de inteligencia de amenazas (por ejemplo, CISA, ENISA, principales proveedores de antivirus) y asegurar que las firmas de detección se mantienen actualizadas
El valor de esta cláusula es la asignación de responsabilidad. La inteligencia sobre amenazas no es “alguien de TI debería revisar alertas”. Es una obligación explícita del proveedor.
La Política de gestión de vulnerabilidades y parches Política de gestión de vulnerabilidades y parches - pyme refuerza el mismo modelo en la cláusula 4.2.1 de Roles y responsabilidades:
Supervisa los sistemas para detectar vulnerabilidades y parches disponibles mediante alertas de proveedores, avisos de inteligencia de amenazas y notificaciones del sistema operativo
También identifica, en la cláusula 6.2.1.3 de Requisitos de implantación de la política, el tipo de fuente que debe activar acciones:
Avisos de inteligencia de amenazas de confianza (por ejemplo, CISA, ENISA, alertas de CERT nacionales)
Para empresas, la Política de gestión de vulnerabilidades y parches Política de gestión de vulnerabilidades y parches establece en la cláusula 4.5.1 de Roles y responsabilidades:
Supervisar avisos de amenazas (por ejemplo, CVE, CISA KEV, boletines de proveedores) y escalar vulnerabilidades críticas.
El requisito de escalado es crucial. Una vulnerabilidad se vuelve urgente cuando convergen explotabilidad, exposición, criticidad para la organización, sensibilidad de los datos y actividad de amenaza.
La Política de gestión de riesgos Política de gestión de riesgos integra la inteligencia sobre amenazas en el análisis. La cláusula 6.2.2 de Requisitos de implantación de la política establece:
El análisis deberá considerar la eficacia de los controles existentes, la inteligencia de amenazas pertinente, la criticidad de los activos y la severidad de las vulnerabilidades.
Esa cláusula es el núcleo de una inteligencia sobre amenazas preparada para auditoría. Demuestra que el análisis de riesgos no es teórico.
La Política de registro y supervisión Política de registro y supervisión convierte la inteligencia en detección. Su cláusula 1.2 de Propósito establece:
El registro de auditoría, la supervisión y la detección de amenazas son críticos para la detección de anomalías, la respuesta a amenazas, la revisión forense, la preparación para auditorías y el cumplimiento legal. Esta política asegura que todos los eventos generados por sistemas se registren, conserven y correlacionen adecuadamente con precisión de hora sincronizada.
Por último, la Política de Auditoría y Supervisión del Cumplimiento Política de Auditoría y Supervisión del Cumplimiento explica por qué importa la disciplina probatoria. La cláusula 3.4 de Objetivos exige que la organización genere evidencia:
Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos regulatorios, procedimientos legales o solicitudes de aseguramiento de clientes.
Cuando NIS2, DORA, un cliente o un auditor ISO preguntan qué sabía la organización, cuándo lo supo, quién decidió y qué cambió, esta pista de evidencia marca la diferencia entre un aseguramiento maduro y una reacción defensiva improvisada.
Construir el registro de inteligencia sobre amenazas
Un registro maduro tiene dos capas: gobernanza de fuentes y seguimiento de eventos. La gobernanza de fuentes define en qué confía la organización, quién es responsable, cómo se valida y qué acción puede activar.
| Nombre de la fuente | Tipo | Proceso de validación | Punto de integración | Responsable |
|---|---|---|---|---|
| Catálogo CISA KEV | Operativo | Contrastar con el inventario de activos y la exposición | Activar la priorización de parches de emergencia | Gestión de vulnerabilidades |
| Avisos de ENISA | Estratégico | Revisión por el propietario del riesgo o el comité de riesgos | Actualizar escenarios de riesgo e informe a la dirección | CISO |
| ISAC sectorial | Táctico | Analizar IOC para determinar su relevancia respecto de la pila tecnológica | Actualizar SIEM, EDR y tareas de búsqueda proactiva de amenazas | Responsable del SOC |
| Boletines de proveedores de servicios en la nube | Operativo | Verificar servicios y regiones afectados | Escalar a ingeniería de nube | Responsable de DevOps |
| Notificaciones de parches de proveedores | Operativo | Confirmar producto, versión y alcance de despliegue | Añadir al ciclo de parches o a cambio de emergencia | Operaciones de TI |
| Notificaciones MDR | Táctico y operativo | Triaje frente a registros, activos y configuraciones de referencia conocidas | Abrir caso de detección, investigación o incidente | Operaciones de seguridad |
| Avisos de seguridad de proveedores | Operativo | Mapear con servicios contratados y flujos de datos | Actualizar riesgo de proveedores y controles compensatorios | Responsable del proveedor |
El seguimiento de eventos captura cómo un aviso concreto se convirtió en evidencia. Volviendo al escenario del martes por la mañana sobre transferencia de archivos, la entrada del registro debe capturar información suficiente para respaldar decisiones de riesgo, respuesta y cumplimiento.
| Campo | Ejemplo de entrada |
|---|---|
| Fecha y hora de recepción | 2026-05-26 07:42 UTC |
| Fuente | Alerta de CERT nacional, boletín de proveedor, notificación MDR |
| Tipo de fuente | Aviso gubernamental, aviso de proveedor, detección interna |
| Tecnología afectada | Servicio gestionado de transferencia de archivos, rango de versiones, bibliotecas dependientes |
| Propietario de negocio | Director de Operaciones de Plataforma |
| Propietario del riesgo | CISO |
| Vinculación con activos | Pasarela externa de transferencia de archivos, flujo de trabajo de informes a clientes |
| Severidad inicial | Alta pendiente de validación de exposición |
| Acciones requeridas | Comprobación de exposición, estado de parches, revisión de detección, confirmación del proveedor |
| Relevancia de cumplimiento | NIS2 Article 21, NIS2 Article 23 si se cumplen los criterios de incidente significativo, ciclo de vida de riesgo e incidentes de las TIC de DORA si aplica |
| Ubicación de evidencia | Ticket, actualización del registro de riesgos, cambio en SIEM, nota a la dirección |
Esto no es burocracia. Es el registro fáctico que demuestra que la organización cuenta con un proceso definido de entrada, validación, triaje, escalado y conservación de evidencia.
Del aviso a la evidencia de auditoría: un flujo de trabajo práctico
Un flujo de trabajo de inteligencia sobre amenazas debe responder rápidamente a seis preguntas: ¿estamos expuestos?, ¿qué gravedad tiene?, ¿qué debe cambiar?, ¿quién es responsable?, ¿tenemos que notificar? y ¿qué evidencia debe conservarse?
1. Validar la exposición y el impacto en el negocio
Las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022 exigen que el SGSI refleje el contexto, las obligaciones y las dependencias reales de la organización. La primera tarea no es parchear a ciegas. Es validar la exposición.
Pregunte:
- ¿Ejecutamos la tecnología afectada?
- ¿Está expuesta a internet?
- ¿La utiliza un servicio crítico de negocio?
- ¿Trata datos personales?
- ¿La opera un proveedor o proveedor de servicios gestionados?
- ¿Es relevante para una función crítica o importante según DORA?
- ¿Es relevante para servicios dentro del alcance de NIS2?
- ¿Existen obligaciones contractuales de notificación a clientes?
- ¿Los registros están disponibles, completos y con sincronización horaria?
Si los datos personales pueden verse afectados, la responsabilidad proactiva del RGPD de la UE también entra en el análisis. El RGPD de la UE exige una seguridad del tratamiento adecuada y responsabilidad proactiva demostrable, incluida la capacidad de evaluar si se ha producido una brecha de seguridad de los datos personales y si se requiere notificación.
2. Actualizar el registro de riesgos
La Política de gestión de riesgos Política de gestión de riesgos - pyme ofrece una regla temporal sencilla en la cláusula 5.1.3 de Requisitos de gobernanza:
Los riesgos deben revisarse trimestralmente y actualizarse cuando se produzcan eventos significativos.
Un aviso creíble de explotación activa es un evento significativo. La actualización no debe esperar a la siguiente revisión trimestral.
| Elemento de riesgo | Evaluación actualizada |
|---|---|
| Amenaza | Explotación activa de una vulnerabilidad en transferencia gestionada de archivos |
| Vulnerabilidad | Versión afectada, interfaz expuesta, configuración débil, parche pendiente |
| Activo | Plataforma de intercambio de datos con clientes |
| Consecuencia | Interrupción del servicio, acceso no autorizado a datos, notificación regulatoria, impacto en la confianza del cliente |
| Probabilidad | Incrementada debido a explotación activa observada en el entorno real |
| Controles existentes | MFA, WAF, protección de endpoints, supervisión SIEM, copia de seguridad, SLA de proveedor |
| Deficiencias de control | Parche no confirmado, detección no ajustada, evidencia del proveedor pendiente |
| Tratamiento | Parche de emergencia, restricción temporal de red, búsqueda de IOC, atestación del proveedor, evaluación de impacto en clientes |
| Propietario del riesgo residual | CISO y responsable de Operaciones de Plataforma |
Esto conecta directamente con las cláusulas 6.1.1-6.1.3 de ISO/IEC 27001:2022. La organización identifica el riesgo, analiza la probabilidad y las consecuencias, prioriza el tratamiento, selecciona controles, mantiene la Declaración de Aplicabilidad, crea un plan de tratamiento y obtiene la aprobación del riesgo residual.
3. Priorizar el tratamiento de vulnerabilidades usando inteligencia sobre exploits
Zenith Blueprint, en la fase Controles en acción, paso 19, Controles tecnológicos I, explica por qué la gestión de vulnerabilidades es una parte esencial de la higiene cibernética:
Gestionar las vulnerabilidades es una de las áreas más críticas de la higiene cibernética moderna. Aunque los cortafuegos y las herramientas antivirus proporcionan protección, pueden verse socavados si se dejan expuestos sistemas sin parches o servicios mal configurados. Para cumplir este control, las organizaciones deben implantar un proceso estructurado y repetible para identificar, evaluar y tratar vulnerabilidades.
CVSS por sí solo no basta. Una vulnerabilidad con puntuación media bajo explotación activa en un sistema expuesto a internet puede ser más urgente que una vulnerabilidad con puntuación alta oculta dentro de un laboratorio segmentado.
| Factor | Pregunta | Evidencia |
|---|---|---|
| Actividad de explotación | ¿La explotación ha sido observada o notificada por fuentes de confianza? | Alerta CERT, referencia CISA KEV, boletín de proveedor, informe MDR |
| Exposición | ¿El activo está expuesto a internet o es alcanzable por proveedores? | Inventario de activos, postura de seguridad en la nube, escaneo de red |
| Criticidad de negocio | ¿Soporta servicios esenciales o funciones críticas? | Análisis de impacto en el negocio, mapeo de funciones DORA |
| Sensibilidad de datos | ¿Trata datos personales, datos financieros regulados o datos confidenciales de clientes? | Inventario de datos, EIPD, registros de tratamiento |
| Controles compensatorios | ¿Pueden WAF, reglas de cortafuegos, segmentación, EDR o deshabilitación de funcionalidades reducir el riesgo? | Ticket de cambio, regla de cortafuegos, política EDR |
| Riesgo operativo | ¿Podría el parcheo de emergencia interrumpir la prestación de un servicio crítico? | Evaluación del cambio, plan de reversión, plan de continuidad |
Esto produce una decisión defendible. También respalda NIS2 Article 21(2)(e) para la gestión de vulnerabilidades, NIS2 Article 21(2)(g) para la higiene cibernética y las expectativas de gestión del riesgo de las TIC de DORA.
4. Convertir la inteligencia en supervisión y detección
La inteligencia sobre amenazas debe llegar al registro y la supervisión. La Política de registro y supervisión Política de registro y supervisión - pyme establece en la cláusula 6.2.1 de Requisitos de implantación de la política:
Las herramientas de seguridad (por ejemplo, antivirus, cortafuegos, VPN) deben configurarse para generar alertas ante escenarios de amenaza definidos, incluidos:
El extracto fija claramente la intención del control: los escenarios de amenaza definidos deben impulsar el alertado.
Zenith Blueprint, en la fase Controles en acción, paso 19, describe así las actividades de supervisión:
Si el registro de eventos es el acto de registrar lo que ocurre en su entorno, la supervisión es el acto de observar, comprender y responder a esos eventos. Este control consiste en observar activamente redes, sistemas y aplicaciones para detectar actividad inusual, no solo a posteriori, sino en tiempo real o casi real, cuando sea posible.
Para el escenario de transferencia de archivos, el SOC o el proveedor de TI debe:
- Añadir o validar IOC procedentes del CERT y del aviso del proveedor.
- Buscar en los registros rutas de explotación conocidas, cargas sospechosas, indicadores de web shell, ejecución inusual de procesos y conexiones salientes inesperadas.
- Confirmar que se conservan registros de autenticación, actividad administrativa, acceso a archivos, API y red.
- Ajustar alertas SIEM para el patrón de explotación.
- Crear una nota de caso que explique qué se buscó, qué se encontró y quién lo revisó.
- Escalar a clasificación de incidente si los indicadores muestran compromiso, exposición de datos o impacto en el servicio.
Aquí es donde la notificación de incidentes se vuelve práctica. NIS2 Article 23 exige una notificación por fases de los incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas, actualizaciones intermedias previa solicitud y un informe final a más tardar un mes después de la notificación. DORA exige a las entidades financieras detectar, gestionar, clasificar y notificar incidentes importantes relacionados con las TIC mediante el proceso por fases definido por el reglamento y las normas técnicas relacionadas.
La inteligencia sobre amenazas ayuda a determinar si la organización sigue en respuesta a vulnerabilidades, evaluación de eventos de seguridad o notificación regulada de incidentes.
Un flujo de trabajo, múltiples obligaciones de cumplimiento
La inteligencia sobre amenazas es un flujo de trabajo ideal de cumplimiento integrado porque la misma evidencia respalda varios regímenes.
| Marco o regulación | Qué espera | Evidencia de inteligencia sobre amenazas |
|---|---|---|
| ISO/IEC 27001:2022 | SGSI consciente del contexto, evaluación de riesgos, selección de controles, planificación del tratamiento, mejora continua | Alcance del SGSI, registro de riesgos, Declaración de Aplicabilidad, plan de tratamiento, entradas para la revisión por la dirección |
| ISO/IEC 27002:2022 | Inteligencia sobre amenazas, gestión de vulnerabilidades, registro de eventos, supervisión, evaluación de incidentes, protección contra el software malicioso | Registro de inteligencia sobre amenazas, actualizaciones de IOC, reglas SIEM, tickets de parches, notas de triaje de incidentes |
| NIS2 | Gestión de riesgos, gestión de incidentes, higiene cibernética, gestión de vulnerabilidades, seguridad de la cadena de suministro, supervisión de la gobernanza | Evidencia de Article 20 y 21, informes a la dirección, flujo de trabajo CSIRT, seguimiento de avisos de proveedores |
| DORA | Marco de riesgo de las TIC, detección, continuidad, ciclo de vida de incidentes, pruebas de resiliencia, riesgo de terceros proveedores de TIC | Clasificación de activos de TIC, casos de detección, registros de clasificación de incidentes, entradas para pruebas de resiliencia, registros de proveedores de TIC |
| RGPD de la UE | Seguridad del tratamiento, responsabilidad proactiva, soporte para detección y notificación de brechas | Evaluación de impacto de datos, registros de acceso, evidencia de supervisión, registro de evaluación de brechas |
| NIST CSF 2.0 | Resultados de Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar | Perfil actual, perfil objetivo, plan de acción priorizado, comunicaciones de riesgo |
| COBIT 2019 como lente de auditoría | Gobernanza sobre riesgo, controles, desempeño, aseguramiento y responsabilidad proactiva | Titularidad de controles, métricas de gestión, evidencia de aseguramiento, seguimiento de remediación de incidencias |
NIST CSF 2.0 es especialmente útil para la comunicación con la alta dirección. Sus funciones principales, Gobernar, Identificar, Proteger, Detectar, Responder y Recuperar, convierten la inteligencia técnica en una narrativa comprensible para el consejo de administración:
- Gobernar: las fuentes de inteligencia sobre amenazas, los responsables y las líneas de reporte están definidos.
- Identificar: los activos, proveedores, servicios de negocio y datos afectados están mapeados.
- Proteger: se actualizan el parcheo, el endurecimiento, la segmentación y las firmas de protección de endpoints.
- Detectar: se despliegan reglas de supervisión, IOC y tareas de búsqueda proactiva de amenazas.
- Responder: se revisan procedimientos de respuesta a incidentes, reglas de triaje y umbrales de notificación.
- Recuperar: se validan copias de seguridad, prioridades de restauración y lecciones aprendidas.
Esto convierte la inteligencia sobre ciberamenazas sin procesar en gobernanza del riesgo.
La perspectiva del auditor: qué solicitará
Un proceso sólido de inteligencia sobre amenazas debe resistir distintos estilos de auditoría. Un auditor ISO, revisor NIS2, autoridad supervisora de DORA, evaluador NIST CSF, auditor orientado a COBIT 2019, profesional de ISACA o revisor de privacidad pueden usar lenguajes distintos, pero todos convergen en la evidencia.
| Lente del auditor | Pregunta de auditoría probable | Evidencia que la responde |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿Cómo influyen el contexto externo e interno en los riesgos y controles del SGSI? | Registro de inteligencia sobre amenazas, metodología de riesgos, registro de riesgos actualizado, justificación de la Declaración de Aplicabilidad |
| Revisor de controles ISO/IEC 27002:2022 | ¿Cómo se conectan los controles 5.7, 8.8, 8.16, 8.15, 8.7 y 5.25? | Lista de fuentes, triaje de vulnerabilidades, ajuste de SIEM, actualizaciones de firmas antimalware, registros de evaluación de eventos |
| Revisor NIS2 | ¿Cómo cumple la supervisión por la dirección, la higiene cibernética, la gestión de vulnerabilidades, la gestión de incidentes y la seguridad de la cadena de suministro? | Mapeo de Article 20 y 21, informes a la dirección, procedimiento de notificación CSIRT, flujo de trabajo de avisos de proveedores |
| Autoridad supervisora de DORA | ¿Cómo actualiza la inteligencia sobre amenazas el riesgo de las TIC, la detección, las pruebas de resiliencia y la clasificación de incidentes? | Marco de riesgo de las TIC, mapeo de funciones críticas, casos de detección, registros de clasificación de incidentes, alcance de pruebas de resiliencia |
| Evaluador NIST CSF | ¿Cuál es su perfil actual, su perfil objetivo y su plan de acción priorizado? | Perfil CSF, evaluación de brechas, plan de acción, registro de actualización continua |
| Auditor COBIT 2019 o ISACA | ¿Quién es propietario del control, cómo se mide el desempeño y cómo se remedian las excepciones? | RACI, KPI, KRI, registro de excepciones, tickets de remediación, aprobación formal de la dirección |
| Auditor del RGPD de la UE o revisor de privacidad | ¿Cómo protegieron la supervisión y la gestión de vulnerabilidades los datos personales y respaldaron la evaluación de brechas? | Mapa de tratamiento de datos, registros, evaluación de brechas, evidencia de medidas técnicas y organizativas |
Zenith Controls proporciona la interpretación de cumplimiento transversal para estas conversaciones. Para el control 8.16, Actividades de supervisión, la guía conecta la supervisión con la seguridad y la responsabilidad proactiva en materia de brechas del RGPD de la UE, la gestión y notificación de incidentes de NIS2, y las expectativas de detección y respuesta de DORA. Para el control 8.8, Gestión de vulnerabilidades técnicas, conecta la gestión de vulnerabilidades con la seguridad del tratamiento del RGPD de la UE, NIS2 Article 21(2)(e) y la gestión proactiva del riesgo de las TIC de DORA.
Esa es la convergencia de evidencia que los auditores quieren ver.
Información a la dirección: el informe trimestral de tendencias de amenazas
El registro de inteligencia sobre amenazas no debe morir en el SOC. Zenith Blueprint recomienda un breve informe trimestral de tendencias de amenazas para las partes interesadas clave. Clarysec recomienda un informe de gestión de una página con cinco secciones:
- Las tres principales tendencias de amenaza relevantes por impacto en el negocio.
- Tecnologías o proveedores más expuestos.
- Vulnerabilidades críticas parcheadas, mitigadas o aceptadas.
- Mejoras realizadas en detección y respuesta.
- Decisiones requeridas de la dirección.
Un buen informe a la dirección no enumera 400 CVE. Explica el movimiento del riesgo. Por ejemplo:
- El ransomware dirigido a proveedores de servicios gestionados aumentó la prioridad de revisión de proveedores.
- La explotación de plataformas de transferencia de archivos activó parcheo de emergencia y una regla de cortafuegos compensatoria.
- Los ataques a identidades en la nube provocaron la revisión de excepciones de MFA y el endurecimiento del acceso condicional.
- La inteligencia de un ISAC sectorial dio lugar a nuevas simulaciones de phishing para los equipos de finanzas y soporte.
- El mapeo de funciones críticas de DORA reveló una deficiencia de supervisión en un flujo de trabajo de terceros.
Este informe respalda la responsabilidad de la dirección en NIS2, la gobernanza del riesgo de las TIC en DORA, la revisión por la dirección de ISO/IEC 27001:2022 y el aseguramiento de clientes.
Patrones de fallo comunes
Los programas de inteligencia sobre amenazas suelen parecer maduros en presentaciones, pero débiles bajo auditoría. Los patrones de fallo más comunes son:
- Demasiadas fuentes y ningún criterio de validación.
- Ausencia de vínculo entre la inteligencia y el inventario de activos.
- Ausencia de actualización documentada del riesgo tras avisos importantes.
- Prioridad de parches basada únicamente en la severidad del escáner.
- Avisos de proveedores gestionados fuera del SGSI.
- Reglas del SOC actualizadas sin registros de cambios.
- Umbrales de incidentes no alineados con los flujos de trabajo de notificación de NIS2 o DORA.
- Información al consejo de administración centrada en el volumen de alertas en lugar del riesgo de negocio.
- Ausencia de evidencia de que las lecciones aprendidas modificaron los controles.
- Ausencia de responsable para mantener el registro de inteligencia sobre amenazas.
La solución no es comprar otra fuente. La solución es integrar controles.
Lista de verificación de preparación de 10 puntos para 2026
Utilice esta lista como una revisión interna práctica.
| Pregunta de preparación | Sí o no |
|---|---|
| ¿Mantenemos un registro de inteligencia sobre amenazas aprobado, con responsables de fuentes y reglas de validación? | |
| ¿Los avisos de CERT, CSIRT, ISAC, proveedores, nube, MDR y proveedores externos se enrutan a roles nominales? | |
| ¿Los avisos significativos activan la revisión del registro de riesgos fuera del ciclo trimestral? | |
| ¿La priorización de vulnerabilidades incluye actividad de explotación, criticidad de activos, sensibilidad de datos y exposición? | |
| ¿Los IOC y escenarios de amenaza se convierten en reglas de supervisión o tareas de búsqueda proactiva de amenazas? | |
| ¿Se comprueba la vigencia de las firmas de endpoints, detecciones en la nube y fuentes dinámicas de inteligencia sobre amenazas? | |
| ¿Los avisos de proveedores se evalúan frente al riesgo de la cadena de suministro y las obligaciones contractuales? | |
| ¿Los criterios de clasificación de incidentes están alineados con los flujos de trabajo de notificación de NIS2 y DORA cuando aplica? | |
| ¿La dirección recibe un informe trimestral de tendencias de amenazas? | |
| ¿Podemos producir un paquete de evidencia para un auditor, regulador o cliente en el plazo de un día laborable? |
Si la respuesta a cualquiera de estas preguntas es “no”, la organización no tiene simplemente un problema de inteligencia sobre amenazas. Tiene un problema de integración del SGSI.
Cómo ayuda Clarysec a convertir la inteligencia sobre amenazas en evidencia
El método de Clarysec está diseñado para organizaciones que necesitan seguridad práctica y cumplimiento creíble al mismo tiempo.
Zenith Blueprint proporciona la ruta de implantación de 30 pasos, incluido el paso 22 para el registro de inteligencia sobre amenazas y el paso 19 para la gestión de vulnerabilidades y las actividades de supervisión. Las políticas empresariales y para pymes de Clarysec convierten esas expectativas en procedimientos basados en roles para gestión de riesgos, gestión de vulnerabilidades, protección de endpoints, registro, supervisión y evidencia de auditoría. Zenith Controls proporciona después la interpretación de cumplimiento transversal, mostrando cómo los controles de ISO/IEC 27002:2022 se conectan con NIS2, DORA, RGPD de la UE, NIST CSF 2.0, COBIT 2019 y la evidencia de auditoría.
Para el CISO del martes por la mañana, la respuesta al CFO queda clara:
“Recibimos el aviso, validamos la exposición, actualizamos el registro de riesgos, priorizamos el parcheo en función de la explotación activa, ajustamos la supervisión, comprobamos la dependencia del proveedor, evaluamos los umbrales de notificación de incidentes, informamos a la dirección y conservamos evidencia. No estamos improvisando. Seguimos nuestro SGSI.”
Así debe ser la inteligencia sobre amenazas de ISO 27001 para la higiene cibernética de NIS2 y la evidencia de riesgo de las TIC de DORA en 2026.
Próximos pasos
Si su organización recibe inteligencia sobre amenazas pero no puede demostrar cómo cambia las decisiones de riesgo, los controles, la detección, la respuesta a incidentes, la gestión de proveedores y la evidencia regulatoria, empiece esta semana con tres acciones:
- Construya o actualice su registro de inteligencia sobre amenazas utilizando Zenith Blueprint, fase Controles en acción, paso 22.
- Mapee su proceso actual frente a los controles 5.7, 8.8, 8.15, 8.16, 8.7 y 5.25 de ISO/IEC 27002:2022 utilizando Zenith Controls.
- Alinee sus políticas, especialmente la Política de gestión de riesgos, la Política de gestión de vulnerabilidades y parches, la Política de registro y supervisión y la Política de Auditoría y Supervisión del Cumplimiento, para que cada aviso pueda convertirse en evidencia defendible.
Clarysec puede ayudarle a convertir fuentes de amenazas, avisos, notificaciones de proveedores, inteligencia de vulnerabilidades y señales de detección en un modelo operativo alineado con ISO/IEC 27001:2022, preparado para NIS2 y consciente de DORA.
Descargue los toolkits de Clarysec, solicite un recorrido o reserve una evaluación de preparación para ver cómo resistiría su proceso actual de inteligencia sobre amenazas ante un auditor ISO, un revisor NIS2, una autoridad supervisora de DORA o una solicitud de aseguramiento de cliente.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
