Una auditoría de seguridad sin contexto de negocio produce un informe de vulnerabilidades ordenadas por severidad técnica, sin ninguna priorización por impacto real. El resultado es un documento que nadie lee completamente y que genera más ansiedad que acción. Antes de cualquier auditoría técnica, hacemos un proceso de preparación que determina qué buscar, dónde buscar y cómo interpretar lo que encontremos.
Por qué la preparación importa más que la auditoría
El valor de una auditoría no está en la lista de vulnerabilidades: está en saber cuáles de esas vulnerabilidades afectan a los sistemas que más importan para el negocio, con qué probabilidad son explotables en tu contexto real y qué impacto tendría un incidente en cada una de ellas. Sin ese contexto, un hallazgo crítico en un sistema obsoleto que nadie usa es menos urgente que uno medio en el sistema de facturación que procesa todas tus transacciones.
Bloque 1: contexto del negocio
- ¿Cuáles son los tres procesos de negocio que no pueden detenerse bajo ninguna circunstancia?
- ¿Qué datos maneja la empresa que tienen mayor sensibilidad regulatoria (datos personales, financieros, de salud)?
- ¿Ha habido incidentes de seguridad en los últimos 24 meses, aunque sean menores? ¿Cómo se resolvieron?
- ¿Cuál es el perfil de amenaza más probable para este sector y tamaño de empresa?
- ¿Hay proyectos de cambio tecnológico en curso o previstos que afecten al perímetro de seguridad?
- ¿Cuáles son los requisitos regulatorios aplicables (GDPR, NIS2, ENS, PCI, sectorial)?
Bloque 2: inventario de sistemas
- Lista completa de sistemas activos con propietario, función y criticidad para el negocio
- Mapa de flujos de datos: qué dato va de qué sistema a cuál y por qué canal
- Sistemas expuestos a internet: cuáles tienen superficie pública y desde cuándo
- Aplicaciones SaaS en uso: cuántas, quién las gestiona y qué datos contienen
- Dispositivos en red: inventario de endpoints, incluyendo dispositivos móviles y equipos de teletrabajo
- Sistemas legacy: qué sistemas tienen soporte activo y cuáles están fuera de ciclo de actualizaciones
- Integraciones entre sistemas: qué conecta con qué y si esas conexiones están documentadas
Bloque 3: accesos y gestión de identidades
- ¿Existe un directorio centralizado de identidades (AD, Entra ID, Okta) o los accesos son por sistema?
- ¿Hay un proceso documentado de alta y baja de usuarios al incorporar o salir personal?
- ¿Qué sistemas tienen MFA activado y cuáles no?
- ¿Existen cuentas de servicio o accesos de aplicación que no están ligados a personas identificadas?
- ¿Se han revisado los privilegios administrativos en los últimos 6 meses?
- ¿Hay accesos de terceros (proveedores, consultores, ex-empleados) activos que deberían estar cerrados?
Bloque 4: gestión de incidencias anterior
- ¿Existe un registro de incidencias IT de los últimos 12 meses?
- ¿Hubo algún incidente relacionado con acceso no autorizado, pérdida de datos o indisponibilidad prolongada?
- ¿Se ejecutan pruebas de restauración desde backup con frecuencia documentada?
- ¿Hay un plan de respuesta a incidentes formal, aunque sea básico?
- ¿Qué proveedor o persona interna sería el primer punto de contacto ante un incidente grave?
Este proceso de preparación lleva entre 2 y 4 horas de trabajo conjunto con el cliente. Es la inversión más rentable del proyecto: permite que los hallazgos técnicos se traduzcan directamente en un plan de acción priorizado por impacto de negocio, no por severidad técnica abstracta.
Si estás pensando en hacer una auditoría de seguridad, podemos explicarte cómo estructuramos el proceso para que los resultados sean accionables desde el primer día.
Ver cómo hacemos las auditorías