Activos TIC: el inventario que sí sirve para algo

En tecnología hay una frase que parece muy sencilla, pero que muchas veces se complica más de lo que debería:

No puedes proteger ni gestionar bien lo que no sabes que tienes.

Y esto, llevado al día a día, significa una cosa muy concreta: antes de hablar de riesgos, controles, DORA, continuidad, proveedores o auditorías, conviene tener claro qué activos TIC sostienen realmente el servicio.

No hablo de hacer un inventario enorme para dejarlo olvidado en una carpeta.

Hablo de saber qué tienes, para qué sirve, quién lo usa, de qué depende, quién lo mantiene, qué proveedor hay detrás y qué pasa si falla.

Eso es lo importante.

Un inventario no debería ser una lista muerta

Durante mucho tiempo, cuando se hablaba de inventario TIC, mucha gente pensaba en un listado de equipos: servidores, portátiles, impresoras, switches, firewalls, licencias y poco más.

Eso puede ser útil, claro. Pero se queda corto.

Hoy un activo TIC puede ser muchas cosas:

un servidor físico,
una máquina virtual,
un contenedor Docker,
una base de datos,
una aplicación interna,
un servicio SaaS,
una integración entre sistemas,
una cuenta de administrador,
un certificado digital,
una VPN,
una copia de seguridad,
una herramienta de monitorización,
un proveedor tecnológico,
un procedimiento técnico,
o incluso una automatización que nadie mira hasta que deja de funcionar.

El problema no es tener muchos activos. Eso es normal.

El problema es no saber cuáles son importantes, cuáles son críticos, cuáles dependen de otros y cuáles están funcionando “porque siempre han funcionado”.

Ahí empiezan los sustos.

El inventario útil responde preguntas

Para mí, un inventario TIC tiene sentido si ayuda a responder preguntas prácticas.

No debería ser solo una tabla con nombre, IP y sistema operativo.

Debería ayudar a entender cosas como:

qué servicio presta ese activo,
qué proceso depende de él,
quién lo usa,
quién lo administra,
qué datos trata,
qué proveedor interviene,
qué impacto tendría una caída,
cómo se recupera,
si tiene copia de seguridad,
si está monitorizado,
si está documentado,
y si alguien lo revisa de vez en cuando.

Cuando un inventario responde a estas preguntas, deja de ser burocracia.

Se convierte en una herramienta para trabajar mejor.

La diferencia entre “tenerlo apuntado” y entenderlo

Hay una diferencia enorme entre tener algo apuntado y entenderlo de verdad.

Por ejemplo, puedes tener en una tabla:

Servidor: SRV-APP-01
IP: 192.168.1.50
Sistema operativo: Linux
Responsable: TI

Eso está bien, pero no cuenta casi nada.

Lo que realmente importa es saber:

qué aplicación corre ahí,
si esa aplicación es crítica,
qué usuarios la necesitan,
qué base de datos utiliza,
si depende de otro servidor,
si tiene backup,
si se puede restaurar,
cuánto tiempo se puede permitir estar parada,
y qué proveedor habría que llamar si algo falla.

Ese segundo inventario es el que sirve.

El primero te dice que algo existe. El segundo te ayuda a gestionarlo.

Activos visibles y activos invisibles

En cualquier entorno hay activos muy visibles.

El firewall, el NAS, el servidor principal, el sistema de correo, el ERP, la web, la VPN, la herramienta de copias.

Pero también hay activos menos visibles que suelen dar problemas precisamente por eso:

scripts antiguos,
tareas programadas,
integraciones entre aplicaciones,
cuentas técnicas,
certificados que caducan,
conectores con proveedores,
plantillas de configuración,
reglas de firewall heredadas,
automatizaciones que nadie recuerda,
o pequeñas bases de datos que sostienen un proceso concreto.

Muchas veces el riesgo no está en lo grande, sino en lo olvidado.

Ese servidor que nadie toca. Esa cuenta que sigue activa. Ese certificado que caduca un domingo. Ese script que hacía “una tontería” pero resulta que movía información importante. Esa integración que nadie documentó porque era algo provisional.

Lo provisional, en tecnología, tiene una facilidad enorme para quedarse.

El homelab también enseña esto

En un homelab se aprende rápido la importancia del inventario.

Empiezas montando un servicio para probar. Luego otro. Luego un contenedor. Luego una VPN. Luego monitorización. Luego un proxy inverso. Luego copias. Luego una integración con Home Assistant. Luego un modelo local de IA. Luego algo que depende de otra cosa.

Y un día te preguntas:

¿Dónde estaba configurado esto?

O peor:

¿Por qué ha dejado de funcionar esto si yo no he tocado nada?

Ahí descubres que el inventario no era una manía. Era una forma de no depender de tu memoria.

En casa puedes permitirte romper, investigar y volver atrás. En un entorno profesional, esa misma falta de claridad puede afectar a usuarios, procesos, datos, proveedores o continuidad.

Por eso me gusta usar el homelab como laboratorio. No solo para probar herramientas, sino para entrenar una forma de pensar: qué tengo, cómo se conecta, qué depende de qué, cómo lo recupero y qué pasa si falla.

Inventario y gestión de riesgos van juntos

Un inventario TIC no es gestión de riesgos por sí solo, pero sin inventario la gestión de riesgos se queda coja.

Porque para valorar riesgos necesitas saber primero sobre qué estás hablando.

No es lo mismo un servidor de pruebas que un servidor que sostiene un proceso crítico. No es lo mismo una herramienta interna sin datos sensibles que una aplicación que contiene información personal. No es lo mismo un proveedor accesorio que un proveedor sin el cual no puedes operar.

Por eso, antes de valorar impacto y probabilidad, hay que entender el activo.

Preguntas básicas:

¿Qué activo es?
¿Qué proceso soporta?
¿Qué datos trata?
¿Qué dependencia tiene?
¿Qué pasaría si falla?
¿Cuánto tiempo podemos estar sin él?
¿Cómo se recupera?
¿Quién decide qué hacer?

Sin esas respuestas, cualquier matriz de riesgos queda un poco en el aire.

DORA y la importancia de saber qué sostiene el servicio

En sectores regulados, DORA ha puesto mucho foco en la resiliencia operativa digital y en la gestión del riesgo TIC.

Pero si lo aterrizamos, la idea de fondo es sencilla: las organizaciones tienen que saber qué tecnología sostiene sus funciones, qué riesgos existen, qué proveedores participan y cómo se mantiene la capacidad de operar cuando algo falla.

Además, DORA da mucha importancia a los servicios prestados por terceros TIC. No basta con saber qué tienes dentro de casa; también hay que saber qué servicios tecnológicos dependen de proveedores, qué contratos existen, qué función soportan y qué impacto tendría una incidencia.

Esto encaja con algo muy práctico: el inventario no puede quedarse solo en “mis servidores”. Tiene que incluir también servicios externos, SaaS, integraciones, proveedores críticos y dependencias tecnológicas relevantes.

Dicho de forma sencilla:

Si algo sostiene el servicio, debería estar identificado.

Luego ya vendrán los niveles de criticidad, las matrices, los controles, las evidencias y los informes.

Pero el primer paso es saber qué piezas forman el puzzle.

Proveedores TIC: activos que no siempre parecen activos

Uno de los errores habituales es pensar que un activo TIC es solo algo que tienes instalado o comprado.

Pero un proveedor también puede ser una pieza crítica del servicio.

Por ejemplo:

un proveedor de hosting,
un SaaS de gestión,
un proveedor de correo,
un servicio de backup cloud,
una plataforma de firma electrónica,
un proveedor de ciberseguridad,
un mantenimiento externo,
una API de terceros,
o una herramienta de soporte remoto.

Puede que no tengas el servidor físicamente. Puede que ni siquiera administres la plataforma. Pero si ese servicio falla y afecta a tu operación, tienes que tenerlo en el mapa.

Externalizar no elimina la dependencia. La cambia de sitio.

Por eso, para cada proveedor TIC relevante conviene saber:

qué servicio presta,
qué proceso soporta,
qué datos trata,
qué nivel de servicio ofrece,
cómo comunica incidencias,
qué soporte tiene,
qué pasa si deja de prestar servicio,
y qué alternativa existe si el problema se alarga.

No hace falta tratar igual a todos los proveedores. Pero sí distinguir cuáles son críticos y cuáles no.

Criticidad: no todo importa igual

Otro punto importante: no todos los activos tienen la misma importancia.

Esto parece evidente, pero a veces los inventarios no lo reflejan bien.

Hay activos que son críticos porque sin ellos no se puede operar. Otros son importantes, pero pueden esperar unas horas. Otros son útiles, pero no comprometen el servicio si caen. Y otros quizá están ahí por herencia, sin que nadie tenga claro si siguen aportando algo.

Clasificar la criticidad ayuda a priorizar.

Una forma sencilla de hacerlo es pensar en cuatro niveles:

Crítico: si falla, afecta de forma importante al servicio, a los clientes, a la operación o al cumplimiento.
Alto: si falla, genera impacto relevante, pero puede existir alguna alternativa temporal.
Medio: afecta al trabajo, pero no paraliza procesos críticos.
Bajo: impacto limitado o fácilmente asumible.

Lo importante no es discutir eternamente si algo es “alto” o “medio”.

Lo importante es que la clasificación ayude a tomar decisiones: qué se protege primero, qué se monitoriza, qué se copia, qué se prueba, qué proveedor se revisa con más detalle y qué plan de recuperación necesita más atención.

Dependencias: el mapa que casi nunca está completo

Un activo rara vez funciona solo.

Una aplicación puede depender de una base de datos, de un servidor, de una API, de un certificado, de una regla de firewall, de un proveedor externo, de una cuenta técnica y de una tarea programada.

Si solo miras la aplicación, te pierdes medio problema.

Las dependencias son importantes porque muchas incidencias no nacen donde se ven.

Un servicio puede caerse porque ha caducado un certificado. Una integración puede fallar porque cambió una credencial. Una aplicación puede dejar de funcionar porque el proveedor externo modificó una API. Un backup puede no servir porque nadie incluyó una carpeta crítica. Una alerta puede no llegar porque cambió una configuración de correo.

Por eso, un inventario útil debería reflejar al menos las dependencias más importantes.

No hace falta hacer un mapa perfecto de todo. Pero sí identificar las piezas sin las cuales un servicio crítico no funciona.

Datos: no todos los activos tienen el mismo riesgo

Para entender un activo, también hay que saber qué datos trata.

No es lo mismo un servidor sin información sensible que una base de datos con datos personales. No es lo mismo una herramienta interna sin impacto externo que una plataforma que gestiona información de clientes, empleados, proveedores o usuarios.

Al inventariar activos conviene añadir una visión mínima sobre los datos:

si trata datos personales,
si contiene información confidencial,
si maneja credenciales o secretos,
si almacena documentación crítica,
si intercambia datos con terceros,
si tiene requisitos de conservación,
y si necesita medidas adicionales de protección.

Esto ayuda a priorizar controles.

Un activo puede no ser crítico por disponibilidad, pero sí ser importante por confidencialidad. Y al revés: puede no contener datos sensibles, pero ser clave para operar.

La criticidad no tiene una sola dimensión.

Inventario mínimo: qué campos pondría yo

Si tuviera que empezar un inventario TIC útil desde cero, no empezaría con cincuenta columnas.

Empezaría con pocas, pero buenas:

Nombre del activo: cómo lo identificamos.
Tipo: servidor, aplicación, base de datos, proveedor, SaaS, red, backup, integración, etc.
Función: para qué sirve.
Proceso asociado: qué proceso de negocio o de soporte depende de él.
Responsable: quién lo conoce o lo mantiene.
Proveedor: si hay un tercero implicado.
Datos tratados: si hay datos personales, confidenciales o críticos.
Criticidad: crítica, alta, media o baja.
Dependencias: de qué otros sistemas o servicios depende.
Backup: si se copia y cómo.
Monitorización: si hay alertas o seguimiento.
Recuperación: cómo se restauraría o sustituiría.
Documentación: dónde está explicado.
Última revisión: cuándo se revisó por última vez.
Observaciones: dudas, carencias o próximos pasos.

Con eso ya puedes empezar a trabajar.

Luego se puede sofisticar. Pero al principio prefiero un inventario sencillo que se mantenga vivo a una herramienta enorme que nadie actualiza.

Ejemplo práctico: una VPN

Pensemos en una VPN.

En un inventario pobre pondríamos:

Activo: VPN
Tipo: acceso remoto
Estado: activa

Pero eso dice poco.

Un inventario útil debería añadir:

qué usuarios acceden,
desde qué dispositivos,
a qué redes o servicios llegan,
qué autenticación se usa,
cómo se revoca un acceso,
qué logs quedan,
quién revisa los permisos,
qué pasaría si se compromete una credencial,
y si hay documentación para recuperarla o migrarla.

La VPN no es solo una herramienta técnica. Es una puerta de entrada.

Y las puertas de entrada hay que tenerlas bastante claras.

Ejemplo práctico: una herramienta de backup

Ahora pensemos en una herramienta de copias.

No basta con poner “backup: sí”.

Hay que saber:

qué sistemas copia,
qué sistemas no copia,
dónde guarda las copias,
qué retención tiene,
quién puede restaurar,
si las copias están protegidas,
cuándo se hizo la última prueba,
qué resultado tuvo,
y cuánto se tardaría en recuperar un servicio importante.

Un inventario así no es solo inventario.

Es una base para continuidad.

Ejemplo práctico: un proveedor SaaS

Un proveedor SaaS también debería estar inventariado si sostiene un proceso relevante.

No vale con decir “lo lleva el proveedor”.

Conviene saber:

qué servicio presta,
quién lo usa,
qué datos se suben,
qué contrato existe,
qué soporte ofrece,
qué pasa si hay una caída,
cómo se exportan los datos,
si hay dependencia fuerte del proveedor,
y qué alternativa habría si hubiera que cambiar.

Muchas dependencias críticas hoy no están en un servidor propio. Están en servicios externos.

Por eso el inventario TIC tiene que mirar dentro y fuera.

El inventario también ayuda a limpiar

Un buen inventario no solo sirve para proteger. También sirve para limpiar.

Cuando revisas activos, aparecen cosas interesantes:

servicios que ya no se usan,
usuarios que deberían estar desactivados,
máquinas antiguas sin responsable claro,
proveedores duplicados,
licencias innecesarias,
automatizaciones que nadie entiende,
documentación desactualizada,
y sistemas que convendría retirar antes de que den problemas.

Esto también es gestionar riesgo.

A veces la mejor mejora de seguridad no es instalar una herramienta nueva, sino apagar lo que ya no hace falta.

Cómo mantenerlo vivo

El gran problema de los inventarios no es crearlos. Es mantenerlos.

Un inventario puede nacer muy bien y estar desactualizado en tres meses si nadie lo incorpora al trabajo diario.

Para que sirva, debería conectarse con hábitos sencillos:

cuando se crea un sistema, se añade al inventario,
cuando se retira, se marca como retirado,
cuando se cambia un proveedor, se actualiza,
cuando se modifica una integración, se revisan dependencias,
cuando se hace una prueba de restauración, se anota,
cuando hay una incidencia, se revisa si el activo estaba bien identificado,
y cada cierto tiempo se hace una revisión rápida de los activos críticos.

No hace falta convertirlo en una ceremonia enorme.

Hace falta que no dependa únicamente de “ya me acordaré”.

Y aquí conviene no complicarse demasiado con la herramienta.

Para empezar, no hace falta una gran plataforma GRC.

Puede ser una hoja de cálculo bien pensada, una base de datos sencilla, una wiki interna, una herramienta de documentación o un sistema de inventario más avanzado si ya existe.

La herramienta importa, pero no es lo primero.

Lo primero es tener claro qué información necesitas y cómo la vas a mantener.

He visto herramientas muy potentes mal alimentadas y hojas sencillas que daban mucho más valor porque estaban actualizadas y las entendía todo el equipo.

La herramienta perfecta no arregla un inventario que nadie mantiene.

Señales de que el inventario no está funcionando

Hay señales bastante claras de que el inventario no está sirviendo:

nadie lo consulta,
nadie sabe quién lo actualiza,
no aparecen proveedores importantes,
hay sistemas críticos sin responsable,
no se reflejan dependencias,
no se sabe qué activos tienen backup,
no hay fecha de última revisión,
y en una incidencia nadie mira el inventario porque no se fía de él.

Cuando pasa eso, el inventario se convierte en decoración.

Y la decoración no ayuda cuando algo falla.

Una forma sencilla de empezar

Si hoy tuviera que empezar desde cero, haría algo muy simple.

Primero, identificaría los servicios que de verdad importan.

No todos. Los importantes.

Después, para cada uno, respondería estas preguntas:

¿Qué proceso soporta?
¿Qué activos lo componen?
¿Qué proveedor interviene?
¿Qué datos trata?
¿Qué pasa si se cae?
¿Cómo me entero?
¿Cómo lo recupero?
¿Quién sabe tocarlo?
¿Dónde está documentado?
¿Cuándo se revisó por última vez?

Con eso ya aparece mucho.

Luego puedes ir completando, ordenando y mejorando.

Pero el primer salto no es tenerlo perfecto. Es dejar de trabajar a ciegas.

Conclusión

Un inventario TIC útil no es un listado para cumplir.

Es una forma de entender la tecnología que sostiene el servicio.

Qué tienes. Para qué sirve. Quién lo usa. Qué datos trata. De qué depende. Quién lo mantiene. Qué proveedor hay detrás. Qué impacto tendría una caída. Cómo se recupera. Y qué habría que revisar antes de que sea un problema.

Cuando el inventario se hace así, deja de ser burocracia.

Se convierte en una herramienta para gestionar mejor, priorizar mejor y tomar decisiones con más criterio.

No hace falta empezar con una solución perfecta.

Hace falta empezar con una pregunta sencilla:

¿Sabemos realmente qué sostiene nuestro servicio?

Si la respuesta no está clara, ahí ya tenemos el primer trabajo.