Caso real anonimizado: 8 hallazgos de una auditoria TI a un grupo con varias filiales en Mexico, del ERP sin soporte desde 2015 a los backups nunca probados.
Este es un caso real de una de nuestras auditorías informáticas en México, anonimizado: sin nombre de la empresa, sin nombres de personas, sin ningún dato que permita identificar al cliente. Lo que queda son los hallazgos técnicos — porque son exactamente el tipo de riesgo que se repite en grupos empresariales con varias filiales, no una anécdota aislada.
El grupo auditado operaba con siete empresas hermanas bajo un mismo holding, todas dependientes de un único sistema de gestión desarrollado a medida años atrás. Estos fueron los hallazgos.
El ERP interno estaba construido sobre una tecnología que el propio fabricante dejó de dar soporte el 13 de enero de 2015. Diez años después, seguía siendo el sistema que procesaba contabilidad, nómina, créditos y facturación de todas las filiales del grupo. Ningún parche de seguridad, ninguna actualización oficial desde entonces — solo mantenimiento interno improvisado.
No existía un área de calidad ni un ambiente de pruebas real. El mismo desarrollador que escribía el cambio lo probaba, y la validación final ocurría por ensayo y error con el usuario final ya en producción. No había ventanas de mantenimiento programadas ni validaciones sistemáticas — solo comprobar que "el código corriera" después de modificarlo.
El equipo de TI seguía la filosofía de que "el código habla por sí mismo" — es decir, prácticamente no se comentaba. No existía un catálogo de variables ni una persona dedicada a la administración de las bases de datos (DBA). El conocimiento del sistema vivía casi exclusivamente en la cabeza de una persona.
El grupo tenía un flujo documentado para solicitar cambios: formato, aprobación, pruebas, implementación. En la práctica, los usuarios pedían los cambios directamente por urgencia y el coordinador de TI decidía la prioridad caso por caso, sin seguir el proceso formal. El resultado: cambios en producción sin trazabilidad de quién los pidió, por qué, ni quién los aprobó.
Al preguntar por las políticas internas de seguridad y uso de TI, la respuesta fue que no se tenía certeza de si existían — no se mencionaron en ninguna de las entrevistas. Para una entidad del grupo sujeta a supervisión de reguladores financieros externos, es una brecha de cumplimiento tan relevante como técnica.
Se hacían respaldos diarios — en disco físico, en la nube y en un servidor centralizado — pero el propio equipo de TI desconocía qué aplicativo se usaba para generarlos y si el proceso se ejecutaba realmente como se describía. El tiempo estimado de recuperación ante desastre (DRP) se citaba de memoria — "unos 40 minutos, quizás una hora" — sin que nadie hubiera cronometrado una recuperación real. Ni el servidor de contingencia fuera de sitio, mencionado como plan de respaldo, pudo verificarse en la práctica.
Varias filiales compartían físicamente el mismo site y, en caso de falla, se contemplaba tomar prestado hardware de otra empresa del grupo para mantener la operación. Es una solución de continuidad ingeniosa a corto plazo, pero también significa que ninguna filial tenía una frontera de seguridad clara respecto a las demás — un fallo o una brecha en una empresa del grupo podía exponer a las otras.
En más de una filial, el mismo coordinador de sistemas era a la vez el responsable de la gestión de proyectos, el desarrollador principal y el soporte técnico de primera línea — y en ocasiones también daba soporte a otras empresas del grupo. No había redundancia de conocimiento: si esa persona no estaba disponible, tampoco lo estaba la capacidad de resolver una falla.
Cada hallazgo se calificó en una matriz de riesgos por severidad — moderado, importante o catastrófico — para que el grupo pudiera priorizar qué atender primero en lugar de intentar resolver todo a la vez. Los del punto 1 (sistema sin soporte) y 6 (continuidad no verificada) encabezaban la lista de atención inmediata.
Ningún hallazgo de esta lista es exótico. Aparecen, en distintas combinaciones, en la mayoría de los 15 hallazgos típicos que documentamos en auditorías a filiales: sistemas heredados sin dueño claro, continuidad de negocio que existe en la teoría pero nunca se ha probado, y demasiado conocimiento crítico concentrado en una sola persona. Es exactamente lo que una auditoría informática está diseñada para sacar a la luz antes de que un incidente lo haga por las malas.
30 minutos con uno de nuestros directores. Sin presentación comercial — directo al grano.