Cómo auditar una infraestructura informática existente

Introducción

Auditar una infraestructura informática existente significa reconstruir una visión fiable de cómo funciona realmente, comprobar su estado técnico y convertir los problemas encontrados en un plan de actuación priorizado. No consiste en recorrer una lista genérica de controles ni en buscar fallos para justificar una renovación completa.

En muchas pequeñas empresas la infraestructura ha crecido por etapas. Un servidor se instaló para resolver una necesidad concreta, después se añadió un NAS, varias aplicaciones cloud, acceso remoto, máquinas virtuales, copias, scripts, cuentas de proveedores y equipos de distintas generaciones. Cada pieza puede seguir funcionando, pero nadie conserva una imagen completa y actualizada del conjunto.

La ausencia de esa visión complica cualquier decisión. No se sabe si un disco está cerca de su límite, qué aplicación depende de una versión sin soporte, quién administra una cuenta crítica, si las copias permiten reconstruir el servicio o qué consecuencias tendría actualizar un componente. La empresa trabaja sobre una infraestructura que conoce de forma parcial.

Una auditoría técnica debe empezar por observar y recopilar evidencias, no por modificar. Primero se define el alcance, se protege la operativa, se inventarían activos y dependencias, se revisan configuraciones y se validan procedimientos. Después se clasifican los hallazgos por impacto, urgencia y esfuerzo.

Este artículo propone una metodología práctica para profesionales, microempresas, PYMES y organizaciones de formación online. El objetivo es revisar una infraestructura ya implantada con profundidad suficiente para detectar riesgos, obsolescencia, saturación, desorden y oportunidades de mejora, sin convertir la auditoría en una intervención destructiva ni en un documento que nadie utilizará.

Índice

• Qué es una auditoría de infraestructura informática
• Diferencia frente a otras auditorías tecnológicas
• Objetivos y resultados esperados
• Principios para auditar sin causar incidencias
• Fase 0. Preparación y alcance
• Fase 1. Recogida de evidencias
• Fase 2. Inventario técnico real
• Fase 3. Mapa de dependencias
• Auditoría de hardware y ciclo de vida
• Auditoría de sistemas operativos y servidores
• Auditoría de virtualización y contenedores
• Auditoría de red y conectividad
• Auditoría de almacenamiento
• Auditoría de aplicaciones y servicios
• Auditoría de identidades, permisos y cuentas
• Auditoría de datos y documentación
• Auditoría de copias y recuperación
• Auditoría técnica básica de seguridad
• Auditoría de monitorización y registros
• Auditoría de operación, soporte y cambios
• Auditoría de proveedores, licencias y contratos
• Auditoría de capacidad y rendimiento
• Pruebas técnicas recomendadas
• Cómo redactar y clasificar hallazgos
• Cómo priorizar correcciones
• Estructura del informe final
• Ejemplo aplicado a una microempresa
• Ejemplo aplicado a una empresa con LMS
• Cada cuánto conviene auditar
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué es una auditoría de infraestructura informática

Es una revisión estructurada del estado técnico, operativo y documental de los componentes que sostienen los servicios informáticos de una organización.

Debe permitir responder:

• qué activos existen;
• para qué se utilizan;
• dónde están ubicados;
• qué versiones y configuraciones mantienen;
• quién los administra;
• de qué otros elementos dependen;
• qué capacidad consumen;
• qué riesgos presentan;
• cómo se recuperan;
• qué debe corregirse primero.

La auditoría no termina al encontrar problemas. Su resultado útil es una imagen de situación verificable y una secuencia de correcciones compatible con la continuidad de la empresa.

El punto de partida debe ser la infraestructura real, no la documentación ideal. Si un servidor no aparece en el inventario, una cuenta depende de un antiguo proveedor o una copia se ejecuta mediante un script personal, la auditoría debe registrarlo tal como funciona hoy.

Auditar no es demostrar cómo debería ser la infraestructura, sino descubrir cómo es, qué riesgo contiene y cómo puede mejorar sin perder operativa.

Diferencia frente a otras auditorías tecnológicas

Auditoría de ecosistema digital

Analiza de forma amplia herramientas, cuentas, datos, procesos, proveedores y dependencias empresariales. El artículo cómo auditar ecosistemas digitales desarrolla esa visión transversal.

Auditoría de infraestructura informática

Profundiza en el estado técnico de equipos, servidores, red, almacenamiento, sistemas, virtualización, capacidad, copias y operación.

Auditoría de seguridad

Evalúa controles, exposición, vulnerabilidades y respuesta ante incidentes. Puede requerir pruebas especializadas y un alcance legal y técnico propio.

Auditoría de cumplimiento

Comprueba requisitos normativos, contractuales o sectoriales frente a criterios determinados.

Auditoría financiera de tecnología

Analiza costes, activos, licencias, amortización y compromisos.

Evaluación de madurez

Clasifica la capacidad de gobierno y evolución. Puede apoyarse en cómo medir la madurez tecnológica de una empresa.

Estas revisiones se complementan, pero no deben presentarse como equivalentes. Una auditoría técnica puede detectar un sistema sin soporte sin determinar por sí sola todas sus implicaciones regulatorias.

Objetivos y resultados esperados

• Construir un inventario técnico fiable.
• Identificar servicios críticos y dependencias.
• Detectar componentes sin soporte o próximos a retirada.
• Comprobar capacidad, saturación y crecimiento.
• Revisar configuraciones y responsabilidades.
• Validar copias y recuperación.
• Localizar puntos únicos de fallo.
• Detectar permisos excesivos o cuentas fuera de control.
• Encontrar herramientas duplicadas o sin uso.
• Revisar documentación y conocimiento operativo.
• Clasificar hallazgos por riesgo.
• Definir un plan de corrección por fases.

La auditoría no debe prometer ausencia total de fallos. Debe aumentar visibilidad, control y capacidad de decisión.

Principios para auditar sin causar incidencias

Observar antes de cambiar

La recogida inicial debe ser preferentemente de solo lectura. No se actualiza, reinicia ni reconfigura durante el diagnóstico salvo autorización y necesidad.

Proteger la producción

Las pruebas con carga, escaneos activos o restauraciones deben planificarse y, cuando sea posible, realizarse fuera del entorno productivo.

Registrar cada acceso

Debe saberse quién accedió, cuándo, con qué finalidad y qué información obtuvo.

Minimizar privilegios

La auditoría no necesita conservar cuentas administrativas permanentes. Los accesos temporales deben revocarse al finalizar.

No confiar en una única fuente

La documentación, las herramientas automáticas y las entrevistas pueden estar incompletas. Deben contrastarse.

Separar hallazgo de recomendación

Primero se describe el hecho y su evidencia; después se propone una medida.

Priorizar continuidad

Un problema grave no siempre debe corregirse inmediatamente si la intervención improvisada puede provocar una caída mayor. Puede ser necesario estabilizar y preparar vuelta atrás.

Fase 0. Preparación y alcance

Definir qué se incluye

• sedes y redes;
• puestos de trabajo;
• servidores físicos y virtuales;
• almacenamiento;
• servicios cloud;
• aplicaciones críticas;
• copias;
• cuentas e identidades;
• proveedores;
• documentación.

Definir exclusiones

Debe constar qué no se revisará: pruebas de penetración, código fuente, cumplimiento legal, dispositivos personales o sistemas de terceros sin autorización.

Nombrar interlocutores

Conviene contar con dirección, responsable técnico, usuarios clave y proveedores.

Acordar ventanas

Las pruebas que puedan consumir recursos deben tener horario, responsables y criterio de parada.

Preparar confidencialidad

La auditoría puede acceder a diagramas, configuraciones, contratos y registros sensibles. Deben definirse custodia, cifrado, retención y eliminación.

Establecer entregables

• inventario validado;
• mapa de dependencias;
• matriz de hallazgos;
• resumen ejecutivo;
• plan de actuación;
• anexos técnicos.

Fase 1. Recogida de evidencias

Las evidencias pueden proceder de:

• entrevistas;
• inventarios existentes;
• consolas de administración;
• comandos de sistema;
• configuraciones exportadas;
• monitorización;
• registros;
• facturas y contratos;
• diagramas;
• pruebas de restauración;
• observación de procesos;
• muestreo de equipos.

Calidad de evidencia

Puede clasificarse como:

• confirmada: comprobada directamente;
• documentada: respaldada por información actualizada;
• declarada: comunicada por una persona sin comprobación;
• inferida: deducida a partir de señales parciales;
• pendiente: no fue posible verificar.

Esta clasificación evita presentar suposiciones como hechos.

Fase 2. Inventario técnico real

El inventario debe registrar como mínimo:

• identificador;
• tipo de activo;
• función;
• ubicación física o lógica;
• propietario funcional;
• responsable técnico;
• fabricante o proveedor;
• modelo y versión;
• dirección o nombre técnico;
• criticidad;
• datos tratados;
• copias;
• dependencias;
• coste y renovación;
• estado de soporte;
• documentación asociada.

Una hoja de cálculo puede ser suficiente para una pequeña empresa si existe disciplina. Para profundizar puede revisarse cómo inventariar servidores, aplicaciones y servicios.

Descubrimiento automático

Las herramientas pueden detectar dispositivos y software, pero no conocen su función empresarial. El resultado debe validarse con responsables.

Activos invisibles

Deben buscarse scripts, tareas programadas, cuentas técnicas, certificados, dominios, túneles VPN, repositorios, hojas críticas y servicios gratuitos.

Fase 3. Mapa de dependencias

El inventario responde qué existe. El mapa responde qué ocurriría si algo falla.

Para cada servicio crítico conviene representar:

• usuarios;
• autenticación;
• red;
• servidor o plataforma;
• base de datos;
• almacenamiento;
• DNS y certificados;
• integraciones;
• copias;
• proveedores;
• personas clave.

Puntos únicos de fallo

Pueden ser técnicos, humanos, contractuales o documentales.

Dependencias circulares

Una copia puede depender del mismo directorio que debe restaurar, o una cuenta de recuperación del correo que se intenta recuperar.

Cadena de servicio

El mapa debe seguir procesos reales. La metodología de cómo mapear flujos empresariales digitales ayuda a conectar tecnología y operación.

Auditoría de hardware y ciclo de vida

Comprobar

• modelo y antigüedad;
• garantía y soporte;
• estado de discos;
• memoria instalada y utilizada;
• temperaturas;
• fuentes y baterías;
• redundancia;
• firmware;
• repuestos;
• capacidad de ampliación;
• protección eléctrica;
• ubicación y ventilación.

Señales de riesgo

• errores de disco;
• baterías agotadas;
• temperaturas sostenidas;
• equipos sin garantía que sostienen servicios críticos;
• componentes sin repuesto;
• servidores domésticos sin protección;
• etiquetado inexistente.

La antigüedad no es por sí sola un fallo. El hallazgo debe relacionar estado, soporte, criticidad y alternativa.

Auditoría de sistemas operativos y servidores

• versiones y ediciones;
• estado de soporte;
• actualizaciones pendientes;
• servicios activos;
• usuarios locales;
• tareas programadas;
• puertos expuestos;
• uso de CPU, memoria y disco;
• sincronización horaria;
• registros;
• agentes instalados;
• configuración de arranque;
• cifrado;
• procedimiento de reconstrucción.

Software no identificado

Cada proceso importante debe asociarse a una función. Los servicios desconocidos requieren investigación antes de eliminarlos.

Configuración manual

Debe registrarse qué partes no pueden reconstruirse mediante documentación, scripts o plantillas.

Reinicios pendientes

Pueden revelar actualizaciones incompletas y riesgo acumulado.

Auditoría de virtualización y contenedores

• hosts y versiones;
• máquinas virtuales e imágenes;
• asignación de CPU y memoria;
• almacenamiento;
• snapshots antiguos;
• redes virtuales;
• acceso administrativo;
• copias consistentes;
• licencias;
• plantillas;
• dependencia de un único host;
• procedimiento de recuperación.

Sobrealocación

Debe compararse la capacidad prometida con el consumo y los picos reales.

Contenedores

Conviene revisar imágenes, versiones, secretos, volúmenes persistentes, redes, reinicio y origen de la configuración.

Snapshots

No deben confundirse con copias de seguridad. Snapshots permanentes pueden consumir espacio y degradar rendimiento.

Auditoría de red y conectividad

• topología física y lógica;
• router, firewall, switches y puntos de acceso;
• firmware y soporte;
• VLAN y segmentación;
• direccionamiento;
• DHCP y DNS;
• Wi-Fi y redes invitadas;
• VPN y acceso remoto;
• puertos abiertos;
• reglas de firewall;
• ancho de banda y latencia;
• enlace alternativo;
• documentación de cableado;
• administración remota.

Pruebas

Puede medirse pérdida de paquetes, latencia, utilización, cobertura y conmutación del enlace, siempre con control sobre el impacto.

Riesgos frecuentes

Contraseñas por defecto, firmware antiguo, administración expuesta, red plana y dispositivos auxiliares sin aislamiento.

Auditoría de almacenamiento

• capacidad total, utilizada y crecimiento;
• tipo de discos y redundancia;
• estado físico;
• sistemas de archivos;
• cuotas;
• permisos;
• snapshots;
• replicación;
• cifrado;
• datos temporales;
• duplicidades;
• archivo histórico;
• rendimiento;
• procedimiento de ampliación.

Capacidad crítica

Debe estimarse cuándo se alcanzará el umbral operativo, no solo el cien por cien físico.

Redundancia frente a copia

RAID y replicación reducen algunos fallos, pero no protegen frente a borrado, corrupción o ransomware.

El dimensionamiento puede contrastarse con cómo dimensionar almacenamiento empresarial.

Auditoría de aplicaciones y servicios

• función y usuarios;
• versión;
• estado de soporte;
• licencia;
• base de datos;
• dependencias;
• integraciones;
• autenticación;
• registros;
• copias;
• exportación;
• responsable;
• entorno de pruebas;
• plan de retirada.

Software huérfano

Aplicaciones utilizadas sin responsable ni documentación deben clasificarse como riesgo aunque funcionen.

Solapamiento

Varias aplicaciones pueden realizar la misma función y fragmentar datos.

Integraciones

Deben revisarse cuentas técnicas, límites, reintentos, alertas e idempotencia.

Auditoría de identidades, permisos y cuentas

• directorio o fuentes de identidad;
• cuentas activas;
• usuarios inactivos;
• cuentas compartidas;
• administradores;
• grupos y roles;
• autenticación multifactor;
• recuperación;
• cuentas de servicio;
• tokens y claves;
• altas y bajas;
• revisión periódica;
• titularidad empresarial.

Prueba de baja

Puede seleccionarse una baja anterior y verificar si se revocaron cuentas, sesiones, dispositivos y accesos de terceros.

Privilegio mínimo

Los administradores deben justificarse. Una cuenta utilizada a diario no debería mantener privilegios innecesarios.

Auditoría de datos y documentación

• fuentes de verdad;
• ubicaciones;
• propietarios;
• clasificación;
• permisos;
• versionado;
• retención;
• duplicidades;
• exportación;
• calidad;
• formatos;
• documentación técnica;
• procedimientos operativos;
• historial de cambios.

El objetivo no es leer toda la información empresarial, sino comprobar cómo se gobierna y si puede recuperarse y utilizarse.

Documentación mínima

Debe existir suficiente información para comprender arquitectura, administración y recuperación. Puede ampliarse con cómo documentar una infraestructura tecnológica.

Auditoría de copias y recuperación

Revisar

• qué se copia;
• frecuencia;
• retención;
• destino;
• cifrado;
• inmutabilidad;
• alertas;
• responsable;
• dependencias;
• credenciales;
• pruebas;
• tiempo de recuperación;
• pérdida de datos aceptable.

Prueba de restauración

Debe elegirse una muestra representativa: archivo, base de datos, máquina virtual o aplicación. La prueba necesita criterio de éxito y debe evitar sobrescribir producción.

Copia fuera del entorno

La estrategia de copias 3-2-1 aporta una referencia, pero debe adaptarse a la criticidad.

Hallazgo crítico

Una copia que nunca se ha restaurado debe registrarse como no verificada, no como recuperación garantizada.

Auditoría técnica básica de seguridad

Esta revisión no sustituye una auditoría de ciberseguridad especializada. Puede comprobar controles básicos:

• actualizaciones;
• cifrado;
• firewall;
• antimalware cuando proceda;
• MFA;
• privilegios;
• exposición de servicios;
• firmware;
• gestión de secretos;
• registro de eventos;
• segmentación;
• copias aisladas;
• respuesta ante incidentes;
• retirada segura.

No realizar pruebas destructivas sin autorización

Explotación, fuerza bruta, phishing simulado y escaneos agresivos requieren alcance, autorización y profesionales adecuados.

Auditoría de monitorización y registros

• qué se monitoriza;
• umbrales;
• alertas;
• responsables;
• cobertura;
• retención de métricas;
• registro de errores;
• sincronización horaria;
• espacio de logs;
• protección de datos sensibles;
• pruebas de alerta;
• paneles utilizados.

Alerta sin respuesta

Una herramienta que envía mensajes a una cuenta que nadie revisa no constituye una capacidad operativa.

Cobertura

Debe comprobarse si se detectan caída, saturación, error de copia, certificado próximo a vencer y pérdida de conectividad.

Auditoría de operación, soporte y cambios

• canal de incidencias;
• prioridades;
• tiempo de respuesta;
• escalado;
• base de conocimiento;
• incidencias repetidas;
• mantenimiento;
• registro de cambios;
• pruebas;
• vuelta atrás;
• ventanas;
• comunicación a usuarios;
• revisión posterior.

Cambios invisibles

Si varias personas modifican configuraciones sin registro, resulta difícil atribuir una degradación y volver atrás.

Soporte informal

Mensajes directos y llamadas pueden ocultar volumen, causas y tiempos. La auditoría debe observar el proceso real.

Auditoría de proveedores, licencias y contratos

• servicio prestado;
• cuentas y titularidad;
• accesos;
• alcance de soporte;
• horarios;
• tiempos comprometidos;
• renovaciones;
• licencias;
• subencargados o dependencias;
• exportación;
• documentación entregable;
• plan de salida;
• coste;
• alternativas.

Control empresarial

La empresa debe conservar capacidad de administrar activos críticos aunque delegue el trabajo. Conviene aplicar los criterios de cómo evitar dependencia de proveedores.

Licencias infrautilizadas

Debe compararse lo contratado con usuarios y funciones reales.

Auditoría de capacidad y rendimiento

Debe analizarse un periodo representativo, no una captura aislada.

• CPU;
• memoria;
• IOPS y latencia de disco;
• espacio y crecimiento;
• red;
• sesiones;
• colas;
• tiempos de respuesta;
• ventanas de copia;
• picos;
• errores;
• licencias o límites de plataforma.

Cuello de botella

No debe suponerse. Puede parecer falta de CPU y deberse a almacenamiento, red, consultas o bloqueo externo.

Proyección

Debe estimarse cuándo se alcanzarán umbrales si continúa el crecimiento.

Pruebas técnicas recomendadas

Cada prueba debe registrar fecha, alcance, resultado, evidencia, impacto y acciones pendientes.

Cómo redactar y clasificar hallazgos

Un hallazgo útil contiene:

1. Identificador.
2. Título claro.
3. Situación observada.
4. Evidencia.
5. Activo afectado.
6. Impacto posible.
7. Probabilidad.
8. Criticidad.
9. Recomendación.
10. Esfuerzo estimado.
11. Responsable propuesto.
12. Dependencias y precauciones.

Ejemplo

Hallazgo: Copia de la base de datos no verificada
Evidencia: la tarea finaliza correctamente, pero no existe
registro de restauración durante los últimos 18 meses.
Impacto: pérdida prolongada del servicio y datos.
Prioridad: alta.
Recomendación: restaurar una copia en entorno aislado,
documentar el proceso y fijar prueba trimestral.

Debe evitarse lenguaje alarmista sin evidencia.

Cómo priorizar correcciones

Puede utilizarse una matriz con:

• impacto;
• probabilidad;
• exposición;
• criticidad del servicio;
• facilidad de detección;
• esfuerzo de corrección;
• dependencias;
• riesgo de la intervención.

Prioridad inmediata

Riesgos activos con capacidad de provocar pérdida o interrupción grave: discos con errores, copias inexistentes, cuentas comprometidas o exposición crítica.

Corto plazo

Problemas importantes que requieren preparación: fin de soporte, ausencia de restauración, saturación próxima o proveedor único.

Medio plazo

Estandarización, documentación, consolidación y mejora de monitorización.

Oportunidad

Optimizaciones que aportan eficiencia, pero no corrigen un riesgo urgente.

El plan debe distinguir “resolver el riesgo” de “crear la arquitectura definitiva”. A veces una medida temporal segura es el primer paso.

Estructura del informe final

1. Resumen ejecutivo.
2. Objetivo y alcance.
3. Limitaciones.
4. Metodología.
5. Descripción de la infraestructura.
6. Inventario y dependencias.
7. Hallazgos por área.
8. Riesgos críticos.
9. Plan inmediato.
10. Hoja de ruta de 3, 6 y 12 meses.
11. Costes o rangos.
12. Responsables.
13. Anexos técnicos.

Resumen ejecutivo

Debe expresar impacto empresarial sin ocultar precisión técnica.

Anexos

Comandos, configuraciones, capturas y listados extensos pertenecen al anexo, no al cuerpo principal.

Información sensible

El informe no debe incluir contraseñas ni secretos. Puede indicar dónde se custodian.

Ejemplo aplicado a una microempresa

Una empresa de seis personas utiliza cinco portátiles, un NAS, correo cloud, facturación, web y un servidor virtual administrado por un proveedor.

Hallazgos

• El dominio está a nombre del proveedor.
• Dos portátiles carecen de cifrado.
• El NAS tiene un disco con errores crecientes.
• Las copias del servidor virtual no se han restaurado.
• Una cuenta de antiguo empleado sigue activa.
• No existe documentación del túnel VPN.
• El almacenamiento alcanzará el umbral operativo en ocho meses.

Plan inmediato

1. Sustituir el disco y verificar la redundancia.
2. Revocar la cuenta antigua.
3. Recuperar titularidad del dominio.
4. Restaurar una copia en entorno aislado.

Plan a tres meses

1. Cifrar puestos.
2. Documentar VPN y servidores.
3. Crear inventario.
4. Definir renovación y capacidad.

La auditoría no recomienda reemplazar todo. Prioriza estabilizar y recuperar control.

Ejemplo aplicado a una empresa con LMS

La revisión debe seguir la cadena completa de venta y entrega:

1. dominio y DNS;
2. web y formularios;
3. pago;
4. facturación;
5. alta de alumno;
6. LMS;
7. contenidos;
8. correo;
9. soporte;
10. copias.

Comprobaciones específicas

• versiones de WordPress, tema, LMS y plugins;
• compatibilidad y soporte;
• entorno de pruebas;
• copias de base de datos y archivos;
• restauración;
• exportación de alumnos y matrículas;
• contenidos maestros fuera del LMS;
• integración de pago y alta;
• alertas de errores;
• permisos administrativos;
• rendimiento en picos;
• protección de datos;
• continuidad de comunicación.

Prueba decisiva

La empresa debe poder explicar cómo reconstruiría la plataforma y reanudaría el acceso a alumnos si falla el alojamiento principal.

Cada cuánto conviene auditar

• Revisión mensual: alertas, capacidad, copias y errores.
• Revisión trimestral: cuentas, licencias, cambios, accesos y soporte.
• Auditoría anual: alcance completo y hoja de ruta.
• Auditoría extraordinaria: tras incidente, migración, crecimiento, cambio de proveedor o adquisición.

La frecuencia debe aumentar para sistemas críticos o entornos con cambios frecuentes.

Errores frecuentes

Modificar durante el inventario

Puede destruir evidencias y provocar incidencias.

Confiar solo en documentación

Puede estar obsoleta.

Confiar solo en herramientas automáticas

No identifican criticidad ni procesos.

Auditar sin alcance

Genera expectativas imposibles y deja áreas ambiguas.

Realizar pruebas agresivas en producción

Puede convertir la auditoría en la causa de la caída.

Presentar suposiciones como hechos

La evidencia debe clasificarse.

Crear una lista enorme sin prioridad

La empresa no sabe por dónde empezar.

Recomendar renovación total

Puede ignorar componentes válidos y aumentar riesgo de migración.

Ignorar personas y proveedores

Muchos puntos únicos de fallo no son físicos.

No probar recuperación

Revisar que una tarea terminó no valida la copia.

Incluir secretos en el informe

Aumenta exposición.

No revisar después

Los hallazgos quedan abiertos y la auditoría envejece.

Lista de comprobación

• ¿Se ha definido alcance y exclusiones?
• ¿Existe autorización para acceder y probar?
• ¿Se ha protegido la producción?
• ¿Los accesos son temporales y mínimos?
• ¿La evidencia se custodia de forma segura?
• ¿El inventario incluye cloud y cuentas técnicas?
• ¿Cada activo tiene función y responsable?
• ¿Se han identificado dependencias?
• ¿Se han localizado puntos únicos de fallo?
• ¿Se ha revisado soporte y ciclo de vida?
• ¿Se ha medido capacidad?
• ¿Se han revisado sistemas y servicios activos?
• ¿La red está documentada?
• ¿El almacenamiento tiene margen?
• ¿Las aplicaciones tienen responsable?
• ¿Las cuentas antiguas están revocadas?
• ¿Los administradores están justificados?
• ¿Los datos tienen fuente oficial?
• ¿La documentación permite recuperar?
• ¿Las copias se han restaurado?
• ¿Las alertas llegan a alguien responsable?
• ¿Las incidencias repetidas están identificadas?
• ¿Los cambios tienen vuelta atrás?
• ¿Los proveedores entregan accesos y documentación?
• ¿Las licencias se corresponden con el uso?
• ¿Cada hallazgo tiene evidencia?
• ¿Se ha clasificado impacto y prioridad?
• ¿Existe un plan inmediato?
• ¿Existe una hoja de ruta?
• ¿Se ha fijado revisión de cierre?

Preguntas frecuentes

Conclusión

Auditar una infraestructura informática existente consiste en convertir un entorno parcialmente conocido en un sistema visible, verificable y gobernable.

La auditoría debe comenzar con alcance, autorización y protección de la operativa. Después recoge evidencias, construye inventario y dependencias, revisa cada capa y valida procedimientos críticos.

El valor no está en producir la lista más larga de defectos, sino en distinguir qué puede detener la empresa, qué debe corregirse primero y qué cambios pueden implantarse sin crear un riesgo mayor.

Hardware, sistemas, red, almacenamiento y aplicaciones son solo una parte. También deben revisarse identidades, copias, documentación, proveedores, conocimiento, monitorización y operación.

Los hallazgos deben estar respaldados por evidencia, expresar impacto y proponer acciones proporcionadas. Una recomendación sin contexto puede ser técnicamente atractiva y operativamente imprudente.

Para una pequeña empresa, una auditoría útil no necesita imitar un proceso corporativo enorme. Necesita ser suficientemente profunda para descubrir riesgos reales, suficientemente clara para que dirección pueda decidir y suficientemente práctica para convertirse en una hoja de ruta.

Cuando la revisión se repite y los hallazgos se cierran, la infraestructura deja de depender de conocimiento fragmentado y urgencias. La empresa gana continuidad, capacidad de inversión y criterio para evolucionar.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en infraestructura, sistemas, redes, seguridad, copias y gobierno digital.