Checklist para auditar una aplicación legacy

Aclara el propósito de la auditoría

Antes de inspeccionar código, acuerda qué decisión debe habilitar: corregir vulnerabilidades, migrar a Cloud, mejorar despliegues, preparar una sustitución o entender costes. Define sistemas dentro y fuera de alcance, responsables y restricciones de acceso. La palabra «legacy» describe contexto, no demuestra por sí misma que la aplicación sea insegura o inservible.

Arquitectura y dependencias

• ¿Qué componentes, versiones, entornos y almacenes existen?
• ¿Qué sistemas llaman a la aplicación y cuáles son llamados por ella?
• ¿Hay integraciones, tareas programadas, procesos manuales o exportaciones que no figuren en diagramas?
• ¿Qué dependencias ya no reciben soporte o tienen una ruta de actualización conocida?
• ¿Dónde están las interfaces, contratos y configuraciones por entorno?
• ¿Qué límites de capacidad o fallos se han observado y cómo se reproducen?

Comprueba la evidencia en configuración, código, registros y entrevistas. Anota confianza y fecha: un diagrama antiguo no equivale a una dependencia confirmada.

Datos y continuidad

• Clasifica los datos por sensibilidad, propietario, retención y ubicación.
• Identifica formatos, calidad, duplicados, volumen y crecimiento.
• Comprueba cómo se hacen copias, quién las administra y cuándo se restauró una muestra.
• Documenta objetivos de recuperación y tolerancia a pérdida de datos acordados con negocio.
• Localiza sincronizaciones, migraciones y procesos de reconciliación.
• Comprueba qué ocurre ante interrupción parcial y cómo se comunica.

Seguridad y acceso

• Revisa versiones, parches, dependencias y componentes fuera de soporte.
• Identifica cuentas técnicas, permisos, secretos y certificados; confirma propietarios y rotación.
• Comprueba autenticación, autorización, separación de funciones y registro de actividad.
• Verifica cifrado, exposición de interfaces y tratamiento de datos personales.
• Revisa el proceso para corregir una vulnerabilidad y desplegar el cambio.

Una auditoría técnica no reemplaza una evaluación de cumplimiento, privacidad o seguridad especializada cuando el sistema o su sector la exige. Prioriza evidencias y acciones según impacto y exposición.

Despliegue y operación

• ¿Cómo se construye, prueba y publica cada versión?
• ¿Se puede reproducir el entorno y volver a una versión conocida?
• ¿Qué métricas, registros y alertas permiten detectar un fallo?
• ¿Quién responde a incidentes y dónde está el procedimiento operativo?
• ¿Qué tareas manuales se ejecutan con frecuencia y cuáles dependen de una sola persona?
• ¿Se conocen tiempos de ciclo, fallos de cambio, incidentes y costes relevantes?

Usa categorías y definiciones consistentes para que una medición sea comparable. El DORA research program documenta métricas de entrega de software; utilízalas con contexto y no para comparar equipos sin considerar producto, tamaño y entorno.

Conocimiento y mantenibilidad

• ¿Hay una persona responsable de cada componente?
• ¿La documentación coincide con el comportamiento actual?
• ¿Qué reglas de negocio viven solo en conversaciones o procedimientos manuales?
• ¿Qué partes tienen pruebas y cuáles requieren validación manual extensa?
• ¿Qué habilidades o contratos son necesarios para mantener el sistema?
• ¿Hay una forma segura de probar cambios con datos no productivos?

Convierte hallazgos en decisiones

Para cada hallazgo registra evidencia, impacto posible, probabilidad o incertidumbre, responsable y siguiente acción. Separa hechos de hipótesis. Ordena por riesgo para el objetivo acordado, no por novedad tecnológica.

Una auditoría útil termina con opciones: mantener con controles, corregir un riesgo, modernizar un componente, preparar una migración, sustituir o retirar. Incluye dependencias y preguntas sin resolver. No prescribas una reescritura total si la evidencia respalda una intervención menor.