Una auditoría técnica de software es una revisión independiente del código, la arquitectura, la seguridad y la forma de trabajar de un sistema, que termina en una lista priorizada de riesgos y recomendaciones. Se pide antes de una decisión importante: invertir más, cambiar de proveedor, comprar una empresa o salir a producción con datos sensibles.

Si buscas “auditoría de software”, verás que muchos resultados hablan de otra cosa: la auditoría de licencias, que comprueba si una empresa paga por el software que usa. Este artículo trata de la auditoría técnica: la que responde a la pregunta “¿en qué estado está mi software y qué riesgo tengo?”.

Auditoría técnica, de código, de seguridad y de licencias: diferencias

Los nombres se mezclan. Antes de pedir presupuesto, aclara cuál necesitas:

Tipo Qué responde Qué revisa
Auditoría de licencias ¿Cumplimos los contratos de licencia del software que usamos? Inventario de software, licencias, número de usuarios
Auditoría de código ¿Está bien escrito y se puede mantener? Calidad del código, pruebas, dependencias, deuda técnica
Auditoría de seguridad o pentest ¿Se puede atacar y cómo? Vulnerabilidades explotables desde fuera o con un usuario
Auditoría técnica completa ¿En qué estado está el sistema y qué riesgos tiene para el negocio? Código, arquitectura, infraestructura, seguridad, datos, procesos y equipo

La auditoría técnica completa incluye partes de las de código y seguridad, pero no sustituye a un pentest profesional cuando la normativa o un cliente lo exigen. Su valor está en la visión de conjunto: relaciona los problemas técnicos con su impacto en el negocio.

Cuándo pedir una auditoría técnica

Estas son las situaciones en las que una auditoría resulta más útil:

Situación Qué te ayuda a decidir
El proyecto se ha atascado: cada entrega tarda más y aparecen errores antiguos Si el problema es el código, el proceso o el equipo, y qué cambiar primero
Vas a cambiar de proveedor de desarrollo Qué recibes, qué falta y cuánto cuesta que otro equipo continúe
Vas a invertir en una nueva fase importante Si conviene evolucionar el sistema o reescribir partes
Compras una empresa o entras como inversor Qué riesgos técnicos hay detrás del producto (due diligence técnica)
El software trata datos sensibles o va a crecer mucho Si la seguridad, el rendimiento y las copias de seguridad están a la altura
Heredas un sistema sin documentación Cómo funciona, qué depende de qué y dónde están los riesgos
Un MVP ha funcionado y quieres escalarlo Qué se puede aprovechar y qué hay que rehacer

Señales de que la necesitas pronto:

  • Nadie del equipo actual sabe desplegar el sistema sin ayuda del proveedor.
  • Las estimaciones fallan de forma sistemática.
  • Los mismos errores vuelven a aparecer después de corregirlos.
  • Las dependencias llevan años sin actualizarse.
  • No sabes cuándo se hizo la última copia de seguridad ni si se puede restaurar.

Si tu caso es un MVP que quieres convertir en producto, lee también cómo hacer un MVP: explicamos qué decisiones técnicas conviene tomar desde el principio.

Qué revisa una auditoría técnica

Una buena auditoría combina herramientas automáticas con revisión manual y entrevistas. Las herramientas encuentran patrones; la revisión manual entiende el contexto. Estas son las áreas habituales:

Código y calidad

  • Estructura del proyecto y separación de responsabilidades.
  • Duplicación, complejidad y partes difíciles de cambiar.
  • Pruebas automáticas: si existen, qué cubren y si se ejecutan.
  • Dependencias: versiones, mantenimiento y vulnerabilidades conocidas.
  • Uso de tecnologías con soporte. Una versión de lenguaje o framework sin actualizaciones de seguridad es un riesgo.

Arquitectura

  • Cómo se reparten las responsabilidades entre componentes.
  • Integraciones con sistemas externos y cómo se gestionan sus errores.
  • Modelo de datos y su capacidad de crecer.
  • Puntos únicos de fallo.

Infraestructura y operación

  • Cómo se despliega: automático y repetible, o manual y dependiente de una persona.
  • Entornos separados para desarrollo, pruebas y producción.
  • Monitorización, registros y alertas.
  • Copias de seguridad y pruebas de restauración. Una copia que nunca se ha restaurado no está probada.

Seguridad

  • Revisión frente a riesgos habituales, como los que recoge el OWASP Top 10.
  • Gestión de contraseñas, sesiones y permisos.
  • Secretos (claves, contraseñas) fuera del código.
  • Cifrado de las comunicaciones y de los datos sensibles.

Datos personales

  • Qué datos se guardan, dónde y durante cuánto tiempo.
  • Medidas técnicas acordes al riesgo, como exige el artículo 32 del RGPD.
  • Contratos de encargo del tratamiento con los proveedores que acceden a los datos.

Proceso y equipo

  • Control de versiones, revisiones de código y gestión de tareas.
  • Documentación: cómo arrancar el proyecto, cómo desplegar, cómo funciona.
  • Conocimiento concentrado en una sola persona.
  • Propiedad del código, del repositorio y de las cuentas de servicios.

Como marco de referencia, la norma ISO/IEC 25010 define las características de calidad de un producto software, entre ellas la adecuación funcional, la compatibilidad, la fiabilidad, la seguridad y la mantenibilidad. No hace falta certificarse para usarla como lista de comprobación.

Qué debe entregarte el informe

El resultado de una auditoría es un informe. Un buen informe se entiende sin ser técnico y sirve para decidir. Exige que incluya:

Parte Qué contiene
Resumen ejecutivo El estado general en una página y los tres o cinco riesgos principales
Hallazgos Cada problema con su evidencia: archivo, configuración, prueba o captura
Gravedad e impacto Cuánto riesgo supone cada hallazgo y qué le pasa al negocio si se materializa
Recomendación Qué hacer con cada hallazgo y una estimación de esfuerzo
Plan priorizado El orden en que conviene abordar las mejoras: urgente, próximo trimestre, cuando se pueda
Puntos fuertes Lo que está bien hecho y conviene conservar

Dos señales de un informe poco útil:

  • Una lista larga de avisos de una herramienta automática sin priorizar ni explicar. Eso lo puede generar cualquiera en minutos.
  • Conclusiones sin evidencia: “el código es de mala calidad” sin ejemplos concretos no te ayuda a decidir ni a negociar con un proveedor.

Cómo es el proceso

Una auditoría técnica suele seguir estas fases:

  1. Alcance y objetivo. Qué decisión quieres tomar con el resultado. Define qué sistemas entran y cuáles no.
  2. Accesos. Repositorio de código, documentación, entorno de pruebas y, si hace falta, acceso de solo lectura a la infraestructura. Los accesos a datos personales se limitan a lo necesario.
  3. Análisis automático. Herramientas de calidad de código, dependencias y seguridad.
  4. Revisión manual. Lectura del código y la arquitectura en las partes críticas.
  5. Entrevistas. Con quien desarrolla y quien usa el sistema. Muchos problemas están en el proceso, no en el código.
  6. Informe y presentación. Se explican los hallazgos y se resuelven dudas.

La duración depende del tamaño del sistema y del alcance. Una auditoría enfocada en una decisión concreta es más rápida y útil que una revisión de todo “por si acaso”.

Cómo prepararte para una auditoría

Si preparas estos puntos antes, la auditoría será más rápida y más barata:

  • Acceso al repositorio con todo el historial.
  • Documentación que exista, aunque esté desactualizada.
  • Un diagrama, aunque sea a mano, de los sistemas y cómo se conectan.
  • Lista de proveedores y servicios externos (nube, correo, pagos).
  • Contactos de quien conoce el sistema.
  • La pregunta de negocio que quieres responder.

Si el sistema lo desarrolló un proveedor externo, avísale con antelación. Una auditoría no es un juicio a su trabajo: es una foto del estado del software. Un proveedor profesional colabora.

Caso frecuente: auditar antes de cambiar de proveedor

Cambiar de proveedor de desarrollo es uno de los momentos en que más se pide una auditoría. El riesgo no está en el código que ves, sino en lo que no se entrega: accesos, conocimiento y procesos que solo conocía el equipo anterior.

Antes de firmar la salida, comprueba que tienes:

Qué Cómo comprobarlo
Código completo El repositorio con todo el historial, no un archivo comprimido con la última versión
Capacidad de desplegar El nuevo equipo despliega una versión sin ayuda del anterior
Accesos a la infraestructura Cuentas de nube, dominio, correo y tiendas de apps a nombre de tu empresa
Secretos Lista de claves y contraseñas de servicios, que se cambian después del traspaso
Copias de seguridad Una restauración real en un entorno de pruebas
Documentación mínima Cómo arrancar el proyecto, cómo desplegar y qué sistemas externos usa

El criterio práctico es sencillo: el traspaso termina cuando el nuevo equipo puede compilar, desplegar, vigilar y restaurar el sistema por su cuenta. Tener el repositorio no basta.

Desconfía de cualquier proveedor nuevo que, sin haber revisado el sistema, proponga reescribirlo entero o dé un precio cerrado para continuarlo.

Después de la auditoría: evolucionar o reescribir

La pregunta que más se repite al terminar una auditoría es si conviene reescribir. Casi nunca es todo o nada.

Opción Cuándo encaja
Evolucionar El sistema funciona y los problemas se concentran en partes concretas
Sustituir por partes Hay módulos críticos muy deteriorados, pero el resto se puede mantener
Reescribir La tecnología no tiene soporte, no hay forma segura de cambiarla y el sistema bloquea el negocio

Reescribir todo de golpe es la opción con más riesgo: durante meses mantienes dos sistemas y el nuevo tiene que alcanzar todo lo que hacía el antiguo. Sustituir por partes suele ser más seguro.

Si la auditoría sale de una app móvil que quieres relanzar, en cuánto cuesta desarrollar una app móvil explicamos el mantenimiento que exigen Apple y Google cada año.

Preguntas frecuentes

¿Quién debe hacer la auditoría?

Alguien independiente del equipo que desarrolló el sistema. Quien escribió el código tiene más difícil ver sus propios problemas, y su opinión no sirve como evidencia ante terceros.

¿Necesito una auditoría si mi proveedor ya hace revisiones de código?

Las revisiones de código miran cada cambio por separado. Una auditoría mira el conjunto: arquitectura, operación, seguridad y riesgos para el negocio. Son complementarias.

¿Cuánto cuesta una auditoría técnica?

Depende del tamaño del sistema y del alcance. No damos una cifra sin ver el sistema, porque dos auditorías con el mismo nombre pueden tener un alcance muy distinto. Pide que el presupuesto detalle qué sistemas entran, qué se entrega y cuántas horas de revisión manual incluye.

Conclusión

Una auditoría técnica es útil cuando sirve para tomar una decisión. Define la pregunta, elige quién la hace con independencia y exige un informe con evidencia y prioridades. Con eso sabrás qué arreglar primero, qué conservar y si tu proyecto puede seguir adelante.

¿Tu proyecto se ha atascado o vas a invertir en una nueva fase? Cuéntanos tu caso y vemos si una auditoría te ayuda a decidir. Más sobre nuestra consultoría técnica.