Gestión de riesgos TIC sin humo: antes del Excel, entiende tu tecnología

Cuando se habla de gestión de riesgos TIC, mucha gente piensa directamente en matrices, niveles de impacto, probabilidades, controles, evidencias, auditorías y normativa.

Y sí, todo eso existe.

Pero antes de llegar al Excel, al informe o a la herramienta de gobierno, hay una pregunta mucho más básica:

¿Entendemos de verdad qué tecnología sostiene el servicio y qué pasa si falla?

Para mí, la gestión de riesgos TIC empieza ahí. No empieza en una matriz bonita. Empieza entendiendo la realidad.

Qué sistemas tenemos.
Qué datos gestionan.
Qué usuarios o procesos dependen de ellos.
Qué proveedor hay detrás.
Qué pasaría si fallan.
Qué controles existen de verdad.
Qué está documentado.
Qué se puede recuperar y en cuánto tiempo.

Ese es el punto de partida.

La gestión de riesgos TIC no debería ser burocracia

Uno de los problemas de la gestión de riesgos es que muchas veces se explica mal.

Se presenta como algo pesado, normativo, lleno de conceptos y alejado del día a día técnico. Como si fuera una obligación que se hace para que un auditor, un supervisor o un comité puedan marcar una casilla.

Pero bien entendida, la gestión de riesgos TIC es bastante más sencilla:

Es saber qué puede fallar, qué impacto tendría y qué estamos haciendo para evitarlo o recuperarnos.

Eso no es burocracia. Eso es sentido común aplicado a tecnología.

Si tengo un servidor crítico, quiero saber qué pasa si se cae. Si tengo un proveedor que presta un servicio importante, quiero saber qué pasa si deja de responder. Si tengo copias de seguridad, quiero saber si realmente puedo restaurar. Si tengo acceso remoto, quiero saber quién entra, desde dónde y hasta dónde puede llegar.

No hace falta empezar con palabras raras. Hace falta hacerse buenas preguntas.

Antes de hablar de riesgos, hay que hablar de activos

No puedes proteger lo que no sabes que tienes.

Y esto parece obvio, pero en tecnología pasa más de lo que parece. Un servidor antiguo, una máquina virtual que “sigue ahí”, un contenedor que nadie recuerda quién montó, una base de datos que da servicio a un proceso pequeño pero importante, una cuenta de administrador que no se revisa desde hace años, un proveedor que empezó como algo puntual y terminó siendo crítico.

Todo eso son activos TIC o, como mínimo, piezas que pueden afectar al servicio.

Cuando hablo de activos TIC no me refiero solo a hardware. No es solo el servidor físico, el NAS, el firewall o el portátil.

También son activos:

aplicaciones,
bases de datos,
máquinas virtuales,
contenedores,
servicios cloud,
cuentas de usuario,
certificados,
copias de seguridad,
integraciones,
proveedores TIC,
documentación técnica,
automatizaciones,
herramientas de monitorización,
y cualquier pieza tecnológica que sostenga un proceso.

El inventario no debería ser un listado muerto. Debería ayudar a entender la realidad.

Para cada activo importante, como mínimo, deberíamos poder responder:

qué es,
para qué sirve,
quién lo usa,
qué datos trata,
qué depende de él,
quién lo mantiene,
qué proveedor interviene,
cómo se copia,
cómo se recupera,
y qué impacto tendría si falla.

Si no podemos responder a eso, todavía no estamos gestionando bien el riesgo. Estamos confiando en que todo siga funcionando.

El riesgo TIC explicado sin complicarlo

Un riesgo TIC no es una frase elegante en un documento.

Un riesgo TIC es algo que puede pasar y que, si pasa, afecta al servicio, a la seguridad, a los datos, a la operación o a la capacidad de recuperación.

Por ejemplo:

que una copia de seguridad no restaure,
que un proveedor crítico tenga una caída,
que un servidor expuesto tenga una configuración débil,
que una cuenta con demasiados permisos se vea comprometida,
que una actualización rompa un servicio,
que nadie detecte una caída hasta que avisa un usuario,
que un sistema antiguo siga siendo crítico sin que nadie lo tenga claro,
que un incidente no se comunique bien porque no hay procedimiento.

La teoría suele hablar de amenaza, vulnerabilidad, probabilidad, impacto y control. Está bien. Son conceptos útiles. Pero en el día a día yo lo bajo a preguntas más simples:

¿Qué puede salir mal?
¿Qué impacto tendría?
¿Cómo me enteraría?
¿Qué tengo para evitarlo?
¿Qué tengo para recuperarme?
¿Quién tiene que actuar?
¿Está probado o solo lo damos por hecho?

Ese último punto es clave.

En tecnología hay muchas cosas que damos por hechas hasta que fallan. Las copias “están”. La monitorización “avisa”. El proveedor “responde”. La VPN “es segura”. La documentación “más o menos está”. El plan de recuperación “ya lo miraremos”.

El problema es que un riesgo no espera a que tengamos tiempo.

DORA no inventa el sentido común, lo ordena

En sectores regulados, DORA ha puesto mucho foco en algo que ya debería formar parte de una buena gestión tecnológica: la resiliencia operativa digital.

Dicho de forma sencilla: no basta con tener tecnología. Hay que ser capaz de resistir, responder y recuperarse cuando esa tecnología falla o se ve afectada por un incidente.

DORA habla de gestión del riesgo TIC, incidentes, pruebas de resiliencia, proveedores TIC y otros elementos importantes. Pero si lo bajamos al terreno práctico, el mensaje es bastante claro:

conoce tus activos,
entiende tus riesgos,
aplica controles útiles,
detecta incidentes,
prueba tu capacidad de recuperación,
controla tus proveedores,
y deja evidencias de lo que haces.

Esto no debería verse como una montaña de papeles.

De hecho, hacerlo bien ayuda a operar mejor. Porque cuando tienes claro qué es crítico, qué depende de qué, cómo se recupera algo y quién tiene que actuar, no solo cumples mejor. También trabajas con menos improvisación.

El Excel no es el enemigo, pero no puede ser el principio

No tengo nada contra los Excel. De hecho, muchas veces son una herramienta muy útil para empezar.

El problema es cuando el Excel se convierte en el centro de todo.

Si la gestión de riesgos consiste únicamente en rellenar columnas, poner colores y actualizar una matriz una vez al año, algo falla.

Una matriz puede ayudarte a ordenar. Pero no sustituye el conocimiento real de la tecnología.

Antes de valorar un riesgo como alto, medio o bajo, hay que entenderlo. Antes de poner un control, hay que saber si existe de verdad. Antes de decir que algo está mitigado, hay que comprobar si funciona. Antes de hablar de continuidad, hay que probar la recuperación.

El Excel debería reflejar la realidad, no inventarla.

Un ejemplo sencillo: backups

Un backup es un buen ejemplo porque todo el mundo entiende la idea.

La visión técnica suele ser:

tengo copias,
se ejecutan por la noche,
hay una retención,
y el sistema dice que han terminado correctamente.

La visión de gestión TIC añade otras preguntas:

¿qué sistemas están incluidos?
¿qué datos quedan fuera?
¿cuánto tiempo podemos perder?
¿cuánto tiempo tardamos en recuperar?
¿quién puede restaurar?
¿dónde se guardan las copias?
¿están protegidas frente a ransomware?
¿se ha probado una restauración real?
¿queda evidencia de esa prueba?

Ahí cambia todo.

Porque una copia de seguridad no sirve por existir. Sirve cuando puedes recuperar algo importante en un tiempo razonable y con un resultado probado.

Ese es el salto entre “tengo backups” y “tengo capacidad de recuperación”.

Otro ejemplo: acceso remoto

Con una VPN pasa algo parecido.

Desde el punto de vista técnico, puedes decir: tengo WireGuard, tengo túnel, me conecto desde fuera y accedo a mis servicios.

Pero desde gestión TIC aparecen más preguntas:

¿quién tiene acceso?
¿desde qué dispositivos?
¿a qué redes llega?
¿hay separación entre entornos?
¿qué pasa si se pierde un dispositivo?
¿cómo se revoca un acceso?
¿hay registro suficiente?
¿está documentado?

La tecnología puede estar bien montada y aun así estar mal gobernada.

Ese matiz es importante.

Otro ejemplo: monitorización

Otro caso muy claro es la monitorización.

Grafana, Prometheus, Uptime Kuma o cualquier otra herramienta pueden ser muy útiles. Pero la pregunta de fondo no es si la gráfica queda bien.

La pregunta es:

¿Me ayuda a enterarme antes de que algo falla y a responder mejor?

Si un servicio cae y me entero por una alerta, tengo margen. Si me entero porque llama un usuario, ya voy tarde.

Desde gestión TIC, la monitorización conecta con detección, continuidad, evidencias, tiempos de respuesta y mejora continua.

No se trata de mirar dashboards todo el día. Se trata de tener señales útiles.

Los proveedores también son parte del riesgo

Durante años se ha repetido mucho eso de “lo tengo externalizado”.

Pero externalizar un servicio no significa externalizar la responsabilidad.

Si un proveedor sostiene una parte importante del servicio, forma parte del mapa de riesgos. Puede que el servidor no esté en tu CPD, puede que la aplicación esté en SaaS y puede que el soporte dependa de un tercero, pero el impacto de una caída lo sufres tú.

Por eso conviene saber:

qué servicio presta el proveedor,
qué proceso depende de él,
qué datos trata,
qué nivel de servicio existe,
cómo comunica incidentes,
qué pasa si deja de prestar servicio,
qué alternativas hay,
y qué compromisos están por escrito.

No hace falta convertir cada proveedor en una novela, pero sí entender qué papel juega.

Hay proveedores que son accesorios. Otros son críticos. Y no deberían gestionarse igual.

Controles que sirven de verdad

Un control no debería ser algo que existe solo en un documento.

Un control útil es algo que reduce un riesgo real.

Puede ser técnico:

MFA,
hardening,
segmentación,
copias protegidas,
monitorización,
cifrado,
revisión de permisos,
actualizaciones controladas.

Puede ser organizativo:

procedimiento de cambios,
plan de continuidad,
registro de incidentes,
revisión de proveedores,
documentación mínima,
roles y responsabilidades claras.

Y puede ser algo tan básico como probar una restauración, revisar usuarios que ya no deberían estar activos o comprobar que una alerta llega a quien tiene que llegar.

Los controles no tienen que ser espectaculares. Tienen que ser útiles, entendibles y mantenibles.

La evidencia no es postureo

Otra palabra que suele sonar aburrida es “evidencia”.

Pero en entornos regulados, y también en cualquier entorno serio, no basta con hacer las cosas. Hay que poder demostrar que se hacen.

Una evidencia puede ser:

un informe de prueba de restauración,
un registro de revisión de usuarios,
una captura de una configuración crítica,
un log de monitorización,
un acta de revisión de proveedor,
un ticket de cambio,
un documento de análisis de incidente,
o una simple nota bien fechada que explique qué se revisó y con qué resultado.

No se trata de documentar por documentar.

Se trata de no depender de la memoria.

Cuando algo falla, cuando alguien pregunta, cuando hay una auditoría o cuando tienes que revisar una decisión tomada hace meses, agradecerás tener una mínima trazabilidad.

Lo que me ha enseñado el homelab

Mi homelab me ha ayudado mucho a aterrizar estas ideas.

En casa puedes probar, romper, volver atrás y aprender sin el impacto que tendría hacerlo en un entorno profesional. Puedes montar un servicio, exponerlo con un proxy inverso, protegerlo con VPN, monitorizarlo, hacer copias, actualizarlo y ver qué pasa cuando algo deja de funcionar.

Y ahí aprendes rápido.

Aprendes que algo puede funcionar y aun así estar mal documentado.

Aprendes que una actualización puede romper una dependencia.

Aprendes que una alerta mal configurada no sirve.

Aprendes que un backup que no has probado es una promesa.

Aprendes que abrir un servicio desde fuera siempre tiene implicaciones.

Y aprendes que la tecnología, cuando empieza a sostener procesos reales, deja de ser solo una prueba.

Ese aprendizaje luego cambia la forma de mirar los entornos profesionales. Porque en el trabajo no basta con que algo funcione hoy. Tiene que poder mantenerse mañana, explicarse dentro de seis meses y recuperarse cuando haya un problema.

Una forma sencilla de empezar

Si tuviera que empezar desde cero una gestión de riesgos TIC sencilla, no empezaría por una matriz compleja.

Empezaría por una tabla muy básica con estas columnas:

Activo: qué sistema, servicio, proveedor o herramienta estoy revisando.
Para qué sirve: qué proceso o necesidad cubre.
Criticidad: qué impacto tendría si falla.
Riesgo principal: qué puede salir mal.
Control actual: qué tengo hoy para reducir ese riesgo.
Problema pendiente: qué falta o qué no está claro.
Evidencia: cómo puedo demostrar que el control existe o funciona.
Siguiente acción: qué haría primero para mejorar.

No hace falta hacerlo perfecto el primer día.

De hecho, es mejor empezar simple y mantenerlo vivo que crear un documento enorme que nadie vuelve a abrir.

Conclusión

La gestión de riesgos TIC no debería empezar por cumplir un expediente.

Debería empezar por entender la tecnología que tenemos entre manos.

Qué sostiene el servicio. Qué puede fallar. Qué impacto tendría. Qué controles existen. Qué depende de proveedores. Qué podemos recuperar. Qué podemos demostrar. Y qué decisiones estamos tomando sin darnos cuenta.

Después vendrán el Excel, la matriz, el informe, la auditoría o el marco normativo que toque.

Pero si no entendemos la realidad técnica, todo lo demás se queda cojo.

Para mí, gestionar riesgos TIC no va de meter miedo ni de llenar documentos. Va de trabajar con más cabeza.

Probar. Entender. Documentar. Aplicar criterio.

Y, sobre todo, no esperar a que algo falle para descubrir que no lo teníamos tan controlado como pensábamos.