Software para evidencias NIS2, DORA y CRA
El software adecuado conecta entidad, activo, servicio, función crítica, riesgo, control, evidencia, proveedor, contrato, ubicación, vulnerabilidad, versión, incidente, impacto, plazo, notificación y remediación; no convierte un repositorio o formulario en cumplimiento automático.
Trabajo que debe coordinar
Participan órgano de dirección, CISO, propietario de activo, entidad financiera, fabricante, proveedor TIC, subcontratista, CSIRT, supervisor y usuario. La herramienta debe asignar qué aporta cada uno, conservar contexto y evitar que una corrección quede separada del expediente.
Capacidades mínimas
Debe cubrir alcance NIS2/DORA/CRA; activo y propietario; eficacia del control; servicio y subcontratación; concentración; SBOM; soporte; clasificación de incidente; reloj 24/72 horas o CRA; aprobación y cierre. También necesita permisos, historial, versiones, alertas, búsquedas y exportación sin encerrar los datos.
Entradas y salidas
Entradas principales: entidad, activo, servicio, función crítica, riesgo, control, evidencia, proveedor, contrato, ubicación, vulnerabilidad, versión, incidente, impacto, plazo, notificación y remediación. El resultado esperado no es “documentos subidos”, sino registro de riesgos y controles, inventario de terceros, contratos, evidencias, SBOM y vulnerabilidades, línea temporal de incidentes, notificaciones y planes de remediación.
Integraciones honestas
ERP, PLM, QMS, GIS, LIMS o portales oficiales pueden ser origen o destino. Exige distinguir conector desplegado, API configurable, exportación manual y función todavía no disponible.
Prueba de compra
Usa un caso anonimizado y fuerza esta excepción: un proveedor crítico aporta un certificado cuyo alcance no incluye el servicio contratado y notifica un incidente sin identificar las entidades afectadas. Comprueba detección, asignación, corrección, aprobación, trazabilidad y salida.
Mapa operativo específico de NIS2, DORA y CRA
Para esta decisión sobre software y herramientas, el modelo debe relacionar marco · entidad/producto · sector · activo · servicio · función · proveedor · contrato · subcontratista · país · riesgo · control · evidencia · vulnerabilidad · versión · incidente · impacto · plazo · notificación · cierre. Los participantes reales son órgano de dirección, CISO, propietario de activo, entidad financiera, fabricante, proveedor TIC, subcontratista, CSIRT, supervisor y usuario. La salida verificable es registro de riesgos y controles, inventario de terceros, contratos, evidencias, SBOM y vulnerabilidades, línea temporal de incidentes, notificaciones y planes de remediación.
Prueba de estrés antes de aprobar
Reproduce este escenario: una entidad financiera depende de un SaaS que subcontrata infraestructura y además distribuye un dispositivo conectado propio. Introduce deliberadamente la excepción “un proveedor crítico aporta un certificado cuyo alcance no incluye el servicio contratado y notifica un incidente sin identificar las entidades afectadas”. Comprueba qué sistema la detecta, quién recibe la tarea, qué fuente resuelve la duda y cómo queda registrada la aprobación.
La herramienta organiza; el responsable decide
El expediente debe conservar dato, fuente, versión, control, excepción y aprobación. Code Contract puede coordinar la operación, pero no sustituye la evaluación técnica, la declaración oficial ni al supervisor.