IT-Manager.tech

Decisiones presupuestarias en el marco de NIS2: cálculo de inversiones en tecnología, personal y auditorías

Architekturdiagramm und Budgetunterlagen zur Planung von NIS2-Investitionen in Technik, Personal und Prüfungen
Budgetplanung unter NIS2 gelingt, wenn Risiken, Kontrollen und Nachweise gemeinsam betrachtet werden – nicht als getrennte Einzelposten.

Quien hoy prepara decisiones presupuestarias bajo NIS2 rara vez se plantea la pregunta «¿Cuánto cuesta la seguridad?», y se enfrenta más bien a tres problemas más precisos: ¿Qué es obligatorio por normativa, qué tiene sentido desde una perspectiva basada en riesgos, y cómo puede representarse eso en un presupuesto de modo que Operaciones, Compras, RR. HH., Compliance y Dirección compartan la misma lógica? NIS2 no es solo un tema técnico. La directiva apunta a medidas de gestión de riesgos, capacidad de demostración y obligaciones de liderazgo. Por eso, presupuesto no significa solo licencias y hardware, sino sobre todo personal, procesos, auditorías y la capacidad de notificar en plazos claros y mantener la operativa en caso de incidente.

Este artículo muestra una lógica de cálculo sólida para inversiones en Tecnología, Personal y Auditorías, con la perspectiva de Gobernanza, consecuencias operativas y auditoría. Recibirá ayudas para la toma de decisiones, listas de verificación y bloques de plantilla que podrá trasladar a su planificación (CapEx/OpEx), su registro de riesgos y su hoja de ruta de medidas.

Por qué la planificación presupuestaria bajo NIS2 funciona de forma diferente a los „proyectos de seguridad“

En los programas clásicos de seguridad a menudo se presupuestan primero las „herramientas“: EDR aquí, SIEM allá, una formación de concienciación adicional. Bajo NIS2 ese orden se invierte. Lo decisivo es que su empresa identifique sistemáticamente los riesgos, implante controles efectivos y pueda demostrar que dichos controles están operativos. “Demostrar” significa: decisiones trazables, responsabilidades documentadas, registros, informes, pruebas, evidencias de ejercicios de incidente y evaluaciones de proveedores.

De ello se derivan tres realidades de coste que a menudo se subestiman en los presupuestos:

  • Costes de operación: operación, mantenimiento, ajuste, tratamiento de alertas, elaboración de informes, formaciones, recertificación de accesos.
  • Costes de evidencia: generar evidencias, versionarlas, revisarlas; responder a preguntas de auditoría; hacer los controles verificables.
  • Costes de coordinación: roles, comités, aprobaciones, aceptaciones de riesgo, escalados —especialmente en contextos de externalización y múltiples sedes.

La cuestión presupuestaria es, por tanto: ¿Qué combinación de medidas logra una reducción de riesgo efectiva y una preparación frente a auditorías sin sobrecargar la operación de TI con complejidad adicional?

Delimitar el alcance y la afectación: sin acotación cualquier cifra es arbitraria

Textfreie Grafik mit drei Scope-Zonen für System- und Lieferkettenabgrenzung unter NIS2
Delimitar el alcance con claridad: considerar por separado sistemas centrales, sistemas de apoyo y la cadena de suministro.

Antes de calcular necesita una definición de alcance sólida. No es un formalismo, sino la palanca que puede multiplicar o reducir su presupuesto por factores. Alcance aquí significa: ¿Qué áreas de negocio, ubicaciones, servicios críticos, sistemas y proveedores están afectados por los requisitos de NIS2 y deben incluirse en los análisis de riesgo, controles y evidencias?

En la práctica ha demostrado ser eficaz un enfoque de alcance en tres niveles:

  • Alcance central: Sistemas que prestan directamente el servicio afectado (p. ej., plataformas centrales, servicios de identidad, red núcleo, software empresarial central, TI orientada a OT/producción, cuando proceda).
  • Alcance de soporte: Sistemas cuya caída afecta de forma sustancial al servicio (p. ej., backup, infraestructura central de logging/monitoring, distribución de parches y software, VPN, ticketing).
  • Alcance ampliado: Cadena de suministro, modelos operativos externos, servicios en la nube, proveedores críticos, Managed Services.
  • Relevante para el presupuesto es que NIS2 no considera únicamente el ámbito „Core“. Especialmente los riesgos de la cadena de suministro (riesgos derivados de proveedores y dependencias de software/servicios en la nube) constituyen un bloque de costes propio: cláusulas contractuales, due diligence, requisitos de seguridad para proveedores, evidencias y, si procede, costes de cambio.

    Mini-lista de comprobación: datos de alcance que necesita para una estimación de costes fiable

    • Inventario de servicios y sistemas (al menos aproximado): aplicaciones, servidores/VMs, cuentas en la nube, segmentos de red, ubicaciones.
    • Criticidad por servicio: impacto en ingresos, seguridad, suministro/producción, obligaciones legales.
    • Dependencias: identidad (IAM), DNS, correo electrónico, almacenamiento, backup, monitoring, terceros.
    • Modelo operativo actual: interno/externo, disponibilidad, SLAs, puntos de transferencia.
    • Interfaces regulatorias: protección de datos, requisitos vinculados a KRITIS (si procede), estándares sectoriales.

    Decisiones presupuestarias bajo NIS2: el marco de costes en tres bloques

    Para la planificación con la dirección y el control financiero es decisiva una estructura sencilla. Ha demostrado su eficacia la siguiente división en tres partes, que puede utilizar como estructura de presupuesto e informes:

    • Técnica (Controles & plataformas): herramientas, integraciones, medidas de arquitectura.
    • Personal (Desarrollo & Operación): roles, esfuerzo de operación, cualificación, disponibilidad.
    • Verificaciones (Aseguramiento): auditorías, assessments, pruebas de penetración, ejercicios, revisiones de proveedores.

    Importante: cada gasto debe poder asignarse a un riesgo y a una evidencia. Si no, después tendrá discusiones sobre por qué una partida debe ser considerada „NIS2“, y en la auditoría faltará el hilo conductor.

    Calcular inversiones técnicas: menos lista de herramientas, más efecto de control

    Los presupuestos técnicos son sostenibles bajo NIS2 cuando se planifican como familias de controles. Las familias de controles son grupos de medidas que, en conjunto, cubren un área de riesgo (p. ej., identidades, registro/protocolización, gestión de vulnerabilidades). Con ellas puede priorizar, incluso si no se financia todo de inmediato.

    1) Identidad & Acceso: MFA, roles, acceso privilegiado

    La identidad es la palanca más habitual para limitar daños. Los impulsores del presupuesto aquí no son tanto los costes de licencias de MFA, sino los conceptos de roles, los procesos de ciclo de vida y, si procede, el PAM (Privileged Access Management: gestión asegurada de cuentas altamente privilegiadas con autorizaciones, control de sesiones y registro).

    • Coste único: definir modelo de roles, interfaz de permisos, conexión de sistemas, accesos de emergencia (Break-Glass).
    • Recurrente: recertificación, proceso Joiner/Mover/Leaver, revisión de privilegios de administrador, gestión de tokens y dispositivos.

    2) Gestión de activos y vulnerabilidades: inventario, priorización, realidad del parcheo

    Sin un inventario fiable no es posible justificar de forma clara ni el riesgo ni el presupuesto. Un registro de activos no tiene que ser perfecto desde el primer momento, pero debe ser verificable: qué sistemas están dentro del alcance, quién es responsable, cómo se gestionan las actualizaciones y las vulnerabilidades.

    Puntos presupuestarios que con frecuencia faltan en la práctica:

    • Infraestructura de escaneo (on-prem, Cloud, ubicaciones remotas) y mantenimiento de los escáneres.
    • Procesos de excepción (p. ej. sistemas legacy): evaluación de riesgos, controles compensatorios, documentación.
    • Ventanas de parcheo y esfuerzo operacional: pruebas, rollback, gestión de cambios (CAB), aceptación.

    3) Logging, Monitoring und Detektion: SIEM, XDR, Use Cases, Betrieb

    Diagramm-Skizze eines Log-Datenflusses zu zentraler Analyse in einem Security-Operations-Kontext
    La detección exige, sobre todo, operación: las fuentes de logs, el flujo de datos, la triage y la escalada deben encajar.

    Bajo NIS2 no se trata de «comprar un SIEM», sino de detectar, evaluar y responder. SIEM (Security Information and Event Management) recopila y correlaciona logs; XDR (Extended Detection and Response) integra la detección a través de endpoints, identidad, red y Cloud. Decisivo para el presupuesto es si lo opera internamente o lo adquiere como servicio gestionado.

    Factores típicos de coste:

    • Volumen de logs (almacenamiento, ingestión), conservación (retención) y requisitos de protección de datos.
    • Ingeniería de casos de uso: reglas de alarma, correlación, líneas base, afinado para reducir falsos positivos.
    • Disponibilidad 24/7 o tiempos de respuesta definidos, incluyendo cadenas de escalado.

    Una decisión presupuestaria sólida necesita un estado objetivo: qué eventos debe ver de forma fiable (p. ej. inicios de sesión de administrador, escalamiento de privilegios, flujos inusuales de datos, cambios en políticas críticas) y en qué plazo debe poder reaccionar.

    4) Backup, Recovery und Business Continuity: RTO/RPO als Budgetparameter

    Wiederherstellungsübung mit Checkliste und Backup-System zur Messung von RTO und RPO
    RTO y RPO sólo son fiables cuando las pruebas de RESTauración se realizan y documentan de forma periódica.

    Muchos incidentes se vuelven caros porque la recuperación lleva demasiado tiempo o no es fiable. Aquí ayuda una traducción clara a RTO (Recovery Time Objective: tiempo máximo de recuperación) y RPO (Recovery Point Objective: pérdida máxima de datos en tiempo). Estas dos métricas son el «regulador» de su presupuesto.

    • Esfuerzo puntual: arquitectura (copias de seguridad inmutables, dominios administrativos separados), pruebas de RESTauración, documentación.
    • En curso: validación regular de RESTauraciones, rotación de medios, monitorización, planificación de capacidad.

    Bajo NIS2 también importa que no solo lo „tenga“, sino que lo practique y pueda demostrar los resultados. Eso desplaza el presupuesto hacia auditorías y personal (véase abajo).

    5) Segmentación de red y endurecimiento: medidas planificables en lugar de „Big Bang“

    La segmentación (separación de áreas de red) y el endurecimiento del sistema (configuración base segura) suelen ser más eficaces que herramientas adicionales, pero generan trabajo de proyecto y de operación: reglas de firewall, procesos de excepción, resolución de problemas, documentación. Si presupuestan esto, planifiquen necesariamente el esfuerzo de cambio y la coordinación con las áreas funcionales, porque las modificaciones de red pueden volverse críticas para la producción con rapidez.

    Calcular personal: roles, lógica FTE y consecuencias operativas

    NIS2 pone de manifiesto lo que en muchas organizaciones de TI ya es escaso: tiempo para un funcionamiento ordenado y una gestión de riesgos fiable. El presupuesto de personal, por tanto, no es un lujo, sino una condición para que las medidas técnicas no queden como proyectos a medio terminar.

    Modelo de roles: ¿a quién hay que financiar, incluso si antes no había un „Security-Headcount“?

    Según el tamaño y el nivel de madurez, no siempre se requieren nuevas posiciones a tiempo completo, pero sí es necesario definir claramente la asignación de funciones. Roles típicos bajo NIS2:

    • CISO/Responsable de seguridad de la información: dirección, cartera de riesgos y medidas, informes al management.
    • ISMS-Manager (ISMS = Sistema de gestión de la seguridad de la información: procesos y reglas para gobernar la seguridad de forma sistemática): políticas, evidencias, controles internos.
    • Operaciones de seguridad: monitorización, triage, gestión de incidentes, inteligencia sobre amenazas (según necesidad).
    • Operaciones de TI/Equipos de plataforma: parches, endurecimiento, backup/recuperación, gestión de identidades, red – como co-responsables de los controles.
    • Cumplimiento/Legal: procesos de notificación, obligaciones de documentación, cadena de suministro, cláusulas contractuales.

    Lógica de presupuesto: si introduce nuevas herramientas, debe prever horas de operación (triage, mantenimiento, reporting). Sin estas horas disminuye la eficacia y en la auditoría faltará la evidencia operativa.

    Estimación de FTE pragmática: paquetes de esfuerzo en lugar de cifras especulativas

    En lugar de indicar una cifra única de FTE, muchas organizaciones funcionan mejor con paquetes de esfuerzo que presupuestan por trimestre y escalan según el grado de madurez:

    • Gobernanza y Reporting: mantener el registro de riesgos, reporting al management, ciclos de revisión de políticas.
    • Vulnerabilidades y Parches: escaneos, evaluación, planificación de cambios, implementación, gestión de excepciones.
    • Detección y Respuesta: gestión de alertas, mantenimiento de casos de uso, playbooks, lecciones aprendidas.
    • Concienciación y Ejercicios: planificación de formaciones, simulación de phishing (si se utiliza), ejercicios tabletop.
    • Cadena de suministro: evaluaciones de seguridad, requisitos de evidencia a proveedores, revisión de informes.

    Estos paquetes pueden contabilizarse como OpEx y reducirse parcialmente mediante servicios gestionados, con la aclaración de que la gobernanza y la responsabilidad permanecen internas.

    Formación y cualificación: presupuesten tiempo, no solo los costes de formación

    La concienciación bajo NIS2 no es una „casilla de e‑learning“. Lo decisivo es diferenciar los grupos objetivo: administrador de TI, Service Desk, equipos de desarrollo (si los hay), dirección, unidades de negocio con procesos críticos. El mayor bloque de costes suele ser tiempo de trabajo y coordinación (citas, seguimiento, medición de eficacia). Para la preparación ante auditorías necesita evidencias: tasas de participación, contenidos, ciclos de repetición, medidas en caso de no participación.

    Pruebas y evidencias: lo que realmente cuesta el „aseguramiento“

    Las pruebas bajo NIS2 no son solo una auditoría externa, sino un continuo de verificaciones internas, pruebas técnicas y revisiones de la dirección. El objetivo es que, en caso de inspecciones o incidentes, pueda mostrar de forma trazable qué se decidió y qué se implementó.

    Penetrationtests, Red Teaming, evaluaciones técnicas: definir el alcance con claridad

    Un error presupuestario frecuente es comprar „un pentest“ sin definir alcance y objetivo. Para ofertas sólidas y la planificación interna debería al menos fijar:

    • Objetos de prueba: superficie de ataque externa, aplicaciones centrales, identidad, configuración en la nube, segmentos de red.
    • Tipo de prueba: Blackbox/Graybox, autenticado/no autenticado, ingeniería social sí/no.
    • Trabajos posteriores: re-test, priorización, seguimiento de remediación, aceptación del riesgo ante hallazgos.

    Además, presupueste el acompañamiento interno: provisión de accesos, ventanas de mantenimiento, coordinación con operaciones y unidades de negocio, así como la implementación de los hallazgos (que frecuentemente representa la parte mayor).

    Preparación para auditorías: la recopilación de evidencias como proceso continuo

    Prepararse para auditorías no significa buscar documentos justo antes de una revisión. Necesita unas operaciones que produzcan evidencias „de paso“: registros, informes, aprobaciones, tickets, estados de configuración, actas de ejercicios. Eso exige estructura.

    Mínimo práctico de categorías de evidencia:

    • Gobernanza: roles, responsabilidades, órganos de decisión, actas de revisión de gestión.
    • Riesgo: metodología, evaluación, aceptaciones, plan de medidas, estado.
    • Controles técnicos: baselines, informes de parches, pruebas de backup, cobertura de logging, revisiones de IAM.
    • Respuesta a incidentes: playbooks, ejercicios, lecciones aprendidas, vías de comunicación y notificación.
    • Cadena de suministro: clasificación de proveedores, requisitos de seguridad, evidencias/informes, excepciones.

    Ejercicios tabletop y gestión de crisis: presupuesto para franjas horarias y entrenamiento en toma de decisiones

    NIS2 está estrechamente ligado a obligaciones de notificación y responsabilidad de la dirección. Los ejercicios tabletop (escenarios ensayados alrededor de una mesa) son por tanto una vía eficiente para probar rutas de notificación, derechos de decisión y rutinas de comunicación. Los costes aquí son sobre todo: tiempo de preparación, moderación, participación de mandos, trabajo posterior y ajuste de los runbooks.

    Priorización: un portafolio basado en riesgo en lugar de „todo a la vez“

    Pocas empresas pueden implementar todas las medidas de inmediato. Lo decisivo es que su priorización sea plausible ante una auditoría. Basado en riesgo significa: vincular probabilidad de ocurrencia, impacto y capacidad de detección/respuesta en una secuencia justificable.

    Un marco práctico de priorización

    • Mitigación del daño primero: identidad (MFA/PAM), backup/recuperación, separación de administradores, respuesta a incidentes.
    • Restablecer la visibilidad: cobertura de logging, alarmas centralizadas, monitorización de referencia, inventario de activos.
    • Reducir la superficie de ataque: proceso de parches y gestión de vulnerabilidades, hardening, segmentación, configuraciones estándar seguras.
    • Fortalecer la capacidad de demostración: proceso de evidencias, revisiones periódicas, auditorías/controles internos, expediente de proveedores.

    Este orden es deliberadamente no centrado en herramientas. Está centrado en la operación: ¿qué le ayuda a evitar incidentes, detectarlos más rápido y restaurar el servicio —y hacerlo de forma demostrable?

    Construir o comprar: servicios gestionados, equipos internos y los costes ocultos de la transferencia

    Bajo NIS2, „externalizar“ no es un salvoconducto. Puede delegar detección, operación de logs o gestión de vulnerabilidades a un proveedor, pero mantiene la responsabilidad y debe poder gobernarlo. Las decisiones presupuestarias deberían distinguir por tanto tres niveles:

    • Servicio: ¿Qué hace concretamente el proveedor (monitorización, triaje, soporte de respuesta)?
    • Interfaces: ¿Cómo se transfieren tickets, alertas y cambios (ITSM, API, E-Mail)?
    • Evidencias: ¿Qué informes, registros y KPIs proporcionan evidencia válida para auditoría?

    Los costes ocultos suelen surgir en las transferencias: cadenas de escalado poco claras, responsabilidades inexistentes, ausencia de definiciones comunes de severidad y fracturas en el flujo entre SOC-Tooling e ITSM. Estos costes son reales, aunque no aparezcan en una factura: retrasos, falsas alarmas, decisiones poco claras en el incidente.

    Plantilla de cálculo: Cómo construir un presupuesto NIS2 que soporte control de gestión y auditoría

    Una plantilla robusta consta de tres tablas que se relacionan lógicamente: Riesgo → Medida → Partida presupuestaria. A continuación un marco compacto que puede trasladar a Excel/Sheets o a su herramienta de portfolio.

    1) Lista de riesgos y medidas (nivel portfolio)

    Code
    Campos (recomendado)
    - ID de riesgo
    - Servicio/Sistema (ámbito)
    - Descripción del riesgo
    - Impacto (financiero/operativo/legal)
    - Probabilidad de ocurrencia (cualitativa o escala)
    - Controles existentes
    - Controles planificados (ID de medida)
    - Fecha objetivo / hito
    - ¿Se requiere aceptación del riesgo? (sí/no, por quién)
    - Fuente de evidencia (¿qué prueba demuestra eficacia?)

    2) Partidas presupuestarias (CapEx/OpEx, Técnica/Personal/Auditoría)

    Code
    Campos (recomendado)
    - ID de medida
    - Bloque de costes (Técnica / Personal / Auditorías)
    - Tipo de coste (CapEx / OpEx)
    - Puntual (Implementación/Proyecto) / Recurrente (Operación)
    - Factores de coste (p. ej., volumen de logs, endpoints, ubicaciones, criticidad)
    - Dependencias (p. ej., IAM antes de PAM, inventario de activos antes del programa de vulnerabilidades)
    - Consecuencias operativas (cambios adicionales, ventanas de mantenimiento, disponibilidad)
    - Evidencia/Beneficio (¿qué prueba de auditoría o qué reducción de riesgo?)
    - Responsable (Owner) + Colaboradores

    3) Plan de evidencia (columna vertebral de preparación para auditorías)

    Code
    Campos (recomendado)
    - Control/Proceso (p. ej., gestión de parches)
    - Artefacto de evidencia (informe, extracto de ticket, registro, documento de ejercicio)
    - Frecuencia (mensual/trimestral/anual/basada en eventos)
    - Generador (rol/equipo)
    - Ubicación de almacenamiento (DMS, herramienta GRC, ticketing, repo)
    - Revisión (quién revisa, quién firma)
    - Retención y control de acceso

    Con esta tríada, las decisiones presupuestarias bajo NIS2 dejan de ser „intuición“ y pasan a ser un portfolio gestionable con lógica de evidencias.

    Gobernanza y responsabilidades: el presupuesto necesita rutas de decisión

    NIS2 hace que la dirección sea más cercana a la responsabilidad legal: las decisiones deben tomarse y documentarse de forma deliberada. Para el presupuesto eso significa: necesita un órgano o un proceso fijo que decida sobre las aceptaciones de riesgo, las prioridades y las excepciones. En la práctica, esto suele ser un comité de dirección de seguridad o un comité ampliado de riesgos de TI.

    Conjunto mínimo de gobernanza que estabiliza la planificación presupuestaria:

    • RACI (Responsible, Accountable, Consulted, Informed): ¿Quién implementa, quién decide, quién se involucra?
    • Límites de decisión: ¿A partir de qué nivel de riesgo debe decidir la dirección?
    • Proceso de excepciones: ¿Cómo se aprueban temporalmente las desviaciones (p. ej., sistemas heredados sin parches)?
    • Cadencia de informes: informe operativo mensual, revisión de gestión trimestral.

    Sin estas vías, el presupuesto se „fragmenta“ a lo largo del año: los proyectos arrancan, pero el esfuerzo operativo y las auditorías quedan sin financiar o se descargan sobre equipos que ya están al límite.

    Trampas presupuestarias típicas — y cómo evitarlas en la planificación

    Trampa 1: herramientas sin concepto operativo

    Cuando aumentan las fuentes de alarma, crece el esfuerzo de triage. Planifique como mínimo: responsabilidad, tiempo de respuesta, flujo de tickets, conjunto de KPI (p. ej. Time to Acknowledge, Time to Contain) y ajustes periódicos.

    Trampa 2: medidas de parcheo y hardening sin capacidad de cambios

    La deuda técnica no se puede „comprar“ para eliminarla. Si sus ventanas de cambio son escasas, necesita presupuesto para automatización de pruebas (cuando sea posible), para ventanas de mantenimiento adicionales o para la eliminación gradual de sistemas heredados. Si no, los hallazgos quedan pendientes y las preguntas de auditoría se vuelven incómodas.

    Trampa 3: la cadena de suministro como partida residual

    NIS2 exige que gestione activamente los riesgos de proveedores. Presupueste la capacidad para clasificar proveedores, solicitar evidencias, ajustar contratos y, ante dependencias críticas, evaluar alternativas. Esto implica trabajo en compras, TI y compliance — no es solo un anexo contractual.

    Trampa 4: „Una auditoría y listo“

    Las evidencias caducan. Los responsables cambian. Los sistemas evolucionan. Por eso planifique comprobaciones continuas y ejercicios periódicos; si no, la preparación para auditorías será cada año un proyecto extraordinario con alta fricción.

    Guía para la decisión: ¿Qué preguntas deben incluirse en cada propuesta presupuestaria de NIS2?

    • ¿Qué riesgos reducimos concretamente y cómo lo medimos (KPI/evidencias)?
    • ¿Qué consecuencias operativas se derivan (carga de cambios, disponibilidad, formaciones, volumen de tickets)?
    • ¿Qué dependencias tiene la medida y cuál es el calendario realista?
    • ¿Qué se decide internamente, qué puede pRESTarse externamente y cómo gestionamos al proveedor?
    • ¿Qué evidencias necesitaremos en 6 y 12 meses y quién las generará?

    Conclusión: Un buen presupuesto para NIS2 es un sistema en operación — no una lista de compras

    El cambio central para la dirección de TI y la gerencia es: las decisiones presupuestarias bajo NIS2 deben financiar la tecnología, el personal y las auditorías como un sistema interconectado. Tecnología sin operación genera nuevos riesgos. Personal sin una gobernanza clara se diluye en la operación diaria. Las auditorías sin un proceso de evidencias se convierten en esfuerzos extraordinarios frenéticos. Si delimita el alcance con claridad, prioriza las medidas en función del riesgo y vincula cada gasto al riesgo y a la evidencia, obtendrá un presupuesto que conecta internamente y que, externamente, resulta plausible en auditorías.

    Si planifica los siguientes pasos, el punto de partida más pragmático suele ser: acotar el alcance, establecer una cartera de riesgos, priorizar tres a cinco familias de control (identidad, recuperación, visibilidad, aplicación de parches/endurecimiento, respuesta a incidentes) y, en paralelo, establecer el plan de evidencias. Entonces las inversiones pasan a ser planificables – y NIS2 deja de ser un proyecto ad hoc para convertirse en una disciplina operativa controlable.

    Para este tema también son importantes el presupuesto Nis2 y los costes de cumplimiento Nis2. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.