Anonymized real-life case: 8 findings from an IT audit of a group with several subsidiaries in Mexico, ranging from an un ERP that has been unsupported since 2015 to backups that have never been tested.
This is a real-life case from one of our IT audits in Mexico, anonymized: no company name, no names of individuals, and no information that would allow the client to be identified. What remains are the technical findings—because they represent exactly the type of risk that recurs in corporate groups with multiple subsidiaries, not an isolated incident.
The audited group operated through seven sister companies under a single holding company, all of which relied on a single management system that had been custom-developed years earlier. These were the findings.
The in-house " ERP " was built on technology that the manufacturer itself stopped supporting on January 13, 2015. Ten years later, it was still the system used to process accounting, payroll, loans, and billing for all of the group’s subsidiaries. No security patches, no official updates since then—just makeshift internal maintenance.
There was no quality assurance department or real testing environment. The same developer who wrote the code change would test it, and final validation was done through trial and error with the end user once the code was already in production. There were no scheduled maintenance windows or systematic validations—just checking that “the code ran” after it was modified.
The IT team followed the philosophy that "the code speaks for itself"—in other words, there were virtually no comments. There was no variable catalog, nor was there a dedicated database administrator (DBA). Knowledge of the system resided almost exclusively in one person's head.
The team had a documented workflow for requesting changes: formatting, approval, testing, and implementation. In practice, however, users would request changes directly due to urgency, and the IT coordinator would decide on the priority on a case-by-case basis, without following the formal process. The result: changes in production with no way to trace who requested them, why, or who approved them.
When asked about internal IT security and usage policies, the response was that it was unclear whether any existed—they were not mentioned in any of the interviews. For an entity within the group that is subject to oversight by external financial regulators, this is a compliance gap that is as significant as it is technical.
Daily backups were performed—to physical disk, the cloud, and a centralized server—but even the IT team itself did not know which application was used to generate them or whether the process actually ran as described. The estimated disaster recovery time (DRP) was cited from memory—“about 40 minutes, maybe an hour”—without anyone having timed an actual recovery. Nor could the off-site contingency server, mentioned as part of the backup plan, be verified in practice.
Several subsidiaries were physically located at the same site, and in the event of a failure, the plan was to borrow hardware from another company in the group to keep operations running. It is an ingenious short-term continuity solution, but it also means that no subsidiary had a clear security boundary from the others —a failure or breach at one company in the group could expose the others.
At more than one subsidiary, the same systems coordinator served as the project manager, lead developer, and first-line technical support—and sometimes also provided support to other companies in the group. There was no redundancy of knowledge: if that person was unavailable, there was no one else capable of resolving a failure.
Each finding was rated on a risk matrix based on severity—moderate, significant, or catastrophic—so that the group could prioritize which issues to address first rather than trying to resolve everything at once. Those under point 1 (unsupported system) and 6 (unverified continuity) topped the list of issues requiring immediate attention.
None of the findings on this list are unusual. They appear, in various combinations, in most of the 15 typical findings we document in audits of subsidiaries: legacy systems with no clear owner, business continuity plans that exist in theory but have never been tested, and too much critical knowledge concentrated in a single person. This is exactly what an IT audit is designed to bring to light before an incident forces the issue.
30 minutes with one of our directors. No sales pitch—straight to the point.