GRC, ITSM, hojas o plataforma de ciberseguridad
La decisión no es “Excel o software”: puede combinar sistemas maestros, especialistas y una capa que coordine terceros y excepciones.
Mapa de alternativas
GRC para riesgos; ITSM/SIEM para operación; CMDB para activos; procurement para contratos; repositorio de código/SBOM; plataforma de evidencia para terceros y excepciones. Cada opción cubre una parte distinta y debe evaluarse por operación completa, no por número de funciones.
Cuándo basta una hoja
Una hoja puede servir para probar este caso: una entidad financiera depende de un SaaS que subcontrata infraestructura y además distribuye un dispositivo conectado propio. 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. Si aparece esta incidencia —un proveedor crítico aporta un certificado cuyo alcance no incluye el servicio contratado y notifica un incidente sin identificar las entidades afectadas—, comprueba si permite asignar la corrección, conservar versiones y preparar registro de riesgos y controles, inventario de terceros, contratos, evidencias, SBOM y vulnerabilidades, línea temporal de incidentes, notificaciones y planes de remediación; si ese seguimiento depende de correos separados, el piloto necesita otra forma de coordinación.
Sistemas internos
El sistema maestro aporta identidad, compras, lotes o activos. Valora cuánto esfuerzo requiere pedir información externa, interpretar archivos, gestionar cambios y conservar decisiones.
Especialistas y consultoría
Aportan método y criterio. Define transferencia, propiedad de datos, actualización, tiempo de respuesta y cómo seguirá funcionando el proceso entre revisiones.
Criterios de elección
Mide volumen, terceros, variabilidad, excepciones, coste de error, plazos, mercados, integraciones, auditoría y salida. Prueba específicamente: un proveedor crítico aporta un certificado cuyo alcance no incluye el servicio contratado y notifica un incidente sin identificar las entidades afectadas.
Mapa operativo específico de NIS2, DORA y CRA
Para esta decisión sobre comparación de alternativas, 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.