Blog
Qué incluye una auditoría técnica y qué entrega al final.
En resumen. Una auditoría técnica revisa el estado real de un sistema —código, arquitectura, dependencias, seguridad, datos, infraestructura, procesos de entrega y rendimiento— y termina en un documento con hallazgos priorizados por impacto y esfuerzo y un plan de remediación. Sirve para decidir con evidencia qué hacer con un sistema, y no obliga a contratar la implementación a quien la hizo.
Cuándo tiene sentido pedirla
Una auditoría responde con evidencia preguntas que suelen discutirse con opiniones. Los momentos típicos son estos:
- Heredaste un sistema y nadie sabe bien cómo está construido.
- Vas a cambiar de proveedor y quieres saber qué recibes.
- Estás por decidir entre reescribir un sistema o seguir mejorándolo.
- Cada cambio tarda más que el anterior y los errores vuelven.
- Vas a comprar, integrar o reemplazar una plataforma.
- Hay dudas sobre la seguridad o la estabilidad antes de crecer.
Qué se revisa
El alcance se acuerda al inicio, pero una auditoría completa cubre estos frentes:
- Arquitectura: componentes, integraciones, límites del sistema y dónde se concentra el riesgo.
- Código: legibilidad, duplicación, complejidad, pruebas y deuda técnica, con ejemplos concretos del repositorio.
- Dependencias: versiones desactualizadas, vulnerabilidades conocidas y licencias.
- Seguridad técnica: autenticación, permisos, manejo de secretos y exposición de servicios.
- Datos: modelo, integridad, respaldos y, sobre todo, si esos respaldos se han restaurado alguna vez.
- Infraestructura y entrega: ambientes, control de versiones, revisión de código, integración continua y cómo se despliega.
- Rendimiento: tiempos de respuesta, uso de recursos, caché y cuellos de botella con su causa probable.
- Conocimiento: documentación y cuánto depende el sistema de una sola persona.
Qué recibes al final
El entregable es un documento pensado para dos lectores: la dirección, que necesita decidir, y el equipo técnico, que necesita actuar. Por eso tiene dos niveles:
- Un resumen ejecutivo: estado general, riesgos principales y recomendación, sin jerga.
- Hallazgos priorizados por impacto y esfuerzo, cada uno con su evidencia: archivo, configuración o medición.
- Un plan de remediación por etapas, con lo urgente separado de lo importante.
- Una recomendación explícita sobre la pregunta de fondo, por ejemplo refactorizar o reescribir, con sus razones.
Qué hace falta de tu lado
Acceso de lectura al repositorio y, si es posible, a los ambientes y a la configuración de despliegue; la documentación que exista, aunque esté incompleta; y una o dos conversaciones con las personas que conocen el sistema. Una auditoría hecha solo sobre el código pierde el contexto de por qué las cosas se hicieron así.
Lo que una auditoría no es
No es una búsqueda de culpables: casi todas las decisiones que hoy parecen malas tuvieron una razón en su momento, y entenderla es parte del diagnóstico.
No es una prueba de penetración completa. Revisa la seguridad desde el código y la configuración; si el sistema necesita un pentest formal, el informe lo dice.
Y no es una propuesta de venta disfrazada. Termina en un documento que tu equipo o cualquier proveedor puede ejecutar. Si después quieres que nosotros hagamos la remediación, bien; si no, el documento sigue siendo tuyo y sigue sirviendo.