Control de cumplimiento de NIS2 y KSC: documentos, registros y pruebas que deben formar una cadena de evidencias coherente

Un control de cumplimiento de NIS2 y KSC no se limita a presentar políticas y procedimientos. La autoridad supervisora puede comprobar si la organización ha definido correctamente el alcance de sus obligaciones, asignado responsabilidades, implantado controles y demostrado su funcionamiento mediante registros actualizados, resultados de pruebas y decisiones de la dirección. La preparación debe seguir, por tanto, una cadena de evidencias: desde la obligación y el riesgo hasta el control aplicado, el registro de su ejecución, la evaluación de su eficacia y la respuesta ante cualquier desviación.

El control evalúa el sistema, no una carpeta de documentos

El punto de partida no es la cantidad de políticas y procedimientos disponibles, sino la correcta delimitación de las obligaciones. La organización debe poder indicar qué servicios, procesos, sistemas de información, ubicaciones y dependencias de proveedores están sujetos a los requisitos de KSC y en qué se basa esa determinación. Antes de ordenar la documentación, la dirección debe confirmar la condición de la entidad y el alcance de los servicios prestados, y designar después a una persona responsable de coordinar la preparación para el control.

El mayor riesgo probatorio aparece cuando la documentación describe soluciones que la organización no aplica realmente o cuyo funcionamiento no puede demostrar mediante registros. Esto afecta especialmente a las revisiones de permisos, evaluaciones de riesgos, copias de seguridad, supervisión de proveedores y pruebas de continuidad. El expediente debe formar una secuencia coherente: requisito o riesgo, decisión, control implantado, responsabilidad asignada, evidencia de ejecución, resultado de la evaluación de eficacia y respuesta ante la desviación detectada.

La autoridad puede comenzar por un documento de alto nivel y pasar después a una muestra operativa. Si el procedimiento de gestión de incidentes define cómo deben clasificarse y escalarse los eventos, cabe esperar que se revisen las notificaciones, los tiempos de respuesta, las decisiones adoptadas, las comunicaciones, el cierre de los casos y las lecciones aprendidas. El alcance del sistema no se demuestra únicamente mediante una descripción: también requiere un mapa de servicios y dependencias, un inventario de activos, la asignación de propietarios y la coherencia de estos datos con los registros operativos.

La documentación de NIS2 y KSC antes de un control: qué políticas, registros y evidencias se necesitan realmente debe reflejar un mecanismo de gestión operativo, no un catálogo de plantillas. También es necesario distinguir el control de la autoridad supervisora de una auditoría del sistema de gestión. Ambas actividades pueden utilizar evidencias similares, pero el control examina el cumplimiento de las obligaciones derivadas de la normativa aplicable y del alcance de supervisión, mientras que la auditoría evalúa la conformidad y eficacia del sistema frente a criterios establecidos. Un resultado positivo en una de estas actividades no sustituye a la otra.

Alcance y responsabilidades bajo examen

El primer grupo de evidencias debe explicar por qué la organización está sujeta a determinadas obligaciones y dónde se encuentran los límites del entorno supervisado. La autoridad puede solicitar la justificación de la clasificación de la entidad, la identificación de los servicios incluidos en la regulación y la relación de los procesos, activos de información, sistemas, ubicaciones y proveedores vinculados. El alcance no debe describirse únicamente mediante el nombre de la actividad. Debe permitir seguir la prestación del servicio desde el proceso de negocio hasta los activos que lo soportan y sus dependencias externas.

La preparación debe apoyarse en una descripción actualizada del alcance, aprobada por la dirección y complementada con un mapa de servicios y procesos, un inventario de activos críticos y una estructura de responsabilidades. Los documentos que formalizan las funciones no deben limitarse a indicar puestos: también deben establecer la autoridad para aceptar riesgos, activar medidas de contingencia, escalar incidentes y adoptar decisiones relativas a proveedores. Los propietarios de servicios, activos y riesgos deben asignarse de acuerdo con la distribución real de competencias.

Una incoherencia habitual se produce cuando el registro identifica a un propietario formal del riesgo, pero la aceptación la decide otra persona sin la autoridad correspondiente ni un registro que lo justifique. El mismo problema puede afectar a las excepciones de seguridad, la continuidad de negocio y la aprobación de proveedores. Las actas de reuniones, resoluciones, aprobaciones de evaluaciones de riesgos, decisiones presupuestarias y revisiones por la dirección deben demostrar que esta conoce los riesgos relevantes, resuelve las cuestiones que exceden las competencias operativas y supervisa la ejecución de sus decisiones.

La clasificación, la inscripción en el registro correspondiente y las competencias de la autoridad deben determinarse en cada caso conforme al marco jurídico vigente y a la situación concreta de la entidad. Este aspecto se desarrolla de forma práctica en NIS2: autoevaluación e inscripción en el Registro KSC: ¿qué debe hacer una empresa industrial? Si la organización tiene la condición de entidad esencial, la evaluación del alcance también debe relacionarse con el contenido Auditoría obligatoria de KSC: qué entidades esenciales deben prepararse para la primera evaluación de conformidad. No obstante, la condición de la entidad no demuestra por sí sola que la dirección haya aprobado los límites de responsabilidad ni establecido su revisión periódica.

Los registros demuestran cómo funciona el sistema

Un registro solo constituye una evidencia de gestión continua cuando refleja decisiones y actividades realizadas dentro de los procesos, y no cuando se completa periódicamente como un mero anexo del procedimiento. Antes de elegir una herramienta deben definirse los campos necesarios, las fuentes de datos, los responsables de los registros y las reglas de aprobación de cambios. Una hoja de cálculo puede ser suficiente si garantiza control de acceso, historial de cambios, responsabilidades inequívocas y protección frente a modificaciones no autorizadas. Una herramienta avanzada no aportará fiabilidad si no se sabe quién actualiza el registro, cuándo lo hace y qué evento origina la actualización.

El registro de riesgos debe relacionar los escenarios de amenaza con los servicios y activos, e indicar el propietario, los controles existentes, el resultado de la evaluación, la decisión de tratamiento y el estado de las acciones. La autoridad puede comprobar si un riesgo identificado para su mitigación dispone de una tarea, un plazo y una evidencia de ejecución, y si un riesgo aceptado cuenta con la aprobación de una persona debidamente autorizada. Entre los indicadores útiles para la dirección se encuentran el número de riesgos abiertos, las acciones pendientes y las decisiones que requieren una nueva revisión. Se trata de indicadores adoptados por la organización, no de umbrales legales.

El registro de incidentes y eventos debe permitir reconstruir todas las etapas: detección, clasificación del incidente, escalado, decisión de notificación, comunicación, recuperación del servicio y cierre formal con las conclusiones correspondientes. Las evidencias relacionadas incluyen registros de vulnerabilidades, parches y excepciones aceptadas, revisiones de permisos, ejecución y restauración de copias de seguridad, cambios de configuración, actividades de administradores, formación y simulacros.

El aplazamiento de un parche debe quedar trazado desde la vulnerabilidad identificada, pasando por la evaluación del impacto y la decisión de excepción, hasta el establecimiento de controles compensatorios, la fecha de reevaluación y la confirmación del cierre. Una lista de parches pendientes no demuestra por sí sola que el retraso esté bajo control.

La supervisión de la cadena de suministro exige el mismo nivel de coherencia. Un listado de contratos no sustituye a la clasificación de proveedores, la evaluación de la dependencia de servicios y activos respecto de terceros, la definición de requisitos de seguridad, los registros de las revisiones ni las decisiones sobre deficiencias no aceptadas. El registro debe mostrar quién autorizó al proveedor, qué excepciones se aprobaron y cuándo tendrá lugar la siguiente evaluación. Deben vigilarse especialmente los proveedores sin una evaluación vigente y las acciones pendientes derivadas de revisiones anteriores. Esta cuestión también es relevante durante la ejecución del programa Implantación de NIS2 tras la inscripción en el Registro KSC: plan de actuación hasta el 3 de abril de 2027.

Las reglas de conservación, acceso y aprobación de cambios deben adaptarse al tipo de registro, su valor probatorio, los requisitos legales y contractuales y las necesidades de análisis de incidentes. No debe aplicarse un único plazo de conservación a todos los registros sin realizar antes este análisis. Los plazos de notificación de incidentes y las medidas de preservación de evidencias deben verificarse en cada caso conforme a la normativa vigente y a las directrices de la autoridad competente. El artículo Documentación de NIS2 y KSC antes de un control: qué políticas, registros y evidencias se necesitan realmente presenta un catálogo más amplio. Sin embargo, la madurez operativa depende de los registros generados durante el trabajo diario y de una trazabilidad visible desde el requisito hasta el resultado del control y la acción correctiva.

Toda prueba debe concluir con una decisión

La autoridad supervisora puede solicitar no solo el plan de continuidad de negocio, el procedimiento de respuesta ante incidentes o la confirmación de que se realizan copias de seguridad. También son relevantes las evidencias de que estas medidas se han probado en condiciones representativas de los servicios, tecnologías y dependencias reales de los proveedores. El programa de pruebas debe basarse en la evaluación de riesgos, la criticidad del servicio, los cambios en el entorno y los requisitos legales y contractuales. No existe una frecuencia única adecuada para todos los controles. Las áreas con mayor impacto, sujetas a cambios rápidos o en las que pruebas anteriores hayan detectado desviaciones importantes deben verificarse con mayor frecuencia.

Antes de iniciar cada prueba es necesario definir su objeto y los criterios de aceptación. El registro debe incluir el alcance, escenario, participantes, entorno, criterios de aceptación y tolerancias permitidas; una vez realizada, debe documentar el resultado, las desviaciones y el impacto real o potencial sobre el servicio. Si se detectan deficiencias, la evidencia debe identificar las acciones correctivas, sus responsables, los plazos y la fecha de una nueva verificación.

Entre los indicadores útiles se encuentran el tiempo real de recuperación, el punto de recuperación alcanzado, el tiempo de escalado y el porcentaje de acciones cerradas después de la prueba. El error organizativo más grave consiste en realizar pruebas periódicas sin criterios de éxito o sin cerrar las no conformidades detectadas.

Las pruebas clave incluyen la restauración de datos desde copias de seguridad, la conmutación a soluciones de contingencia, los ejercicios de respuesta ante incidentes, las pruebas de comunicación de crisis, las revisiones de permisos, la restauración de configuraciones y la comprobación técnica de vulnerabilidades, incluido el escaneo y, cuando el riesgo lo justifique, las pruebas de penetración. El resultado proporcionado por un proveedor puede formar parte de la evidencia, pero no sustituye a las pruebas de la organización cuando no incluye sus procesos, integraciones, responsabilidades y condiciones operativas.

Después de cada prueba, el propietario del servicio debe adoptar una decisión documentada: aceptar el resultado, aplicar una corrección, establecer un control compensatorio, repetir la prueba o aceptar el riesgo conforme a la autoridad que se le haya asignado.

La ejecución correcta de una copia de seguridad de una base de datos no demuestra por sí sola la capacidad para recuperar el servicio. Durante una prueba puede descubrirse que la aplicación requiere una versión de configuración no documentada, que el mecanismo de identidad no funciona en el entorno de contingencia, que las claves no están disponibles o que la única persona que conoce la secuencia de arranque de los componentes no participa en la recuperación. Solo la verificación de toda la cadena de dependencias permite comparar el tiempo y el punto de recuperación reales con los criterios establecidos, evaluar el impacto en el servicio y decidir si existe capacidad suficiente o si son necesarias mejoras.

Este método de documentación de pruebas resulta relevante en cualquier sector, también al analizar NIS2 para empresas industriales: a quién afecta, qué obligaciones introduce y cómo preparar la organización sin reducir el asunto exclusivamente a TI. El alcance de las evidencias esperadas debe corresponder a las obligaciones aplicables a la organización, sus servicios y el marco jurídico vigente. La secuencia esencial sigue siendo la misma: riesgo identificado, prueba planificada, criterio medible, resultado documentado, decisión del propietario y confirmación del cierre eficaz de las acciones.

Las incoherencias elevan el coste del control

Una documentación formalmente completa pierde valor cuando no refleja la realidad. La autoridad puede contrastar las declaraciones de las políticas con la configuración de los sistemas, los registros de solicitudes, los contratos, las listas de acceso, los resultados de escaneos, las actas de pruebas y las explicaciones de los propietarios de los procesos. No se trata de comprobar la uniformidad de la redacción, sino de poder seguir cada decisión desde la obligación y el riesgo identificados hasta el control implantado, el registro de su funcionamiento y la respuesta ante una desviación.

La simulación previa al inicio de las actuaciones de la autoridad debe utilizar una muestra seleccionada de forma intencionada de servicios, incidentes, proveedores y permisos, y recorrer la documentación hasta llegar a los datos de origen. Este ejercicio permite detectar inventarios de activos desactualizados, denominaciones distintas del mismo servicio en varios documentos, riesgos sin propietario, incidentes ausentes del registro, proveedores sin una evaluación documentada y acciones correctivas cerradas sin comprobar su eficacia. Las discrepancias deben resolverse determinando la situación real y el responsable del registro, no mediante una armonización apresurada de los documentos.

En una empresa industrial, la revisión no debe terminar en el entorno informático de oficina. Para un servicio seleccionado puede incluir mantenimiento, automatización, acceso remoto de asistencia técnica, gestión de configuraciones y dependencias entre sistemas de producción. Por ejemplo, el inventario de accesos podría no incluir una cuenta utilizada por un técnico externo aunque el contrato, el registro de conexión y la configuración del equipo confirmen su existencia. La relevancia de estas dependencias se desarrolla en NIS2 para empresas industriales: a quién afecta, qué obligaciones introduce y cómo preparar la organización sin reducir el asunto exclusivamente a TI.

Un certificado de sistema de gestión puede contribuir a estructurar la gestión de riesgos, el control documental, las auditorías y las acciones correctivas, pero no sustituye al análisis del alcance legal ni a las evidencias de cumplimiento de las obligaciones aplicables de KSC. Esta diferencia se explica en NIS2 e UNE-EN ISO 27001: qué aporta el certificado y qué sigue faltando para cumplir KSC. La ausencia de un registro concreto no determina automáticamente un incumplimiento, pero exige valorar la importancia de la evidencia, la causa de la laguna y la posibilidad de demostrar el funcionamiento del control mediante otros registros fiables.

El coste del control aumenta principalmente cuando las evidencias están dispersas, los poderes de decisión no están claros y nadie coordina las respuestas ni la aprobación de los materiales entregados. En ese momento, los equipos comienzan a conciliar manualmente datos contradictorios mientras el control ya está en curso. La designación previa de un coordinador, de los propietarios de cada evidencia y de reglas para resolver discrepancias reduce la carga de trabajo y el riesgo de presentar explicaciones incoherentes a la autoridad.

La preparación se construye mediante una simulación de control

La simulación interna debe comenzar confirmando la condición de la entidad, el alcance de los servicios sujetos a obligaciones y las responsabilidades de la dirección y de los propietarios de procesos. A continuación, el coordinador de la relación con la autoridad debe preparar una matriz de cumplimiento que vincule cada obligación con un responsable y una evidencia. Solo entonces deben revisarse muestras de registros, entrevistarse a las personas responsables y reconstruirse el desarrollo de un incidente o una prueba seleccionados. Conviene asignar la coordinación a una persona con acceso a la dirección y capacidad para resolver discrepancias, sin sustituir a los responsables técnicos y operativos de las evidencias.

Cada responsable de una obligación debe poder identificar:

• el documento de referencia que define la forma de actuación,
• el registro que demuestra el cumplimiento de la obligación,
• el indicador utilizado para evaluar la eficacia del control,
• la última decisión adoptada como resultado de la revisión.

La falta de cualquiera de estos elementos crea una interrupción en la cadena de evidencias. Un procedimiento de respuesta ante incidentes no es suficiente si la organización no puede presentar el registro del evento, el tiempo de respuesta, la evaluación de consecuencias, el resultado del análisis de causas y la decisión de modificar los controles. La reconstrucción de un caso también permite comprobar si las explicaciones del personal coinciden con los registros y con el desarrollo real de las actuaciones.

La simulación también debe cubrir la logística del control: recepción y registro del requerimiento, asignación de plazos y responsables de respuesta, aprobación de los materiales, protección de la información sensible, identificación de las versiones entregadas y documentación de las comunicaciones con la autoridad. Conviene ensayar una situación en la que el registro solicitado contenga datos ajenos al objeto del control o requiera una explicación contextual. De este modo puede establecerse quién decide el alcance de la divulgación y cómo mantiene la organización la trazabilidad de la documentación entregada.

El plan de mejora debe priorizar las lagunas según su impacto en el servicio, la exposición jurídica, la probabilidad de que sean detectadas y el tiempo necesario para obtener una evidencia fiable de eficacia, y no según la facilidad de redactar un procedimiento adicional. La dirección debe aprobar las prioridades, los recursos y el nivel de riesgo aceptable. Una acción solo puede cerrarse después de volver a verificar el funcionamiento del mecanismo.

El calendario debe derivarse de la condición real de la entidad, las comunicaciones con la autoridad y la normativa vigente. Una vez determinada esta condición, el análisis puede complementarse con NIS2: autoevaluación e inscripción en el Registro KSC: ¿qué debe hacer una empresa industrial? e Implantación de NIS2 tras la inscripción en el Registro KSC: plan de actuación hasta el 3 de abril de 2027. Las fechas y obligaciones indicadas en estos materiales deben confirmarse en cada caso conforme al marco jurídico vigente.