Blog

Inventario de activos de TI en ISO 27001: plantilla Excel

Karol Barański • 29 de agosto de 2026 • 20 min de lectura
ISO 27001inventario de activosciberseguridadgestión de ITRGPD

Pregunta a un administrador cuántos servidores tiene la empresa y responderá en segundos. Pregúntale en cuántos sitios están los datos personales de los clientes, quién aprueba el acceso a cada uno y qué pasa si mañana por la mañana uno de ellos no está disponible. Silencio, y después: «tengo que mirarlo».

La falta de esa información provoca retrasos al analizar vulnerabilidades, sustituir a un administrador clave, responder cuestionarios de seguridad, contratar un ciberseguro y gestionar incidentes.

Un inventario de activos bien mantenido ayuda a responder esas preguntas. Muchas empresas lo asocian con una lista de hardware preparada para una auditoría, aunque su utilidad es mucho mayor. Este artículo explica qué son los activos según ISO 27001, repasa siete malentendidos frecuentes y muestra cómo mantener el inventario incluso sin planes de certificación. Incluye una plantilla de Excel con 90 entradas de ejemplo de una empresa ficticia que utiliza sala de servidores propia, AWS, Azure, Google Cloud, contenedores en OVHcloud y una docena de servicios SaaS.

Qué es un activo en ISO 27001

En la norma ISO/IEC 27001:2022 el control clave es el A.5.9 del Anexo A, y su nombre importa: inventario de información y otros activos asociados. No es un cambio cosmético. En la versión de 2013 el control se llamaba simplemente «inventario de activos» y durante una década produjo listas de hardware. El nuevo título subraya que la información es un activo primario, mientras que los sistemas, el hardware, las personas, los servicios y la infraestructura de soporte son activos asociados que permiten tratarla. La enmienda climática ISO/IEC 27001:2022/Amd 1:2024 no modificó el control A.5.9.

La diferencia es práctica, no filosófica. El hardware o un sistema a menudo se pueden reconstruir o sustituir. Una base de clientes perdida, la documentación técnica o el histórico de contratos con un proveedor no se compran en una tienda.

El inventario debe abarcar la información y los activos asociados que permiten crearla, almacenarla, procesarla, transmitirla y protegerla:

  • información: bases de datos, documentación técnica, datos de personal, archivo de contratos, también en papel,
  • software y servicios: aplicaciones, ERP, servicios SaaS, contenedores, pipelines de CI/CD,
  • hardware: servidores, cabinas, portátiles, teléfonos, terminales de almacén, autómatas PLC,
  • infraestructura de soporte: alimentación, climatización de la sala de servidores, enlaces de telecomunicaciones, control de acceso,
  • identidad y acceso: el tenant de Entra ID, cuentas de servicio, claves de API, certificados, dominios,
  • servicios externos y dependencias de proveedores: porque forman parte de tu cadena de tratamiento de la información.

El inventario es además la base de varios controles más del Anexo A: A.5.10 (uso aceptable), A.5.11 (devolución de activos al terminar la relación laboral), A.5.12 y A.5.13 (clasificación y etiquetado de la información) y A.5.19-A.5.22 (relaciones con proveedores). Ninguno se puede implantar con sentido si no se sabe qué se devuelve, qué se clasifica y a quién se le encarga.

Siete malentendidos que arruinan los inventarios

1. «Es el registro de inmovilizado»

Un error frecuente es el siguiente: TI recibe de contabilidad el fichero del inmovilizado e intenta convertirlo en un inventario de seguridad.

Son dos documentos distintos con dos objetivos distintos. A contabilidad le interesa el valor y la amortización. A seguridad le interesa el riesgo. El resultado es que en el inmovilizado faltan los activos más importantes: una suscripción de CRM de 200 € al mes no es inmovilizado y contiene toda la base de clientes. Un portátil de hace cinco años tiene valor contable cero y el disco lleno de ofertas. Un dominio cuesta 20 € al año y perderlo tumba a la vez el correo y el portal de pedidos.

Y al revés: el inmovilizado contiene muchas partidas sin relevancia para la seguridad, como mobiliario, carretillas o aire acondicionado de oficina.

2. «Tenemos monitorización y un escáner de red, así que tenemos inventario»

Zabbix, un barrido de nmap, la consola de Intune y la lista de recursos de AWS son fuentes del inventario, no el inventario. La automatización responde a «qué está funcionando». No responde a ninguna de las preguntas para las que existe el inventario:

  • quién, en el negocio, decide el acceso a este sistema,
  • qué clase de información pasa por él,
  • cuántas horas de parada aguanta el proceso que depende de él,
  • si existe copia de seguridad y si alguien la ha restaurado alguna vez,
  • qué deja de funcionar si lo apagamos.

El descubrimiento automático es un complemento excelente y detecta lo que el inventario desconoce. Pero el contexto de negocio lo escribe una persona una vez, y después solo se mantiene.

3. «Tiene que estar completo hasta la última unidad»

Esta creencia ha matado más inventarios que la falta de tiempo. El equipo empieza anotando 140 portátiles por número de serie, tres semanas después nadie recuerda para qué, el fichero acaba en un recurso compartido y no se vuelve a abrir.

El nivel de detalle lo marca el riesgo, no la ambición. Regla práctica: tiene fila propia lo que tiene propietario propio, riesgo propio o contrato propio.

  • 142 portátiles idénticos con la misma política en Intune pueden ser una sola fila resumen si el MDM sigue siendo la fuente de verdad detallada y permite identificar cada dispositivo, asignación, devolución y retirada.
  • Un bucket de S3 con documentación de clientes es una fila propia, aunque pese 200 MB.
  • Una estación SCADA que controla la línea de pintura es una fila propia, aunque físicamente sea un PC corriente.

El inventario debe tener el detalle suficiente para apoyar decisiones y conservar la trazabilidad necesaria.

4. «El propietario del activo es el informático»

Un inventario cuya columna «propietario» dice «Responsable de IT» en todas las filas no aporta ninguna información.

El control A.5.9 exige asignar un propietario al activo. Separar la responsabilidad de negocio de la administración técnica no es un modelo obligatorio impuesto por la norma, pero suele funcionar bien en la práctica:

  • propietario de negocio del activo: la persona responsable de cómo se utiliza la información y que aprueba los accesos. Para el sistema de RR. HH. es el responsable de personal; para el ERP, el director financiero; para los planos, el jefe de ingeniería. El propietario del riesgo es un papel distinto y no tiene por qué ser siempre la misma persona.
  • responsable técnico: quien lo administra a diario. Puede ser un administrador, un desarrollador o una empresa externa.

Esta separación tiene un efecto muy concreto. Cuando el propietario es el negocio, la pregunta «¿sigue necesitando Kowalski acceso a nóminas?» llega a quien conoce la respuesta. Cuando el propietario es TI, la respuesta es «déjalo, por si acaso».

5. «Está en la nube, así que es problema del proveedor»

El reparto de responsabilidades depende del servicio concreto y de si se utiliza IaaS, PaaS o SaaS. El proveedor suele proteger la infraestructura y los componentes de plataforma bajo su control, mientras que el cliente sigue respondiendo de aspectos como la configuración, las cuentas, los permisos, la clasificación de datos y la comprobación de que la retención y la recuperación cumplen los requisitos del negocio.

Consecuencias prácticas para el inventario:

  • un bucket accesible públicamente es tu incidente, no una caída del proveedor,
  • una cuenta de administrador del tenant sin MFA es tu riesgo,
  • hay que comparar las funciones de retención y recuperación de un SaaS con tus RPO, RTO y escenarios de borrado accidental o malicioso; si no bastan, hace falta una exportación o copia adicional,
  • la configuración de identidad, incluidos grupos, roles y políticas de acceso condicional, a menudo no está cubierta por un proceso completo de recuperación, por lo que el inventario debe indicar cómo se reconstruirá.

Sobre cómo prepararse para la indisponibilidad de un servicio en la nube, puedes leer Caída de un SaaS crítico: plan de continuidad de negocio.

6. «El inventario se hace para la auditoría»

Si el inventario solo se actualiza antes de una auditoría, durante la mayor parte del año no refleja el entorno real. En esas condiciones es difícil confiar en él durante un incidente.

Mantén el inventario para el trabajo diario, por ejemplo para comprobar si una vulnerabilidad nueva afecta a los sistemas utilizados. Un documento actualizado también aporta evidencias útiles durante una auditoría.

7. «La norma exige la metodología activo - amenaza - vulnerabilidad»

Es un vestigio de la edición de 2005 que sigue circulando en la formación. La versión de 2013 y la actual de 2022 no imponen una metodología de análisis de riesgos. El apartado 6.1.2 exige un proceso coherente y repetible con propietarios de riesgo, pero no exige partir de una lista de activos.

Las empresas que tratan el inventario únicamente como entrada para una hoja de riesgos suelen aplicar más detalle del necesario. El inventario también tiene valor operativo. El riesgo se puede evaluar por escenarios, por procesos o mediante un método mixto, siempre que el enfoque sea coherente y produzca resultados comparables.

Cómo es una entrada bien hecha

No necesitas treinta columnas para empezar. Necesitas nueve, rellenas con datos ciertos:

ColumnaQué anotar
IDIdentificador permanente, p. ej. AST-0042. No cambia aunque se renombre el equipo.
Nombre del activoEl nombre que se usa al hablar: hostname, nombre del servicio o del conjunto de datos.
TipoServidor, máquina virtual, contenedor, base de datos, SaaS, identidad, conjunto de datos.
Ubicación / proveedorDónde residen los datos: sala de servidores, región cloud, país del proveedor SaaS.
Propietario de negocioQuien aprueba los accesos y acepta el riesgo.
Responsable técnicoQuien lo administra a diario. Puede ser un proveedor.
Clasificación de la informaciónPública, interna, confidencial, estrictamente confidencial.
CriticidadImpacto en el negocio si no está disponible.
Última revisiónFecha en que el propietario confirmó la entrada.

Los demás campos, como RTO, RPO, copia de seguridad, monitorización, control de acceso, fin de soporte, coste anual y dependencias, son útiles, pero no tienen que estar completos el primer día. Es mejor empezar con nueve columnas fiables que mantener una hoja extensa con datos dudosos.

Tres entradas de ejemplo, una de cada mundo:

Servidor físico. AST-0001 · ESXI-HQ-01 · servidor físico · on-premises, sala de servidores HQ · Dell PowerEdge R650, ESXi 8.0 U3 · propietario: Responsable de IT · clasificación: interna · criticidad: crítica · RTO 4 h / RPO 24 h · soporte hasta 2028-06-30.

Recurso cloud. AST-0045 · S3 nordvent-backup-vault · almacenamiento de datos · AWS eu-central-1 · Object Lock, 9 TB · propietario: Responsable de IT · clasificación: estrictamente confidencial · datos personales: sí - clientes · criticidad: crítica · ESTA es la copia, retención 365 días.

Servicio SaaS. AST-0071 · HubSpot CRM Professional · servicio SaaS · SaaS - EE. UU. (CCT + DPF) · 24 puestos · propietario: Director Comercial · clasificación: confidencial · datos personales: sí - contactos comerciales · exportación diaria por API a S3 · renovación 2027-05-31.

Fíjate en los últimos campos. Son los que convierten una lista en una herramienta: se sabe qué es una copia, dónde están los datos personales y cuándo toca decidir sobre un contrato.

Convención de nombres e identificadores

Un detalle que decide si el inventario sobrevive:

  • El ID es permanente y no significa nada. AST-0042 acompaña al activo hasta el final, aunque el servidor cambie de nombre, de función y de ubicación. Los identificadores «con significado» (MAD-SRV-ERP-01) se rompen en la primera migración.
  • El nombre es el que usáis al hablar. Si todos dicen «el CRM viejo», que esté en el nombre. Un inventario cuyos nombres nadie reconoce no se abrirá durante un incidente.
  • Anota las dependencias por ID. Una columna «depende de» sustituye al diagrama que nadie va a actualizar.
  • No borres los activos retirados. Cambia el estado a «retirado» y deja la fecha. Mientras exista el disco, existe el activo; y el acta de borrado es la prueba de que el asunto está cerrado.

Los activos que más se olvidan

Esta lista sale de inventarios reales. Casi siempre falta algo de aquí:

  • dominios y certificados: quién paga la renovación, con qué tarjeta y qué pasa cuando esa persona se va,
  • el tenant de identidad: Entra ID o Google Workspace como activo propio, normalmente el más crítico de la empresa,
  • cuentas de servicio y claves de API: sin propietario, sin rotación, sobreviven a todos los empleados,
  • el servidor de copias: es un activo crítico y el primer objetivo de un ataque de ransomware,
  • la red OT y los PLC: fuera del radar de TI, pero paran la producción,
  • enlaces de telecomunicaciones, SAI y climatización: un fallo de refrigeración apaga la sala en menos de una hora,
  • la banca electrónica y los tokens: el mayor riesgo financiero de la empresa y rara vez está en el inventario de TI,
  • shadow IT pagado con tarjeta: herramientas compradas por marketing u operaciones sin pasar por TI,
  • el almacén de datos y los informes de BI: una copia de los datos de clientes vive ahí en paralelo al sistema origen,
  • repositorios de código y runners de CI/CD: tienen tokens de despliegue a producción, así que son producción,
  • documentos en papel: archivo de contratos, expedientes de personal, el sobre con contraseñas de emergencia,
  • el conocimiento de personas concretas: no cabe en una hoja, pero una columna «responsable técnico» con un solo nombre en cuarenta filas lo dice todo.

Cuánto detalle en la nube y en contenedores

La pregunta más habitual del primer intento es si hay que anotar cada instancia y cada contenedor. No siempre. La granularidad debe responder a las necesidades de la organización, al riesgo, al estado almacenado, a la propiedad y a los límites contractuales.

AWS y Azure. Anota la cuenta o la suscripción como activo propio: forman fronteras importantes de facturación, administración y riesgo. Por debajo, anota los servicios con estado, datos o requisitos de seguridad diferenciados: la base RDS, los buckets relevantes, el clúster de ECS o AKS, el almacén de copias, el key vault o un punto de entrada como CloudFront o un balanceador. Esto no significa que cada bucket necesite una fila; ajusta el detalle al objetivo del inventario. Las tareas, los pods y los objetos reproducibles normalmente no necesitan filas propias.

Google Cloud. Anota el proyecto y después los conjuntos de BigQuery y buckets relevantes. Presta atención especial a las cuentas de servicio. Evita las claves JSON de larga duración cuando puedas usar identidades asociadas, suplantación o Workload Identity Federation. Si una clave es imprescindible, asígnale propietario, minimiza sus permisos, monitoriza su uso y rótala periódicamente.

Servidores dedicados y contenedores, p. ej. en OVHcloud. Anota el host como activo y cada servicio de producción como fila propia que depende de ese host. Traefik, GitLab, Zabbix, el gestor de contraseñas y la base de datos que hay detrás son cinco riesgos distintos aunque estén en una sola máquina. No anotes contenedores auxiliares que se reconstruyen desde un fichero compose sin perder datos.

Merece la pena automatizar al menos parte de la alimentación, no para generar entradas, sino para detectar discrepancias:

# AWS: todos los recursos etiquetados de una región
aws resourcegroupstaggingapi get-resources --region eu-central-1

# Azure: recursos de una suscripción
az resource list --subscription sub-nordvent-prod --output table

# GCP: recursos de un proyecto
gcloud asset search-all-resources --scope=projects/nordvent-analytics-prod

# Todos los contenedores del host, incluidos los detenidos
docker ps -a --format json

Una vez al trimestre, compara el resultado con el inventario. La diferencia es o bien un activo nuevo del que nadie avisó, o bien un zombi que llevas pagando medio año.

Por qué llevarlo aunque no vayas a certificarte

La certificación no tiene que ser el motivo principal para mantener el inventario. En el trabajo diario resulta útil al menos en ocho áreas:

1. Tiempo de respuesta ante vulnerabilidades. Cuando aparece una vulnerabilidad similar a Log4Shell, la primera pregunta es «¿dónde usamos esto?». Un inventario actualizado acorta la búsqueda y reduce el riesgo de omitir un sistema.

2. Dinero. La columna de coste anual ayuda a encontrar licencias sin uso, suscripciones de proyectos terminados y entornos de pruebas olvidados. Estos ahorros dan a dirección una razón concreta para mantener el inventario.

3. Bajas de personal. La columna de control de acceso es una lista lista para usar de los sitios donde revocar el acceso a quien se marcha. Sin ella, la baja termina al desactivar la cuenta de dominio mientras el usuario del CRM y la clave SSH siguen vivos.

4. RGPD en la práctica. El artículo 30 exige, entre otras cosas, las categorías de destinatarios y, cuando proceda, las transferencias a terceros países. No exige expresamente una lista de ubicaciones de almacenamiento, pero es difícil completar esos campos con rigor sin mapear sistemas, proveedores y flujos de datos. Las columnas «datos personales» y «ubicación / proveedor» pueden alimentar el registro de actividades de tratamiento en lugar de reconstruirlo de memoria una vez al año.

5. NIS2. La gestión de activos sustenta los requisitos de gestión de riesgos. El Reglamento de Ejecución (UE) 2024/2690 de la Comisión exige a las categorías de entidades incluidas en su ámbito mantener un inventario completo, exacto, actualizado y coherente, además de conservar un historial trazable de los cambios. Una hoja de cálculo puede ser el punto de partida, pero en ese caso debe utilizarse en un entorno con versionado y pista de auditoría. Si aún estás comprobando si la normativa te afecta, empieza por la checklist de ciberseguridad NIS2 para empresas.

6. Continuidad de negocio. RTO y RPO sin lista de activos son una declaración, no un plan. No puedes prometer restaurar un proceso en cuatro horas si no sabes de cuántas piezas se compone.

7. Cuestionarios de clientes y ciberseguros. Los clientes y las aseguradoras preguntan a menudo cómo se inventarían los activos. Un inventario actualizado facilita preparar respuestas y evidencias sin volver a recopilar los datos.

8. Resistencia a que se vaya una persona. El inventario reduce la dependencia del conocimiento de un solo administrador y facilita que otra persona asuma sus funciones.

Cómo evitar que el inventario muera en un trimestre

Los inventarios no mueren por el formato. Mueren porque nadie responde de su exactitud y no hay un momento en el que nazca una entrada.

Nombra un propietario del inventario. Una persona, con nombre y apellidos. No «el departamento de TI».

Define los puntos de entrada. Una entrada nueva se crea automáticamente al: comprar hardware o una licencia, levantar un entorno, firmar un contrato con un proveedor, arrancar un proyecto, poner en marcha una integración. Si las entradas aparecen solo cuando alguien se acuerda, el inventario está muerto al primer mes.

Pon la revisión en el calendario. Una vez al trimestre los propietarios de negocio confirman sus filas: suelen ser 20 minutos por persona. La columna «última revisión» te dice a quién recordárselo.

Concilia con las fuentes automáticas. Cada trimestre compara el inventario con Intune, Zabbix y las consolas cloud. Las discrepancias son la parte más interesante del ejercicio.

Enlaza el inventario con las solicitudes de acceso. Si la solicitud exige indicar el ID del activo, el inventario se actualiza solo, porque sin entrada no se puede avanzar en el proceso.

Cuándo Excel deja de bastar

Una hoja de cálculo puede seguir siendo adecuada con varios cientos de entradas si tiene un propietario y un proceso de edición controlado. Las señales siguientes ayudan a decidir cuándo conviene valorar otra herramienta:

  • lo editan en paralelo más de tres personas y se pierden cambios,
  • necesitáis histórico de cambios: quién cambió el propietario, cuándo y por qué,
  • queréis alimentarlo automáticamente desde la nube y el MDM en lugar de copiar a mano,
  • el inventario debe enlazar con tickets, cambios e incidentes.

Entonces tienen sentido Snipe-IT o GLPI para hardware y licencias, NetBox para infraestructura de red, o el módulo CMDB del sistema de tickets que ya usáis. Migrar desde una hoja bien llevada es sencillo, porque el modelo de datos ya existe.

La plantilla

El fichero siguiente contiene un ejemplo completo y relleno.

Descargar la plantilla de inventario de activos de TI - XLSX, 90 entradas

Dentro hay cinco hojas:

  • Registro de activos: 24 columnas y 90 filas completas. Las nueve columnas básicas están marcadas por color, las listas desplegables mantienen la coherencia de los valores y el formato condicional resalta solo los activos críticos, la falta de copia, el acceso sin MFA, el soporte vencido y las revisiones fuera de plazo.
  • Proveedores: 22 proveedores con ubicación de los datos, contrato de encargo, modelo de responsabilidad, SLA, fecha de renovación y plan de salida.
  • Resumen: se calcula solo. Recuentos por criticidad, proveedor, tipo, entorno, clasificación y estado, y debajo nueve controles de calidad: activos sin propietario, revisiones vencidas, activos críticos sin copia, soporte caducado, acceso sin MFA, datos personales fuera de la UE.
  • Instrucciones: por dónde empezar, descripción de cada columna y reglas para elegir el nivel de detalle.
  • Listas: los valores de los desplegables, listos para adaptar a tu empresa.

Los datos pertenecen a una empresa ficticia, Nordvent Systems Sp. z o.o.: fabricante de sistemas de ventilación con 186 empleados, sede en Varsovia con sala de servidores propia, planta de producción en Płock con red OT, portal de pedidos B2B en AWS, Microsoft 365 y Azure, almacén de datos en Google Cloud, herramientas internas en contenedores sobre servidores dedicados de OVHcloud y una docena de servicios SaaS.

Los datos incluyen de forma intencionada problemas habituales en entornos que han crecido durante años: un servidor fuera de soporte, Ubuntu 20.04 en una máquina de reserva, una cuenta compartida con la agencia de marketing, un tenant de identidad sin copia de la configuración y un servidor del CRM antiguo apagado cuyo disco todavía contiene datos de clientes. La plantilla muestra tanto la estructura del inventario como ejemplos de hallazgos que requieren actuación.

Puedes usar, copiar y modificar el archivo sin restricciones, también con fines comerciales. Si lo compartes o escribes sobre él, mantén el enlace a este artículo.

Los primeros 30 días

No empieces por todo a la vez.

Semana 1. Enumera los procesos de negocio que generan ingresos o vienen impuestos por la ley: suelen ser entre cinco y ocho. Para cada uno, anota los sistemas sin los que se detiene.

Semana 2. Rellena las nueve columnas básicas para esos sistemas. No bajes por debajo del nivel de servicio. En cada fila fija el nombre del propietario de negocio y confírmalo con esa persona.

Semana 3. Añade identidades, proveedores, dominios, certificados y copias de seguridad. Es la capa que más se olvida y la que antes deja al descubierto las brechas.

Semana 4. Abre la hoja «Resumen», lee los controles de calidad y conviértelos en una lista de tareas con fechas. Pon la revisión trimestral en el calendario y designa al propietario del inventario.

Al cabo de un mes tienes un inventario que de verdad acorta el tiempo de respuesta. Ampliarlo con RTO, RPO y costes es entonces un paso natural, no un requisito previo.

Conclusión

El inventario de activos no es un documento para el auditor ni una lista de hardware. Es la respuesta a de qué se compone la empresa en su capa de información y quién responde de cada parte.

El A.5.9 es un control de referencia del Anexo A. La organización determina si es necesario mediante el tratamiento de riesgos y justifica su inclusión o exclusión en la Declaración de Aplicabilidad. Sin embargo, en la mayoría de los sistemas de gestión de seguridad de la información sería difícil justificar la ausencia de un inventario fiable. Un inventario actualizado ayuda a evaluar el impacto de las vulnerabilidades, controlar costes y reducir la dependencia del conocimiento individual, con independencia de los planes de certificación.

Empieza con nueve columnas y unos pocos procesos críticos. Añade más campos cuando exista una necesidad concreta y alguien se responsabilice de mantenerlos actualizados.

Si quieres inventariar tu entorno, ordenar propietarios y accesos o conectar el inventario con la monitorización, las copias y el plan de continuidad, consulta el servicio Socio IT. Podemos hacer el inventario y dejarte un registro que sí se pueda mantener.