NIS2 y DORA: Guia Tecnica de Cumplimiento para 2026

La realidad que estamos viendo en 2026 es que las directivas NIS2 y DORA han dejado de ser un horizonte lejano para convertirse en una presión operativa diaria. En los últimos seis meses, en Riskitera hemos pasado de realizar evaluaciones de preparación teóricas a gestionar proyectos de implementación a contrarreloj para entidades financieras y operadores de servicios esenciales que se han dado cuenta, demasiado tarde en muchos casos, de que el cumplimiento ya no es una cuestión de checklists de auditoría, sino de arquitecturas de seguridad profundamente integradas. El error más común que observo, especialmente en empresas españolas del sector industrial y de utilities, es abordar NIS2 y DORA como dos marcos separados. Eso es un enfoque costoso y miope. La superposición es masiva: la gestión de riesgos, la resiliencia operativa, la notificación de incidentes, los controles de cadena de suministro y, sobre todo, la necesidad de una ciberseguridad "by design and by default". La guía técnica que importa ahora no es la que repite los artículos de la directiva, sino la que explica cómo construir una base técnica común que satisfaga ambos regímenes sin duplicar esfuerzos y, lo que es más crítico, que realmente mejore tu postura de seguridad.

Vamos al lío. La diferencia fundamental que marca 2026 es el nivel de prescripción técnica. DORA, en particular, con sus estándares técnicos de regulación (RTS) ya plenamente aplicables, exige controles específicos y demostrables. No vale con decir "tenemos un SOC". Hay que demostrar cómo se realiza la detección de amenazas, con qué herramientas, con qué nivel de automatización y con qué tiempos de respuesta. En un ejercicio de preparación para DORA que hicimos el mes pasado con una aseguradora mediana, el gap más grande no estaba en la política de parcheo, sino en la incapacidad de correlacionar eventos de sus herramientas de seguridad (un EDR de CrowdStrike Falcon 7.12 y un SIEM Splunk) con los procesos de negocio críticos definidos en su evaluación de impacto en la continuidad del negocio. La tecnología estaba, pero la gobernanza y la integración técnica para la demostración del cumplimiento brillaban por su ausencia.

¿Cómo construir una arquitectura técnica común para NIS2 y DORA?

El núcleo de ambas regulaciones es la gestión de riesgos de ciberseguridad. Pero en 2026, "gestión de riesgos" significa tener una plataforma centralizada que ingiera datos de activos, vulnerabilidades, amenazas y controles, y que pueda generar evidencias automáticamente. Las hojas de cálculo de Excel y los documentos de Word son, sencillamente, inviables y serán penalizadas en las supervisiones. La base es un CMDB (Configuration Management Database) precisa y un sistema de gestión de vulnerabilidades que vaya más allá del escaneo tradicional. Herramientas como ServiceNow Security Operations (con su módulo de Vulnerability Response) o plataformas especializadas como Tenable.io o Qualys VMDR se han vuelto casi obligatorias, pero su valor está en cómo las integras.

Por ejemplo, necesitas un proceso automatizado que, cuando se identifique una vulnerabilidad crítica (digamos, un CVE-2026-12345 en un servidor de bases de datos Oracle que soporta un proceso financiero crítico bajo DORA), no solo genere un ticket, sino que:

Identifique automáticamente el activo como "crítico" según tus taxonomías NIS2/DORA.
Consulte la CMDB para entender qué aplicación de negocio y qué equipo responsable está afectado.
Evalúe la exposición real (¿está expuesto a internet? ¿hay exploit público?).
Genere una métrica de riesgo ajustada y la eleve a tu panel de gobierno (GRC).
Inicie un flujo de trabajo de parcheo de emergencia con aprobaciones predefinidas.

Este nivel de integración requiere APIs y orquestación. Un script simple de Python usando las APIs de Tenable y ServiceNow puede ser el pegamento. Te pongo un ejemplo realista que hemos implementado para clientes:

#!/usr/bin/env python3
"""
Script de orquestacion NIS2/DORA: Cierra la brecha entre deteccion de vulns y gestion de remediacion.
Usa APIs de Tenable.io y ServiceNow. Version 2026.03.
"""
import requests
import json
from datetime import datetime, timedelta

# Configuracion (usar un vault en produccion, obviamente)
TENABLE_ACCESS_KEY = "tu_access_key_tenable"
TENABLE_SECRET_KEY = "tu_secret_key_tenable"
SERVICENOW_INSTANCE = "tu_instancia.service-now.com"
SERVICENOW_CREDS = ("usuario", "password")

def fetch_critical_vulns():
    """Busca vulnerabilidades criticas (CVSS >= 7.0) descubiertas en las ultimas 24h."""
    url = "https://cloud.tenable.com/workbenches/vulnerabilities"
    headers = {"X-ApiKeys": f"accessKey={TENABLE_ACCESS_KEY}; secretKey={TENABLE_SECRET_KEY}"}
    params = {
        "filter.0.filter": "cvss_score",
        "filter.0.quality": "gte",
        "filter.0.value": "7.0",
        "filter.1.filter": "discovered",
        "filter.1.quality": "gte",
        "filter.1.value": (datetime.now() - timedelta(days=1)).strftime('%Y-%m-%d')
    }
    
    response = requests.get(url, headers=headers, params=params)
    vulns = response.json().get('vulnerabilities', [])
    
    # Filtrar solo las que afecten a activos etiquetados como 'DORA_CRITICAL' o 'NIS2_ESSENTIAL'
    filtered_vulns = []
    for vuln in vulns:
        asset_details = get_asset_details(vuln['asset_id'])
        tags = asset_details.get('tags', [])
        if any(tag['key'] in ['DORA_CRITICAL', 'NIS2_ESSENTIAL'] for tag in tags):
            vuln['asset_details'] = asset_details
            filtered_vulns.append(vuln)
    return filtered_vulns

def get_asset_details(asset_id):
    """Obtiene detalles y tags de un activo desde Tenable."""
    url = f"https://cloud.tenable.com/assets/{asset_id}"
    headers = {"X-ApiKeys": f"accessKey={TENABLE_ACCESS_KEY}; secretKey={TENABLE_SECRET_KEY}"}
    response = requests.get(url, headers=headers)
    return response.json()

def create_snow_incident(vuln):
    """Crea un incidente de seguridad en ServiceNow con la info de la vulnerabilidad."""
    url = f"https://{SERVICENOW_INSTANCE}/api/now/table/incident"
    headers = {"Content-Type": "application/json", "Accept": "application/json"}
    
    # Mapeo de datos clave para evidenciar cumplimiento (DORA Art. 6, NIS2 Art. 21)
    short_description = f"[NIS2/DORA-CRIT] {vuln['plugin_name']} en {vuln['asset_details']['fqdn']}"
    description = f"""
    **Vulnerabilidad de Cumplimiento Regulatorio**
    CVE/Plugin: {vuln.get('plugin_id', 'N/A')} - {vuln['plugin_name']}
    CVSS Score: {vuln.get('cvss_score', 'N/A')}
    Activo Critico: {vuln['asset_details']['fqdn']} (IP: {vuln['asset_details']['ipv4']})
    Tags Regulatorios: {[tag['key'] for tag in vuln['asset_details'].get('tags', []) if 'DORA' in tag['key'] or 'NIS2' in tag['key']]}
    Proceso de Negocio Afectado: {vuln['asset_details'].get('business_process', 'Por determinar - revisar CMDB')}
    
    **Accion Requerida:** Parcheo o mitigacion en 72h maximo segun politica interna DORA-NIS2.
    Evidencia para supervision: Este ticket y su resolucion.
    """
    
    data = {
        "short_description": short_description,
        "description": description,
        "urgency": "1",  # Maxima urgencia
        "impact": "1",
        "category": "Security",
        "subcategory": "Vulnerability",
        "assignment_group": "Security Operations",
        "comments": "Generado automaticamente por orquestacion de cumplimiento NIS2/DORA."
    }
    
    response = requests.post(url, auth=SERVICENOW_CREDS, headers=headers, data=json.dumps(data))
    return response.json()

if __name__ == "__main__":
    print("[*] Iniciando escaneo de vulnerabilidades criticas para cumplimiento...")
    critical_vulns = fetch_critical_vulns()
    print(f"[*] Encontradas {len(critical_vulns)} vulnerabilidades criticas en activos regulados.")
    for vuln in critical_vulns:
        result = create_snow_incident(vuln)
        print(f"[+] Incidente creado en ServiceNow: {result.get('result', {}).get('number', 'Error')}")

Este tipo de automatización no es un lujo, es el mínimo viable para gestionar la escala que requieren estas normativas. Sin ella, los equipos se ahogan en datos y no pueden generar las evidencias de auditoría consistentes que van a pedir el Banco de España o el INCIBE en sus capacidades de supervisión.

nis2-y-dora-guia-tecnica-de-cumplimiento-para-2026 diagram 1

¿Qué demonios son los "Testing Avanzados" que exige DORA y cómo se implementan?

Este es uno de los puntos que más dolores de cabeza está causando. El Reglamento Técnico de Supervisión (RTS) de DORA es explícito en la necesidad de "advanced testing", que incluye pruebas de penetración threat-led (parecidas a los ejercicios Red Team) y ensayos de resistencia operacional. La clave aquí es que un simple escaneo de vulnerabilidades o un pentest tradicional de caja negra ya no son suficientes. Tienes que demostrar que pruebas escenarios realistas de ataque contra tus procesos financieros críticos.

En un proyecto reciente para un proveedor de servicios de pago, diseñamos un ejercicio de Red Team específico para DORA. El objetivo no era encontrar 50 vulnerabilidades XSS, sino intentar comprometer el sistema central de liquidación de pagos (un proceso crítico listado en su evaluación). La metodología fue:

Inteligencia de amenazas aplicada: Usamos plataformas como Recorded Future o Intel 471 para identificar TTPs (Tácticas, Técnicas y Procedimientos) actuales de grupos como FIN11 o Lazarus que estuvieran atacando el sector financiero en 2026.
Simulación de cadena de suministro: Emulamos un ataque a un desarrollador de software tercerizado (en el ámbito de DORA y NIS2, la seguridad de la cadena de suministro es primordial) para introducir un backdoor en una actualización de una librería interna.
Movimiento lateral con contexto financiero: Usamos herramientas como BloodHound 4.3 para mapear los privilegios en el Active Directory, pero con el foco en llegar a los servidores que alojaban las aplicaciones de compensación y liquidación.
Prueba de resiliencia operacional: Una vez "dentro" del sistema crítico, simulamos una acción de ransomware (en lugar de ejecutarlo realmente) y monitorizamos la respuesta del equipo de crisis, la activación de los planes de continuidad y la capacidad de recuperación desde backups air-gapped.

El informe resultante no fue un listado de CVEs, sino una narrativa que mapeaba cada paso del ataque simulado contra los controles requeridos por DORA (detección, respuesta, recuperación, comunicación). Esto es lo que los supervisores quieren ver: que entiendes tus amenazas y has probado tu capacidad para resistirlas de forma integral.

Para las pruebas técnicas continuas, más allá de los ejercicios anuales, es esencial integrar herramientas de Attack Surface Management (ASM) como Microsoft Defender External Attack Surface o Randori, y plataformas de Breach and Attack Simulation (BAS) como Cymulate o AttackIQ. Estas últimas te permiten ejecutar de forma automatizada y continua simulaciones de los vectores de ataque más relevantes, generando métricas de eficacia de controles (por ejemplo, "nuestro EDR detecta y bloquea el 98% de las técnicas de ejecución de PowerShell malicioso").

¿Cómo abordar la notificación de incidentes en 2026? NIS2 vs DORA

Los plazos de notificación son un quebradero de cabeza operativo. NIS2 exige una notificación inicial en 24 horas y un informe detallado en 72 horas. DORA mantiene plazos similares para incidentes significativos. El problema gordo aquí es que la mayoría de los SOCs no tienen los flujos de trabajo integrados para recopilar la información necesaria de forma tan rápida.

Necesitas plantillas predefinidas y automatización en tu SOAR (Security Orchestration, Automation and Response). En nuestro SOC, hemos creado playbooks en Palo Alto Networks XSOAR o en TheHive que se activan cuando un incidente alcanza un umbral de severidad predefinido (usando taxonomías como MITRE ATT&CK y mapeando a procesos de negocio críticos). El playbook hace lo siguiente de forma automatizada:

Recolecta evidencias técnicas relevantes (logs del EDR, paquetes PCAP de sesiones sospechosas, volcados de memoria si es posible).
Consulta la CMDB para determinar si los activos afectados están bajo el ámbito de NIS2 o DORA.
Genera un borrador del informe inicial con los campos obligatorios (impacto estimado, servicios afectados, medidas mitigatorias iniciales).
Asigna tareas a los equipos legales y de comunicación para la notificación formal.

Aquí tienes un ejemplo de un fragmento de un playbook para TheHive en formato JSON, que muestra la lógica de escalado automático:

{
  "name": "Escalado_Automático_NIS2_DORA",
  "description": "Playbook que evalúa y escala incidentes con impacto regulatorio.",
  "startRequirements": ["alert"],
  "tasks": [
    {
      "name": "Evaluar_Impacto_Regulatorio",
      "action": "queryCMDB",
      "config": {
        "query": "SELECT regulatory_frameworks, business_criticality FROM assets WHERE ip = '{{alert.source_ip}}' OR hostname = '{{alert.hostname}}'"
      }
    },
    {
      "name": "Clasificar_Severidad_Regulatoria",
      "action": "setSeverity",
      "conditions": [
        {
          "if": "{{task.Evaluar_Impacto_Regulatorio.output.regulatory_frameworks contains 'DORA'}} AND {{alert.tactic contains 'Impact'}}",
          "then": {"set": "Critical"}
        },
        {
          "if": "{{task.Evaluar_Impacto_Regulatorio.output.business_criticality == 'HIGH'}}",
          "then": {"set": "High"}
        }
      ]
    },
    {
      "name": "Notificacion_Inicial_Automatizada",
      "action": "createReport",
      "config": {
        "template": "NIS2_DORA_Initial_Notification.md",
        "variables": {
          "incident_id": "{{alert.id}}",
          "detection_time": "{{alert.timestamp}}",
          "affected_assets": "{{task.Evaluar_Impacto_Regulatorio.output}}",
          "ttp_identified": "{{alert.tactic}}"
        },
        "notify": ["CISO_Office", "Legal_Compliance_Team"]
      },
      "conditions": [{"if": "{{incident.severity == 'Critical'}}"}]
    }
  ]
}

La clave es que la evidencia técnica (logs, alertas) esté ya enlazada con el contexto de negocio y regulatorio desde el minuto uno. Si tu SIEM (ya sea Splunk, Elastic Security 8.x o Microsoft Sentinel) no tiene enriquecimiento de activos con etiquetas NIS2/DORA, estás construyendo sobre arena.

La gestión de terceros y la cadena de suministro: el talón de Aquiles

Tanto NIS2 (Artículo 21) como DORA (Título V) ponen un énfasis brutal en la seguridad de la cadena de suministro. En 2026, no puedes limitarte a un cuestionario anual de seguridad a tu proveedor de cloud o de software. Tienes que tener una vigilancia continua. Esto implica:

Cláusulas contractuales específicas: Derecho a auditoría, obligación de notificación de incidentes en plazos muy cortos (inferiores a 24h), requisitos de certificación (ISO 27001, SOC2 Tipo II).
Monitorización técnica continua: Para proveedores críticos (como un CSP que aloje datos de pago), necesitas herramientas de monitorización de seguridad gestionada (MSSP) o acceso a sus logs a través de APIs (como el AWS Security Hub o Azure Defender for Cloud) para agregarlos a tu propio SIEM.
Evaluación de riesgos dinámica: Usar plataformas como SecurityScorecard, BitSight o UpGuard para tener una puntuación de seguridad casi en tiempo real de tus proveedores clave y configurar alertas si su rating cae por debajo de un umbral.

Recuerdo un incidente en 2024 donde un ataque a un proveedor de software de nóminas afectó a decenas de empresas europeas. Bajo NIS2 y DORA, la responsabilidad de gestionar ese riesgo recae claramente en la entidad que contrata el servicio. Si no has hecho tu diligencia debida y no tienes un plan de acción para cuando tu proveedor sufra un incidente, las multas pueden ser compartidas.

Herramientas imprescindibles en tu stack técnico para 2026

No se trata de comprar todo lo que brilla, sino de integrar un núcleo sólido. Esta sería mi recomendación basada en lo que está funcionando en clientes del IBEX35 y entidades financieras:

Sinceramente, la mayoría de empresas españolas con las que hablo están razonablemente cubiertas en las tres primeras categorías, pero cojean gravemente en la integración entre ellas (el SOAR) y en la gestión moderna de identidades y terceros. Sin una orquestación sólida, es imposible cumplir con los plazos de notificación o demostrar una gestión de riesgos ágil.

El camino hacia 2026 y más allá no es about checkboxes. Es sobre construir una infraestructura de seguridad resiliente, automatizada y demostrable. Las directivas NIS2 y DORA, en el fondo, lo que están haciendo es obligar al mercado a madurar técnicamente. El que lo vea solo como una carga burocrática perderá tiempo, dinero y, probablemente, su tranquilidad cuando llegue la primera supervisión o, peor, un incidente real. El que lo aborde como una oportunidad para modernizar y integrar su seguridad, no solo estará cumpliendo, sino que estará construyendo una ventaja competitiva real en un mundo digital cada vez más hostil.

Recursos y referencias

Texto Oficial de la Directiva NIS2: Diario Oficial de la Unión Europea - DIRECTIVA (UE) 2022/2555
Texto Oficial del Reglamento DORA: Diario Oficial de la Unión Europea - REGLAMENTO (UE) 2022/2554
ENISA - Guías de Implementación de NIS2: ENISA NIS2 Implementation Support (Contiene documentos esenciales sobre gestión de incidentes, cadena de suministro, etc.)
Repositorio GitHub de Sigma Rules: SigmaHQ/sigma - Reglas de detección genéricas que puedes adaptar para tu SIEM y mejorar la cobertura de amenazas, clave para los requisitos de detección avanzada.