+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Getting your existing software audited

IT Strategy By Mits Engineering Team 2 min read
Getting your existing software audited

Businesses commission a technical audit for a small number of recurring reasons: changes have become slow and expensive and nobody can say why, the vendor who built it is unresponsive or gone, an investor or buyer has asked questions, or something broke badly enough to prompt the question of what else might. All four are legitimate, and what the audit should produce differs depending on which one you have.

A useful audit covers five areas. What the system actually is — architecture, components, dependencies, where it runs, what it connects to, mapped against what anybody believed. What condition the code is in, assessed by whether it can be changed safely rather than by style. What the security position is, including credentials, access, dependency vulnerabilities and data handling. What you own — code, accounts, domains, licences, and whether the assignment chain is clean. And what it will cost to keep running.

That fourth item is the one that most often produces a surprise, and it is worth asking for specifically. Cloud accounts registered to a former employee's email. A domain expiring in four months registered to the agency that built the site. A repository on someone's personal account. A licensed component with no invoice. These are not technical findings and they are frequently the most urgent things the audit uncovers, because each is a single point at which the business could lose access to its own system.

Insist that the output is prioritised and costed rather than exhaustive. A hundred-page report listing everything wrong is a document nobody acts on. What a business owner needs is: here are the four things that could stop you trading, here are the six that make every change slower and what fixing them costs, and here is what is untidy and can wait. An auditor who cannot produce that distinction has assessed the code and not the situation.

Choose the auditor with attention to incentive. A firm that audits and then bids to do the remediation has a reason to find a great deal of work, and while most are honest, the structure invites inflation. Either engage someone who will not bid for the follow-on, or ask for the findings in a form you could take to three different firms for quotes — which is a reasonable request and a useful test of how the findings are written.

One expectation to set internally before starting. An audit of any system more than a few years old will find things that reflect badly on decisions people in the room made under pressure. If the exercise becomes about attributing blame, the people who know most will contribute least, and the audit will miss what only they could have told you. Framing it as establishing the current position, explicitly and out loud, is what determines whether you get the real picture.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy