Durante mucho tiempo, cuando hablábamos de riesgos tecnológicos, la atención se dirigía casi siempre hacia lo que teníamos dentro de casa: servidores, redes, bases de datos, copias de seguridad, firewalls, usuarios, permisos y aplicaciones internas.
Todo eso sigue siendo importante.
Pero con los años he aprendido que una parte cada vez mayor del riesgo tecnológico no está dentro del CPD ni aparece en el inventario de servidores. Está en servicios que operan otros y de los que, sin embargo, depende nuestra propia operación.
Puede ser un SaaS, un hosting, una plataforma de firma, el correo, un servicio de backup, una API, una herramienta de ciberseguridad o una aplicación que solo puede mantener un tercero.
Algunos empiezan siendo servicios auxiliares. Otros se contratan para resolver una necesidad concreta. El problema aparece cuando, con el tiempo, terminan sosteniendo procesos importantes sin que hayamos revisado hasta qué punto dependemos de ellos.
Ahí es donde cambia la conversación.
Externalizar un servicio no significa externalizar el riesgo.
Puede que el servidor no sea nuestro. Puede que no administremos la plataforma ni tengamos acceso directo a la base de datos. Pero si el proveedor falla y la operación se detiene, el impacto sigue siendo nuestro.
Por eso ya no miro a los proveedores TIC solamente como contratos, facturas o servicios externos. Cuando están detrás de procesos, datos o servicios relevantes, forman parte del mismo mapa tecnológico que los sistemas que gestionamos directamente.
El proveedor también forma parte de tu tecnología
Un servidor interno resulta fácil de identificar. Tiene nombre, dirección IP, sistema operativo, copias, monitorización y alguien responsable de mantenerlo.
Con un proveedor no siempre ocurre lo mismo. Puede aparecer en la organización simplemente como «el servicio de correo», «la plataforma de firma» o «la aplicación que mantiene un tercero». Esa forma de nombrarlo hace que la dependencia parezca menos tecnológica de lo que realmente es.
Para mí, la pregunta no es si el servicio está dentro o fuera de la organización. La pregunta es qué proceso sostiene y qué ocurre si deja de estar disponible.
Un proveedor de comunicaciones, una API externa, un SaaS de gestión o una solución de backup no tienen por qué recibir el mismo nivel de control. Pero si alguno de ellos sostiene un proceso relevante, debe estar identificado y relacionado con ese proceso.
No solo por cumplimiento.
Por sentido común operativo.
El error de pensar “eso lo lleva el proveedor”
Hay una frase que se escucha mucho:
Eso lo lleva el proveedor.
Y muchas veces es verdad. El proveedor lo opera, lo mantiene, lo actualiza, lo monitoriza o lo soporta.
Pero esa frase no debería cerrar la conversación. Debería abrirla.
Cuando escucho esa respuesta, mi siguiente pregunta suele ser qué significa exactamente «lo lleva». Puede significar que el proveedor administra la infraestructura, pero no necesariamente que alguien esté siguiendo el servicio, comprobando las copias, revisando los cambios o preparando una alternativa si deja de funcionar.
- qué servicio presta realmente,
- qué proceso sostiene,
- qué datos trata,
- qué ocurre si deja de estar disponible,
- cómo comunica y escala las incidencias,
- qué compromisos existen,
- qué alternativa tenemos,
- y quién es responsable de seguirlo internamente.
Si no sabemos responder a eso, no estamos gestionando bien el proveedor.
Estamos confiando.
Y confiar está bien, pero no sustituye a gestionar.
La calidad de un proveedor no se descubre únicamente cuando se firma el contrato. Se descubre cuando algo falla, cuando necesitas recuperar el servicio o cuando quieres salir.
No todos los proveedores son críticos
Una buena gestión de proveedores no consiste en tratar a todos igual.
Eso sería inviable y, además, bastante inútil.
No es lo mismo un proveedor accesorio que uno que sostiene un proceso clave. No es lo mismo una herramienta secundaria que una plataforma sin la cual no puedes operar. No es lo mismo un SaaS con datos poco sensibles que un proveedor que trata información personal, financiera, contractual o confidencial.
Por eso, antes de complicarse, conviene clasificar.
Una forma sencilla de verlo sería esta:
- Proveedor crítico: si falla, afecta de forma importante al servicio, a clientes, usuarios, continuidad, seguridad o cumplimiento.
- Proveedor importante: si falla, genera impacto relevante, pero puede existir alguna alternativa temporal.
- Proveedor operativo: ayuda al funcionamiento diario, pero su caída no paraliza un proceso clave.
- Proveedor accesorio: impacto bajo o fácilmente sustituible.
La clasificación no tiene que ser perfecta el primer día.
Pero tiene que servir para priorizar.
Como explico también en Gestión de riesgos TIC sin humo, clasificar no consiste en rellenar una matriz perfecta. Consiste en distinguir dónde merece la pena dedicar más atención y dónde el riesgo puede asumirse con controles más sencillos.
Donde hay más dependencia, más datos, más impacto o menos alternativa, hace falta más control.
La dependencia no siempre se ve
Uno de los problemas con los proveedores TIC es que la dependencia a veces está escondida.
Un proveedor puede parecer pequeño hasta que falla.
Una API externa puede parecer secundaria hasta que deja de responder y bloquea un proceso. Un certificado gestionado por un tercero puede parecer un detalle hasta que caduca. Una herramienta de soporte puede parecer auxiliar hasta que la necesitas en mitad de una incidencia. Un proveedor de comunicaciones puede parecer invisible hasta que se cae.
La dependencia tecnológica no siempre coincide con el tamaño del contrato.
Puede haber proveedores con poco coste económico y mucho impacto operativo.
Por eso no basta con mirar facturas.
Hay que mirar procesos.
La pregunta no debería ser solo cuánto cuesta un proveedor. La pregunta importante es otra:
¿Qué deja de funcionar si este proveedor falla?
Qué datos trata el proveedor
Otro punto básico son los datos.
Un proveedor TIC no tiene el mismo riesgo si solo presta un servicio técnico sin datos sensibles que si trata información personal, financiera, contractual, laboral, médica o confidencial.
Para cada proveedor relevante conviene saber:
- qué datos trata,
- dónde se alojan,
- si hay subcontratistas,
- si hay transferencias internacionales,
- qué medidas de seguridad aplica,
- qué pasa con los datos al finalizar el servicio,
- y si existe contrato o anexo de protección de datos cuando procede.
No hace falta convertir cada revisión en una auditoría eterna.
Pero tampoco podemos tratar todos los proveedores como si fueran iguales.
Hay proveedores que apenas tocan información relevante. Otros, en cambio, pueden tener acceso a datos, sistemas o procesos sensibles para la organización.
Y eso hay que tenerlo claro antes de que haya un problema.
DORA y el foco en terceros TIC
En sectores regulados, DORA ha puesto el foco precisamente en esto: no basta con mirar la tecnología interna. También hay que gestionar el riesgo de terceros TIC.
DORA exige a las entidades financieras mantener un marco de gestión del riesgo TIC y prestar atención a los acuerdos con proveedores de servicios TIC, especialmente cuando esos servicios soportan funciones críticas o importantes.
Además, el registro de información sobre proveedores TIC no es una simple lista de nombres. La idea es tener una visión ordenada de qué servicios presta cada proveedor, qué funciones soporta, qué acuerdos existen y qué dependencias hay.
Dicho de forma sencilla:
si un proveedor sostiene una parte importante de tu operación, tienes que saberlo, documentarlo y poder explicarlo.
No lo menciono para convertir este artículo en normativa.
Lo menciono porque DORA formaliza algo que ya tenía sentido antes: no puedes gestionar bien una tecnología si no sabes quién la sostiene.
Y tampoco puedes limitarte a saberlo en teoría. Si el proveedor es crítico, hay que pensar qué harías si no responde, si tarda más de lo previsto o si el servicio queda fuera durante más tiempo del esperado.
El contrato no es solo cosa de legal
Hay contratos TIC que se firman y luego nadie vuelve a mirar.
Eso es un problema.
Un contrato tecnológico no debería ser solo un PDF guardado en una carpeta. Debería ayudar a entender qué se ha contratado, qué compromisos existen y qué pasa si hay problemas.
En proveedores relevantes, conviene revisar aspectos como:
- servicio contratado,
- alcance real,
- niveles de servicio,
- soporte,
- horarios de atención,
- notificación de incidentes,
- seguridad,
- subcontratación,
- ubicación de datos,
- continuidad,
- salida o reversibilidad,
- y responsabilidades de cada parte.
No hace falta que el responsable técnico sea abogado.
Pero sí tiene que entender lo suficiente como para detectar si el contrato no cubre lo que la operación necesita.
Porque luego, cuando hay una incidencia, no vale descubrir que el soporte era solo en horario laboral, que la restauración no estaba incluida o que nadie sabe cómo recuperar los datos.
La reversibilidad: pensar en salir antes de entrar
Hay una pregunta incómoda que conviene hacerse antes de depender demasiado de un proveedor:
¿Cómo salgo de aquí si algún día lo necesito?
La reversibilidad no es pesimismo. Es prudencia.
Significa saber cómo recuperar los datos, en qué formatos se entregan, qué dependencias habría que reconstruir, qué ayuda prestaría el proveedor y cuánto tiempo podría llevar una migración.
Entrar en un servicio suele ser relativamente fácil. Salir no siempre lo es.
Y cuanto más crítico sea el servicio, más peligroso resulta descubrir esas limitaciones cuando la relación ya está terminando, la plataforma ha dejado de ser viable o necesitas recuperar la operación con urgencia.
Pensar en la salida tampoco sirve únicamente para una emergencia. Ayuda a cambiar de tecnología, migrar a otra plataforma o rediseñar una arquitectura que ya no responde a lo que necesitas.
La reversibilidad no es solo una cláusula contractual.
Es conocer suficientemente el servicio como para no quedar completamente atrapado.
Incidentes de proveedor: cuando el fallo no está en tu casa
Otra parte importante es la gestión de incidentes.
Si se cae un servidor interno, puedes mirar logs, revisar servicios, reiniciar, restaurar o escalar internamente.
Cuando falla un proveedor, dependes de otra cadena:
- que detecte el incidente,
- que lo comunique,
- que explique alcance e impacto,
- que dé tiempos estimados,
- que mantenga actualizaciones,
- y que cierre el incidente con información útil.
Por eso conviene saber de antemano cómo comunica incidencias cada proveedor crítico.
No en mitad del incendio.
También conviene tener claro quién habla con quién. Quién abre el ticket. Quién escala. Quién recibe el aviso. Quién informa internamente. Quién decide si hay que activar una alternativa.
Todo eso parece obvio hasta que ocurre una incidencia y nadie tiene claro el circuito.
La vía técnica propia: no depender de una sola respuesta
En mi caso, cuando un proveedor sostiene un servicio importante, intento no quedarme solo con una vía de recuperación.
El soporte del proveedor es necesario. Los SLA también. Los contactos de escalado, la comunicación de incidencias y los compromisos por escrito son importantes.
Pero ante un incidente serio eso no siempre es suficiente.
Puede ocurrir que el proveedor responda más lento de lo esperado. Que el diagnóstico tarde. Que la incidencia afecte a más clientes. Que el tiempo estimado cambie. O que, simplemente, no tengas una respuesta clara cuando más la necesitas.
Por eso, siempre que el servicio lo permite, me parece vital tener una segunda vía preparada: copias de seguridad, recursos técnicos y capacidad suficiente para levantar el servicio en otra infraestructura, aunque el RTO sea más alto.
No siempre será la opción más rápida ni la más sencilla.
Pero es una vía real.
Y en una caída de un proveedor crítico, tener una vía real cambia mucho la situación.
La gestión del incidente no debería depender de una sola carta. Puedes estar trabajando con el proveedor, abriendo ticket, escalando y esperando actualización. En paralelo, puedes validar copias, revisar dependencias, preparar infraestructura alternativa, comprobar configuraciones y valorar si es viable levantar el servicio por otra vía.
Incluso puede haber una tercera vía.
Porque en un incidente real no gana la vía más elegante. Gana la que antes consigue recuperar el servicio con seguridad suficiente.
DORA ha dado estructura normativa a muchas de estas cuestiones, pero la necesidad de entender las dependencias, la continuidad y la capacidad de salida ya era evidente mucho antes para cualquiera que hubiera tenido que convivir con servicios externos importantes.
DORA lo que hace es ponerle estructura, evidencia y gobierno a algo que en la práctica ya tenía mucho sentido: si dependes de un tercero para un servicio importante, tienes que saber qué haces si ese tercero no responde como esperabas.
Por eso, cuando reviso un proveedor crítico, no me quedo solo en el contrato. Necesito saber si tenemos copias utilizables, si realmente sabemos restaurarlas, qué dependencias habría que reconstruir, dónde podríamos levantar el servicio y quién tendría que decidir la activación de esa vía alternativa.
No basta con que todo eso exista sobre el papel. Hay que saber cuánto tardaríamos, qué información podríamos perder y si disponemos de las configuraciones, credenciales y documentación necesarias para hacerlo de verdad.
La copia por sí sola no resuelve nada si nadie sabe restaurarla.
El SLA por sí solo tampoco resuelve nada si el proveedor tarda más de lo previsto.
La resiliencia está precisamente en no depender de una única respuesta.
Esa preparación también da libertad para cambiar. Si conservas copias utilizables, configuraciones, documentación y conocimiento suficiente para reconstruir el servicio, no solo estás mejor preparado ante una caída. También reduces la dependencia cuando necesitas migrar, cambiar de proveedor o sacar un sistema de una plataforma que ya no te conviene.
No significa que la transición vaya a ser rápida. Algunas migraciones duran meses y algunas dependencias son difíciles de romper. La diferencia es que no partes de cero ni estás completamente atado a una única vía.
Preguntas que suelo hacerme sobre un proveedor TIC
Para bajar todo esto a tierra, suelo empezar por unas preguntas bastante sencillas:
- ¿Qué servicio presta y qué proceso depende de él?
- ¿Qué impacto tendría que dejara de funcionar?
- ¿Qué datos trata y dónde se alojan?
- ¿Existen subcontratistas relevantes?
- ¿Qué compromisos de servicio y soporte tenemos realmente?
- ¿Cómo comunica y escala las incidencias?
- ¿Disponemos de copias utilizables y sabemos restaurarlas?
- ¿Existe una alternativa temporal o una vía técnica de recuperación?
- ¿Cómo recuperaríamos los datos y saldríamos del servicio?
- ¿Quién es responsable de revisar todo esto dentro de la organización?
- ¿Cuándo se comprobó por última vez que las respuestas siguen siendo válidas?
No todas las respuestas estarán claras al principio.
Pero si no hacemos las preguntas antes de que haya un problema, probablemente tendremos que responderlas en el peor momento.
Un inventario de proveedores que sirva para algo
Igual que ocurre con los activos TIC, un inventario de proveedores no debería ser una lista muerta. Debería ayudar a comprender dependencias y tomar decisiones.
Como explico en Activos TIC: el inventario que sí sirve para algo, el valor del inventario no está en acumular campos, sino en relacionar cada elemento con el servicio y el proceso que sostiene.
En el caso de los proveedores, como mínimo necesito saber:
- qué servicio presta;
- qué proceso soporta;
- qué criticidad tiene;
- qué datos trata;
- qué compromisos contractuales y de servicio existen;
- quién es el responsable interno;
- qué dependencias y subcontrataciones conocemos;
- qué ocurre si falla;
- qué copias o alternativas tenemos;
- cómo se recuperan los datos y cómo se sale del servicio;
- y cuándo se revisó por última vez.
Con eso ya tenemos una base mucho mejor que «lo lleva el proveedor».
Después se puede ampliar cuanto sea necesario, pero prefiero un inventario sencillo, vivo y utilizado antes que una herramienta enorme que nadie mantiene.
Lo que me ha enseñado la experiencia
Con los proveedores, el problema no suele estar únicamente en que sean buenos o malos. Muchas veces está en no saber qué papel juegan realmente dentro de la operación.
He visto servicios que empezaron siendo auxiliares y terminaron convirtiéndose en dependencias importantes. También he visto proveedores pequeños que, casi sin hacerse visibles, sostenían procesos críticos, y plataformas contratadas para resolver una necesidad concreta que, con el tiempo acabaron formando parte de la operación diaria.
También he aprendido que contratar bien no es suficiente.
Después hay que seguir el servicio, revisar cambios, mantener actualizados los contactos y las dependencias, comprobar las copias, probar la continuidad y conservar una salida razonable.
Ese trabajo posterior tiene un coste y exige atención. Pero normalmente cuesta mucho menos que descubrir, durante una incidencia, que el contrato no cubría lo que creíamos, que la copia no podía restaurarse o que nadie sabía cómo reconstruir el servicio fuera del proveedor.
Por eso miro los proveedores como parte del mapa TIC, no como algo separado.
Contrato y SLA, sí.
Pero también conocimiento, documentación, pruebas, capacidad de recuperación y una alternativa técnica cuando el servicio lo justifica.
Conclusión
El riesgo TIC no siempre está en tu servidor.
A veces está en un proveedor que sostiene un proceso importante, en una API que parecía secundaria, en una plataforma SaaS que se volvió imprescindible o en un contrato que nadie volvió a revisar después de firmarlo.
Gestionar proveedores TIC no consiste en desconfiar de todo el mundo ni en acumular documentación.
Consiste en entender la dependencia.
Saber quién sostiene qué, qué datos trata, qué ocurre si falla, cómo se comunica una incidencia, qué compromisos existen, qué alternativas tenemos y cómo recuperaríamos el servicio o saldríamos de él.
Externalizar puede ser una decisión excelente.
Pero externalizar sin comprender la dependencia es trabajar a ciegas.
Y cuando el servicio es crítico, confiar únicamente en que el proveedor responderá como esperamos deja demasiado poco margen.
Por eso prefiero mantener varias vías abiertas: el soporte, la escalada contractual y, cuando sea viable, una capacidad técnica propia para recuperar el servicio aunque sea más lenta.
Puede que esa alternativa no llegue a utilizarse nunca.
Pero el día que haga falta, marcará la diferencia entre limitarse a esperar o seguir teniendo una opción real.
Fuentes de referencia
- Reglamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA), EUR-Lex
- Reglamento de Ejecución (UE) 2024/2956 — plantillas para el registro de información sobre proveedores TIC, EUR-Lex
- EIOPA — Reglas bajo DORA sobre riesgo TIC, terceros e incidentes
- DGSFP — Reglamento de Resiliencia Operativa Digital (DORA)
¿Quieres seguir explorando?
Puedes descubrir más artículos, seguir mis publicaciones en LinkedIn o escribirme.