"Te paso el informe" no es un entregable. Es una frase. Las auditorías tecnológicas que sirven para algo dejan tras de sí un dossier compuesto, no un documento único. Cada pieza tiene un propósito distinto y se usa en momentos diferentes del año posterior a la auditoría.
Si una propuesta de auditoría te plantea "informe final con conclusiones y recomendaciones" sin más detalle, conviene pedir desglose antes de firmar. Estos son los siete entregables que componen una auditoría seria, qué tienen que contener para ser útiles y dónde fallan los informes genéricos.
1. Diagrama de arquitectura actual
Qué es. Un mapa visual de cómo están conectados los sistemas hoy. Aplicaciones, servidores, bases de datos, integraciones, servicios externos, flujos de datos. Con nombres reales, no genéricos. Con dependencias marcadas: qué necesita qué para funcionar y qué pasa si una pieza cae.
Qué no es. Una caja con "ERP" y otra con "CRM" unidas por una flecha. Esa es la presentación comercial de la propia empresa, no una arquitectura. La arquitectura real incluye el método de integración (API REST, fichero plano, sincronización manual), la frecuencia (en tiempo real, diaria, manual cuando alguien se acuerda), las credenciales y dónde se guardan, los puntos de fallo, los datos en tránsito y dónde quedan los logs.
Cómo se nota que está bien hecho. Cuando un técnico nuevo puede entrar al equipo y, leyendo el diagrama, preguntar "¿qué pasa si SAP no responde a tiempo durante el cierre mensual?". Si el diagrama te permite formular esa pregunta, está vivo. Si solo te permite formular "ah, vale, todo conectado", está muerto.
2. Inventario tecnológico completo
Qué es. El listado exhaustivo de lo que tiene la empresa: licencias de software, contratos con proveedores, suscripciones SaaS, dominios, certificados SSL con sus fechas de caducidad, credenciales críticas (no las propias credenciales, sino dónde están y quién las tiene), herramientas en uso por departamento, servidores y sus configuraciones.
Qué no es. Un Excel con tres columnas (nombre, proveedor, coste) que probablemente ya tienes. El inventario serio incluye versión, licencia activa o caducada, responsable interno, ciclo de revisión, alternativas si el proveedor desaparece, dependencias con otros sistemas y nivel de criticidad.
Cómo se usa después. Para renegociar contratos a vencimiento (la auditoría suele detectar entre un 10% y un 25% de servicios infrautilizados o duplicados). Para responder rápido cuando hay un incidente de seguridad y hace falta saber qué versiones tienes desplegadas. Para preparar el plan de continuidad cuando alguien pregunta qué pasa si tu proveedor de hosting cierra.
3. Mapa de riesgos con evidencias
Qué es. El listado de riesgos detectados clasificados por criticidad (alta, media, baja) y por probabilidad. Cada riesgo lleva la evidencia que lo demuestra: una captura de la consola con el error real, una traza de logs con la operación fallida, una medición concreta del tiempo de respuesta, una configuración insegura visible en un fichero accesible. Sin evidencia, un riesgo es una opinión.
Qué no es. Una lista del estilo "pueden producirse caídas, pérdida de datos, vulnerabilidades de seguridad y problemas de rendimiento". Eso lo escribe cualquiera sin entrar al sistema. Un riesgo bien documentado dice exactamente: "el endpoint de pagos no valida el formato del IBAN antes de enviar al banco; en los logs del 14 de marzo aparecen 27 transacciones rechazadas con error 400 que el cliente final no vio. Pueden estar duplicándose intentos al reintentarse manualmente."
Cómo se prioriza. Los riesgos altos exigen acción inmediata, los medios entran en el plan trimestral, los bajos en el plan anual. Si la auditoría no los clasifica, te deja todo el trabajo de priorización a ti, que es exactamente lo que has pagado para que te ahorren.
4. Análisis de costes tecnológicos
Qué es. El desglose real de qué se paga, a quién, por qué y para qué. Hosting, licencias, SaaS, herramientas, mantenimiento, servicios externos. Comparado con lo que se usa de verdad (usuarios activos, almacenamiento ocupado, tráfico real). Y comparado con alternativas razonables del mercado.
Qué no es. Una tabla con tu factura actual de hosting y la sugerencia genérica de "considerar opciones más económicas". El análisis útil dice: "tu facturación de cloud el año pasado fue de 14.200 €. El 38% corresponde a una base de datos provisionada para tres veces tu uso real. Reduciéndola a su tamaño adecuado, ahorrarías 4.500 € anuales. La factura de un proveedor equivalente con el dimensionamiento correcto sería de 8.900 €."
Cómo se nota que está bien hecho. Cuando incluye números concretos y supuestos explícitos. Sin ambigüedad. Sin "podría ahorrar entre un 10 y un 40%". El rango no aporta nada, los números sí.
5. Plan de acción priorizado
Qué es. La lista ordenada de cosas que hay que hacer, en qué orden, con qué dependencias entre ellas, qué esfuerzo requieren y qué riesgo mitigan. Dividido en horizontes: 0-3 meses (urgente), 3-6 meses (relevante), 6-12 meses (estructural). Cada acción tiene responsable interno propuesto, perfil técnico necesario, estimación de coste y resultado esperado.
Qué no es. Una lista del tipo "implementar copias automatizadas, reforzar la seguridad, mejorar la documentación, optimizar el rendimiento". Eso son objetivos genéricos, no un plan. El plan de acción dice: "Acción 1, primer mes, esfuerzo 8 horas: configurar copias automatizadas diarias de la base de datos en bucket externo cifrado, con prueba de restauración mensual. Coste estimado de la herramienta: 15 €/mes. Mitiga el riesgo R3 (pérdida total de datos por fallo de hosting). Responsable interno: ninguno necesario; ejecutable por proveedor externo en 1 día."
Por qué importa el orden. Porque algunas acciones desbloquean otras. No tiene sentido refactorizar una integración que vas a sustituir. No tiene sentido formar al equipo en una herramienta antes de validar que se va a usar. El orden lo da el auditor, no tú.
6. Resumen ejecutivo de 2 páginas
Qué es. El documento que lee la dirección. Sin tecnicismos, sin jerga, sin "implementar mejores prácticas DevOps". Dos páginas que explican qué se ha encontrado, qué consecuencias tiene si no se actúa, qué hay que hacer en los próximos doce meses y qué presupuesto requiere. Con una conclusión defendible en un comité.
Qué no es. Las dos primeras páginas del informe técnico. Si copia lo mismo que el resto pero con menos detalle, no es ejecutivo: es un resumen. El ejecutivo se redacta para alguien que tiene cinco minutos y necesita decidir si aprueba el plan de acción.
Indicador de calidad. Si la dirección, después de leerlo, puede explicar la situación a su consejo en una transparencia, está bien hecho. Si necesita pedir aclaraciones técnicas para entender qué dice, está mal redactado.
7. Sesión de presentación de resultados
Qué es. Una reunión de 1 a 2 horas donde el auditor presenta los hallazgos al equipo cliente (dirección, IT si lo hay, responsables de las áreas afectadas). Con tiempo para preguntas concretas, con discusión de prioridades, con ajuste del plan de acción según restricciones internas que solo conoce el cliente.
Qué no es. Un envío del PDF por email con un "cualquier duda me decís". Esa no es una presentación: es una abdicación. Los hallazgos importantes se discuten en persona porque casi siempre alguien del cliente puede aportar contexto que cambia la prioridad. Y porque las recomendaciones se entienden distinto cuando se argumentan en directo.
Por qué se nota la diferencia. Las auditorías que terminan en una sesión de presentación tienen una tasa de implementación del plan de acción muy superior a las que terminan en un email con adjunto. Eso lo vemos en los seguimientos a los seis meses.
Cómo usar el dossier después
Los entregables no son un trámite final. Son herramientas que se usan durante los doce meses siguientes. El diagrama de arquitectura se actualiza cada vez que cambia algo importante. El inventario se revisa cada trimestre. El plan de acción se va tachando según se ejecuta. El resumen ejecutivo se reutiliza para justificar inversiones tecnológicas a la dirección.
Si después de seis meses el dossier sigue cerrado y el plan no se ha tocado, no es problema del auditor: es decisión de la empresa. Pero la auditoría que entrega un dossier vivo, con piezas pensadas para usarse, está jugando otro deporte que la que entrega un PDF de cien páginas. Antes de contratar, pregunta exactamente qué entregables vas a recibir y para qué se usan. Si la respuesta es "el informe final con conclusiones", busca otra auditoría.