NIS2: ¿implantación interna o con una consultora? Comparativa de costes, plazos y riesgos

Decidir si abordar NIS2 con recursos internos o con una consultora no consiste únicamente en comparar los honorarios externos con el coste del equipo propio. El resultado depende del alcance de las obligaciones, la disponibilidad de quienes deben tomar decisiones, la calidad de la información sobre procesos y activos, y la capacidad de mantener posteriormente las medidas implantadas. La opción aparentemente más económica puede terminar siendo la más costosa si parte de una clasificación incorrecta, obliga a repetir análisis o genera documentación que no refleja el funcionamiento real de la empresa. Por ello, primero deben determinarse el alcance y las brechas; después, comparar el coste total, el plazo y el riesgo de los tres modelos de ejecución; y solo entonces seleccionar al proveedor y la forma de organizar el proyecto.

No elija proveedor antes de determinar sus obligaciones

Comparar una implantación con medios propios frente al apoyo de una empresa externa solo tiene sentido después de confirmar si la organización está sujeta a las obligaciones derivadas de NIS2 y de la normativa polaca que transpone estos requisitos. Si lo está, debe delimitarse qué servicios, unidades, ubicaciones y activos quedan incluidos en el análisis. Sin esta clasificación no es posible estimar de forma fiable el alcance del trabajo, el plazo ni el coste. La dirección también debe designar a un responsable del proyecto con autoridad para coordinar decisiones entre las áreas operativas, jurídica y de TI.

El punto de partida no es comprar un paquete documental ni una herramienta informática, sino describir el modelo operativo. Es necesario identificar los servicios prestados, los procesos, sistemas y datos que los soportan, así como los proveedores y las dependencias esenciales para la continuidad. Solo este mapa permite decidir si el análisis debe abarcar toda la sociedad o únicamente determinados servicios y centros. El primer resultado debería incluir una clasificación documentada de la entidad, unos límites de alcance definidos y una relación de áreas que requieren evaluación y acciones correctivas.

La sujeción formal a la normativa debe diferenciarse de la necesidad empresarial de mejorar la resiliencia. Una organización puede quedar fuera del ámbito de las obligaciones legales y, aun así, estar sometida a requisitos de clientes, del grupo empresarial, de una aseguradora o de otros participantes de la cadena de suministro. En ese caso, el proyecto no debe presentarse como cumplimiento de una obligación legal, sino como respuesta a requisitos contractuales concretos y a riesgos operativos.

Un ejemplo sería una empresa industrial que dispone de cortafuegos, copias de seguridad y protección de puestos de trabajo, pero no puede identificar al propietario del proceso de respuesta a incidentes. Tampoco ha determinado cómo afectaría una interrupción del sistema de planificación de la producción al programa de pedidos, la disponibilidad de materiales y los plazos de entrega. El problema no reside únicamente en el nivel de las medidas técnicas, sino también en la falta de responsabilidades asignadas y de un análisis de las dependencias entre el sistema informático y la prestación del servicio.

Una vez descrita la actividad, debe realizarse una evaluación jurídica conforme a los criterios sectoriales, relativos a la entidad y de tamaño vigentes en la fecha de publicación. La posición formal debería aprobarla el órgano o la persona con capacidad para representar a la organización, con participación del área jurídica y de los propietarios de los servicios y procesos. TI debe aportar información sobre los sistemas, pero no debería decidir por sí sola la clasificación. Esta cuestión se desarrolla en el artículo «Directiva NIS2: ¿a quién afecta y qué empresas deben cumplir los nuevos requisitos?».

El coste de implantación no termina en la factura

La opción interna no es gratuita, del mismo modo que los honorarios de la consultora no representan el coste total del apoyo externo. El cálculo debe incluir el trabajo de la dirección, los propietarios de procesos, TI, compras, recursos humanos, el área jurídica y el responsable del sistema de gestión. El tiempo de estas personas debe valorarse conforme a los costes internos y las horas de trabajo reales, teniendo en cuenta las tareas operativas que dejarán de realizar durante el proyecto. El esfuerzo dependerá principalmente del número de ubicaciones, procesos, sistemas, proveedores y sociedades incluidos en el alcance.

Los costes que más suelen infravalorarse son la recopilación de datos, la asignación de responsabilidades, el inventario de activos y proveedores, la preparación de evidencias, la ejecución de pruebas y actividades formativas, y la corrección de normas internas incoherentes. Una consultora solo reducirá este esfuerzo si sabe trasladar los requisitos a los procesos, funciones y herramientas existentes. Entregar modelos de políticas sin comprender la actividad no elimina el coste: lo desplaza a las fases de validación, implantación y actualización posterior.

La documentación sobre incidentes puede redactarse rápidamente, pero será meramente formal si no se han acordado las guardias, la ruta de escalado, la conservación de evidencias y las sustituciones. El coste real aparecerá durante una prueba o un incidente, cuando sea necesario rediseñar el procedimiento. Por tanto, el presupuesto debe separar los costes puntuales de los recurrentes e incluir los honorarios de consultoría, las inversiones técnicas, las interrupciones ocasionadas por el proyecto, las correcciones y el mantenimiento anual: revisiones, pruebas, formación, actualización documental, evaluación de proveedores y gestión de incidentes.

Un sistema de gestión de la seguridad de la información operativo o una certificación pueden reducir el alcance del inventario, la evaluación de riesgos, el control documental y las auditorías, siempre que las soluciones funcionen realmente en el ámbito analizado. No sustituyen, sin embargo, la evaluación de las obligaciones específicas establecidas por la normativa aplicable ni la comprobación de que los controles existentes responden a los servicios incluidos. Esta relación se explica en el artículo NIS2 e UNE-EN ISO 27001: qué aporta el certificado y qué sigue faltando para cumplir la KSC.

El plazo depende de la capacidad para tomar decisiones

El tiempo necesario para prepararse frente a NIS2 rara vez depende de la rapidez con la que se redacten procedimientos. Los principales factores limitantes son la disponibilidad de información fiable, de los propietarios de procesos y de las personas autorizadas para aprobar cambios. El calendario debe reflejar su disponibilidad real, la frecuencia de las reuniones del comité de dirección del proyecto y el tiempo necesario para resolver cuestiones entre departamentos. Una fecha prevista de entrega de documentación no constituye una medida de progreso si la organización todavía no ha aprobado el alcance, las responsabilidades y las prioridades.

El trabajo debe planificarse respetando las dependencias. Primero hay que definir el alcance, las funciones, los procesos y los activos; después, realizar el análisis de riesgos, aprobar el plan de tratamiento, implantar los controles, efectuar las pruebas y recopilar evidencias de funcionamiento. Pueden ejecutarse en paralelo las tareas que parten de las mismas premisas aprobadas, como el inventario de contratos y la revisión de los controles existentes. En cambio, no debería iniciarse un análisis detallado de riesgos antes de identificar los servicios, procesos, sistemas, información y dependencias de proveedores incluidos en la evaluación.

Para priorizar las actuaciones conviene distinguir entre brechas que requieren compras, modificaciones contractuales, integraciones técnicas o pruebas. Cada grupo sigue una vía de aprobación y tiene un plazo de ejecución diferente. El apoyo externo puede acelerar el diagnóstico, facilitar los talleres y estructurar sus resultados, pero el consultor no puede decidir por la dirección la aceptación del riesgo, el orden de las inversiones ni el tiempo de interrupción tolerable para los servicios. Si estas decisiones se posponen hasta el final, la documentación se adelanta a las soluciones operativas y parte del análisis debe repetirse.

Por tanto, el avance debe medirse por el número de decisiones aprobadas, dependencias resueltas y controles cuyo funcionamiento se ha verificado, no por la cantidad de documentos redactados. Incluso un calendario de pocas semanas será inviable si la organización carece de una lista actualizada de sistemas, un registro de contratos con proveedores o propietarios de procesos acordados. En ese caso, el equipo podrá describir una situación declarada, pero no determinar las responsabilidades sobre la continuidad, la recuperación del servicio y la supervisión del proveedor.

El mapeo de procesos debe facilitar precisamente estas decisiones, no aumentar innecesariamente la documentación. La comparación «BPMN o diagrama de flujo: ¿qué herramienta funciona mejor para mapear procesos de calidad?» ayuda a elegir el nivel de detalle adecuado. En este contexto, la herramienta correcta es la que muestra con claridad las funciones, los puntos de transferencia de responsabilidad, las dependencias de información y las áreas que requieren protección o sustitución.

El riesgo procede, sobre todo, de premisas incorrectas

El éxito de la preparación para NIS2 depende más de la validez de las premisas que del número de tareas completadas. En el modelo interno, los principales riesgos son interpretar incorrectamente el alcance, omitir dependencias de negocio y reducir la ciberseguridad a una responsabilidad exclusiva de TI. La organización puede dejar fuera procesos productivos, logística, mantenimiento, continuidad del suministro o compromisos con clientes. También falta una visión independiente sobre prácticas que se consideran suficientes únicamente porque hasta ahora no han provocado una interrupción visible.

El apoyo externo tampoco elimina automáticamente estos riesgos. Los incrementa un proveedor que entrega un paquete documental uniforme sin analizar los servicios, procesos y dependencias de la organización, no implica a los propietarios de procesos o no transfiere el conocimiento necesario para mantener las soluciones implantadas. El resultado es un sistema dependiente del autor de la documentación, no de las personas responsables de la operación diaria.

Por ello, conviene separar la ejecución del trabajo de la evaluación final independiente, especialmente cuando la misma entidad ha diseñado el alcance, evaluado los riesgos y seleccionado los controles. La decisión de aceptar el riesgo residual debe seguir correspondiendo al nivel directivo competente.

El cumplimiento meramente formal se manifiesta en la distancia entre lo documentado y la práctica: la política describe una forma de actuar distinta del proceso real, el registro de riesgos no influye en las prioridades ni en las inversiones, y el procedimiento de gestión de incidentes nunca se ha probado. Una brecha documental es la ausencia o incoherencia de un registro necesario. Una brecha operativa existe cuando la organización no sabe ejecutar una actuación, asignar su responsabilidad o presentar evidencias de su eficacia. Completar un formulario puede resolver la primera, pero no sustituye una prueba, una decisión o un cambio en la forma de trabajar.

Un ejemplo sería una planta con un procedimiento aprobado para notificar incidentes, pero cuyos trabajadores de producción no saben cómo comunicar la indisponibilidad de un sistema de control o planificación. Al mismo tiempo, no se han acordado con el proveedor la ruta de escalado, las personas de contacto ni las reglas de actuación fuera del horario laboral. El documento existe, pero durante la interrupción se pierden los primeros minutos determinando quién debe actuar. Esta brecha solo se detectará mediante un ejercicio que incluya al usuario, al propietario del proceso, a TI, a la dirección y al proveedor.

Una auditoría de preparación debe evaluar la capacidad de actuar y de presentar evidencias fiables, no solo la integridad documental. Entre los indicadores útiles figuran las acciones pendientes de auditorías y pruebas anteriores, los resultados de los ensayos de recuperación, las conclusiones de las revisiones de incidentes e interrupciones y el porcentaje de proveedores críticos evaluados y sujetos a requisitos acordados, siempre sobre la base de los datos de la organización. El enfoque para realizar esta verificación se desarrolla en el artículo «Auditoría NIS2 en una empresa industrial: cómo comprobar si la organización está preparada para las nuevas obligaciones».

El modelo mixto suele ofrecer un mayor control

La elección del modelo de implantación debe basarse en la capacidad real de la organización para ejecutar el trabajo, no únicamente en la comparación de tarifas de consultoría. La implantación interna es razonable cuando el proyecto cuenta con un responsable competente, los procesos de gestión de riesgos son maduros, los inventarios de activos y dependencias están actualizados, y el personal clave dispone de tiempo y sabe interpretar los requisitos. Un apoyo externo más amplio se justifica cuando existe una brecha importante de competencias, una estructura dispersa, dependencias tecnológicas relevantes, un plazo de preparación reducido o la ausencia de un sistema de gestión estructurado.

En la práctica, el modelo mixto suele ofrecer el mejor control de costes, plazos y riesgos. La organización conserva la responsabilidad sobre las decisiones, los datos de origen, la propiedad de los riesgos y la ejecución de las actuaciones operativas. El consultor se encarga del diagnóstico, la metodología, la dirección de los talleres, los análisis que requieren conocimiento especializado y el control de calidad de los resultados.

Como mínimo, deben permanecer dentro de la organización:

• la determinación de la relevancia de los procesos y servicios;
• la designación de los propietarios de los riesgos;
• la aceptación del riesgo residual;
• la definición de las prioridades de inversión;
• la confirmación de que los controles funcionan en la práctica.

La dirección no puede transferir al proveedor su responsabilidad sobre la resiliencia de la organización.

Una empresa con varias plantas puede recopilar internamente la información sobre servicios, activos, proveedores y consecuencias de las interrupciones, ya que una evaluación fiable exige conocimiento operativo. A continuación, un especialista externo puede estructurar el método de evaluación, cuestionar incoherencias, dirigir talleres interdepartamentales y comprobar que las evidencias estén completas. La rentabilidad de este reparto depende del número y las competencias de las personas que realmente pueden asignarse al proyecto, no de la composición formal del equipo.

Las ofertas deben compararse utilizando el mismo alcance de entregables y los mismos criterios de aceptación. Las referencias del proveedor deben evaluarse por la similitud del sector, la escala, los procesos y el entorno tecnológico, no solo por el número de proyectos realizados. El contrato debe definir claramente los entregables, los criterios de aceptación, la obligación de adaptar las soluciones a los procesos reales, la transferencia de conocimiento, las reglas de confidencialidad y acceso a datos sensibles, la responsabilidad sobre las correcciones y el alcance del soporte posterior. El modelo de remuneración no debería premiar la cantidad de documentos, sino la consecución de resultados acordados y verificables.

Los límites prácticos de responsabilidad de la dirección, los propietarios de procesos y las funciones de apoyo se desarrollan en el artículo NIS2 en la práctica directiva: cómo convertir los requisitos en decisiones, responsabilidades y resiliencia real.

Base la decisión en evidencias y en la capacidad de mantener el sistema

Antes de elegir el modelo de implantación debe realizarse un breve diagnóstico organizativo. Es necesario confirmar el alcance del proyecto, nombrar a su responsable, evaluar la disponibilidad de competencias, inventariar las evidencias de funcionamiento existentes y estimar las principales brechas. Solo entonces podrá decidirse qué trabajos realizará internamente la organización y en qué áreas la participación de un especialista reducirá el riesgo de interpretaciones erróneas, omisiones o repetición de tareas.

La decisión de la dirección debería comparar tres alternativas: ejecución con recursos propios, modelo mixto y apoyo externo más amplio. A todas deben aplicarse los mismos criterios:

• coste total, incluido el trabajo del personal, las correcciones y el mantenimiento;
• tiempo necesario para alcanzar la capacidad operativa;
• riesgo de error y de tener que repetir trabajos;
• disponibilidad real de competencias;
• capacidad de la organización para mantener las soluciones de forma autónoma.

El acuerdo o la decisión de la dirección debería indicar la alternativa seleccionada, el reparto de responsabilidades, el responsable del proyecto, los recursos, el método de reporte, los criterios de aceptación y los indicadores de eficacia derivados de los procesos de la organización, no de umbrales universales carentes de contexto.

La implantación no debe aceptarse en función del número de políticas elaboradas. El resultado debe ser un funcionamiento repetible: funciones asignadas, decisiones de riesgo documentadas, controles implantados, respuestas probadas ante interrupciones e incidentes, supervisión de proveedores y registros fiables. Un procedimiento de respuesta aprobado no acredita la preparación si una prueba revela contactos desactualizados, una ruta de escalado poco clara o la ausencia de una persona autorizada para tomar decisiones.

Los criterios de aceptación deben incluir la coherencia entre los documentos y la práctica, el cierre de las brechas acordadas, los resultados de las pruebas, la transferencia de conocimiento y un plan inequívoco de mejora posterior, incluido el programa de auditorías internas. Entre las evidencias de aceptación pueden figurar aprobaciones, registros, resultados de pruebas, actas de formación, decisiones sobre riesgos y confirmaciones de las acciones ejecutadas. La preparación y el mantenimiento de estas evidencias se desarrollan en el artículo Documentación NIS2 y KSC ante una inspección: qué políticas, registros y evidencias son realmente necesarios.

La sostenibilidad de la solución solo puede evaluarse cuando se reduce la participación del consultor. En ese momento, los propietarios de procesos deberían poder actualizar los registros, tomar decisiones sobre riesgos, analizar los resultados de las pruebas e iniciar acciones correctivas de forma autónoma. Si el sistema funciona únicamente gracias al conocimiento del proveedor, el proyecto no está terminado: la organización ha recibido documentación, pero no ha desarrollado la capacidad para mantenerla.