Qué es una auditoría técnica
Una auditoría técnica es un diagnóstico del estado de un sistema de software, hecho por alguien externo al equipo que lo construyó. Se revisan el código, la arquitectura, la infraestructura, la seguridad y la forma de trabajar, y se traduce todo eso en algo que se pueda usar para decidir.
No es una búsqueda de culpables. Todo sistema acumula decisiones apuradas, atajos y partes que nadie quiere tocar; es normal. El objetivo es tener una foto objetiva de dónde estás parado, para que las próximas decisiones (seguir, mejorar, reescribir, cambiar de proveedor o invertir) se tomen con información y no a ciegas.
En una frase: una auditoría técnica responde tres preguntas: ¿cómo está mi software?, ¿qué riesgos estoy corriendo? y ¿qué hago primero?
Cuándo conviene hacer una
No hace falta esperar a que algo se rompa. Estas son las situaciones en las que más valor aporta:
- Heredaste un sistema: se fue el desarrollador, cambiaste de proveedor o compraste una empresa con su software. Necesitás saber qué tenés.
- Nadie se anima a tocarlo: cada cambio rompe algo, los tiempos de desarrollo se alargan y nadie sabe bien por qué.
- El sistema está lento o se cae y las soluciones de siempre ya no alcanzan.
- Estás por invertir: antes de una reescritura, de sumar funciones grandes o de escalar a más usuarios.
- Recibiste presupuestos muy distintos y querés una opinión independiente sobre qué hace falta de verdad.
- Te preocupa la seguridad: manejás datos de clientes, pagos o información sensible y no sabés si están bien protegidos.
- Vas a buscar inversión o vender la empresa, y el software va a ser parte de la evaluación (due diligence técnica).
Qué se revisa
El alcance se ajusta a cada caso, pero una auditoría completa suele cubrir estas áreas:
- Arquitectura. Cómo está organizado el sistema, qué partes tiene, cómo se comunican y si esa estructura soporta lo que el negocio necesita hoy y en los próximos años.
- Calidad del código. Legibilidad, duplicación, complejidad, convenciones y tests. La pregunta de fondo: ¿qué tan caro y riesgoso es cambiarlo?
- Seguridad. Autenticación y permisos, manejo de datos sensibles, contraseñas y claves guardadas en el código, dependencias con vulnerabilidades conocidas y exposición de las APIs, tomando como referencia el OWASP Top 10.
- Infraestructura y despliegue. Dónde y cómo corre, cómo se publica una versión nueva, si hay backups (y si alguien probó restaurarlos), monitoreo, alertas y costos de la nube.
- Base de datos. Modelo de datos, índices, integridad, consultas lentas y crecimiento.
- Rendimiento. Tiempos de respuesta, cuellos de botella y cuánta carga soporta antes de degradarse.
- Dependencias y tecnologías. Versiones sin soporte, librerías abandonadas y dependencia excesiva de un proveedor.
- Procesos y documentación. Control de versiones, revisión de código, entornos de prueba, documentación y cuánto conocimiento depende de una sola persona.
Cómo es el proceso
- Charla inicial, sin costo. Me contás qué te preocupa, qué decisión tenés por delante y cómo está armado el sistema. Con eso definimos el alcance.
- Propuesta por escrito. Qué se va a revisar, en cuánto tiempo y con qué presupuesto cerrado.
- Accesos. Acceso de solo lectura a lo acordado: repositorios, infraestructura, base de datos (o una copia anonimizada) y la documentación que exista. Si hace falta, firmamos un acuerdo de confidencialidad.
- Relevamiento. Una o dos charlas cortas con quien mejor conoce el sistema, para entender el contexto y la historia de las decisiones.
- Análisis. Revisión manual del código y la infraestructura, complementada con herramientas automáticas: análisis estático, escaneo de dependencias y métricas.
- Informe y presentación. Te entrego el informe y lo recorremos juntos en una reunión, con espacio para todas las preguntas.
Qué recibís al final
- Resumen ejecutivo. Una o dos páginas en lenguaje claro, para quien decide, sin necesidad de saber de tecnología.
- Hallazgos por severidad. Cada problema clasificado como crítico, alto, medio o bajo, con la evidencia y el impacto concreto en el negocio.
- Plan de acción priorizado. Qué hacer ya (mejoras rápidas), qué en los próximos meses y qué a largo plazo, con el esfuerzo estimado de cada cosa.
- Recomendaciones. Sobre arquitectura, herramientas, procesos y, si corresponde, qué perfil técnico conviene sumar.
- Reunión de presentación para repasar los resultados y resolver dudas.
El informe es tuyo: lo podés usar con tu equipo, compartirlo con otro proveedor o usarlo como base para pedir presupuestos comparables.
Cuánto tarda y cuánto cuesta
Depende del tamaño y la complejidad del sistema. Como referencia:
- Sistema chico (una aplicación, un repositorio): entre una y dos semanas.
- Sistema mediano (varios servicios, integraciones, más de un entorno): entre dos y cuatro semanas.
- Sistema grande o crítico: se divide por etapas, empezando por lo que más riesgo tiene.
El precio es cerrado y se define después de la charla inicial, según el alcance. Así sabés de antemano cuánto vas a invertir.
Qué no es una auditoría
- No es una caza de culpables. Se evalúa el sistema, no a las personas.
- No es una reescritura. La auditoría diagnostica; no modifica el código, salvo que se acuerde lo contrario.
- No es un pentest completo. Incluye una revisión de seguridad, pero si el sistema necesita pruebas de intrusión formales, te lo voy a recomendar.
- No te obliga a nada después. Podés implementar las mejoras conmigo, con tu equipo o con quien elijas.
Cómo prepararte
No hace falta tener todo ordenado; justamente para eso es la auditoría. Pero ayuda tener a mano:
- La lista de lo que te preocupa o lo que querés decidir.
- Quién conoce mejor el sistema, aunque ya no trabaje en la empresa.
- La documentación que exista, aunque esté desactualizada.
- Los incidentes o problemas recientes: caídas, lentitud, errores frecuentes.
- Los accesos que se van a necesitar, o quién puede darlos.