Qué revisar antes de contratar una auditoría de software

Una auditoría de software puede ser una de las mejores inversiones de una empresa… o un PDF de 120 páginas que nadie lee. La diferencia está en cómo se define el alcance, quién participa y qué decisiones permite tomar al final.

Si estás evaluando contratar una auditoría técnica, estas son las preguntas que deberías hacer antes de firmar.

1. ¿Qué decisión quieres tomar con la auditoría?

“Quiero saber cómo está el sistema” no es un objetivo. “Necesito decidir si migro a .NET 10, si reemplazo el módulo de facturación o si renuevo el contrato de soporte” sí lo es.

Una auditoría útil empieza por la decisión, no por la tecnología.

2. ¿Qué incluye y qué no incluye?

Pregunta explícitamente por:

• Revisión de código, arquitectura, base de datos e infraestructura.
• Entrevistas con desarrollo, operación y negocio.
• Pruebas de seguridad y performance.
• Análisis de costos cloud.
• Roadmap y estimación.
• Sesión de presentación de resultados.

Si el proveedor no puede delimitar el alcance, tampoco podrá entregarte algo accionable.

3. ¿Quién va a hacer el trabajo?

No es lo mismo que lo venda un socio senior y lo ejecute un junior sin contexto. Pregunta quién revisa el código, cuántas horas dedica y qué experiencia tiene en tu stack.

4. ¿Cómo van a acceder al sistema?

Una auditoría seria necesita acceso al repositorio, a un ambiente de pruebas o, como mínimo, a evidencia documental y entrevistas. Si solo van a mirar diagramas, el resultado será superficial.

Define también cómo se protege la información: NDA, accesos temporales, entorno aislado y borrado de datos al final.

5. ¿Cómo priorizan los hallazgos?

Un listado de 300 problemas no ayuda. Necesitas un mapa de riesgos con impacto, probabilidad, esfuerzo y dependencia. Pregunta cómo van a separar lo urgente de lo importante.

6. ¿El roadmap es ejecutable?

Un buen roadmap tiene fases, criterios de salida y dependencias. No es una lista de deseos. Pregunta:

• ¿Qué se hace primero y por qué?
• ¿Cuánto esfuerzo requiere cada fase?
• ¿Qué se puede posponer sin riesgo?
• ¿Qué necesita el negocio para empezar?

7. ¿Cómo van a medir el éxito?

Antes de empezar, define métricas: reducción de incidentes, tiempo de despliegue, latencia, costo cloud, cobertura de pruebas, tiempo de incorporación de nuevos desarrolladores. Si no hay métricas, no hay forma de saber si la auditoría sirvió.

8. ¿Qué pasa después?

Una auditoría puede terminar en un plan que ejecuta tu equipo, en una segunda fase con el mismo proveedor o en una decisión de no hacer nada. Las tres son válidas. Lo importante es que el entregable permita continuar sin depender del auditor.

9. ¿Cuál es el precio real?

Compara alcance, horas, seniority y entregables, no solo el número. Una auditoría de USD 1.000 que no incluye entrevistas ni revisión de código puede salir más cara que una de USD 3.000 que te evita un proyecto fallido.

10. ¿Firmarían un acuerdo de confidencialidad y propiedad?

Sí, si trabajan en serio. El contrato debe aclarar:

• Confidencialidad de la información.
• Propiedad de los entregables.
• Uso de datos y accesos.
• Responsabilidad y limitaciones.
• Qué pasa si el proyecto se detiene.

Señales de alerta

• Te entregan el mismo informe genérico a todos los clientes.
• No piden acceso al código ni hablan con tu equipo.
• Prometen “cero riesgo” o una reescritura total en semanas.
• No pueden explicar cómo priorizan.
• El precio es sospechosamente bajo para el alcance.
• No hay sesión de cierre ni plan de transferencia.

Qué deberías recibir al final

• Mapa de arquitectura y dependencias.
• Hallazgos priorizados por riesgo.
• Opciones con trade-offs (no una sola receta).
• Roadmap de 90 días.
• Estimación de esfuerzo.
• Sesión de lectura con negocio y tecnología.
• Documento que puedas defender ante un comité.

Si quieres una segunda opinión sobre tu sistema, puedes agendar un diagnóstico o escribirme directamente. En la primera llamada te digo si una auditoría tiene sentido o si hay una forma más barata de resolverlo.