Ejemplo de expediente de un proveedor TIC crítico
El escenario muestra el flujo y los controles sin presentarse como caso de cliente ni inventar métricas de ahorro.
Escenario
una entidad financiera depende de un SaaS que subcontrata infraestructura y además distribuye un dispositivo conectado propio. Intervienen órgano de dirección, CISO, propietario de activo, entidad financiera, fabricante, proveedor TIC, subcontratista, CSIRT, supervisor y usuario. El equipo fija identificadores, alcance, fecha límite y responsable antes de pedir información.
Información reunida
El expediente solicita y relaciona 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. Cada respuesta conserva emisor, fecha, versión y objeto cubierto.
Control aplicado
Se revisan 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. Los datos técnicamente válidos no se aceptan si pertenecen a otra versión, periodo, instalación, lote o servicio.
Excepción
Durante la revisión ocurre lo siguiente: un proveedor crítico aporta un certificado cuyo alcance no incluye el servicio contratado y notifica un incidente sin identificar las entidades afectadas. El proceso bloquea solo la parte afectada y solicita la aclaración al actor capaz de resolverla.
Resolución
Se conserva la respuesta y el documento o dato corregido, se repiten los controles afectados y una persona competente aprueba o rechaza con motivo.
Resultado
El resultado 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. La auditoría puede reconstruir qué cambió, quién lo aportó, qué regla se aplicó y quién tomó la decisión.
Mapa operativo específico de NIS2, DORA y CRA
Para esta decisión sobre caso práctico, 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.