What a technology audit covers, and what you should get at the end

What an audit examines

• Systems. What software runs the business, how old it is, who supports it, and how the pieces connect.
• Data. Where it lives, how accurate it is, who can reach it, and how often it is typed twice.
• Security. Access, backups, updates, and what would happen if a system or a person were suddenly unavailable.
• Code and infrastructure, where you own any. How it is tested, deployed and documented.
• People and process. Who knows how things work, and what depends on one person's memory.
• Cost. What you pay for licences, hosting and support, and what you pay for and do not use.

A technical review on its own is not enough. The same system can be a serious problem in one company and perfectly adequate in another, depending on how the business uses it. So an audit includes conversations with the people who do the work, not only the people who run the servers.

What it should produce

• A plain description of the current state, written so that a non-technical owner can follow it.
• The risks, ranked by how likely they are and how much they would cost.
• A roadmap in order of priority, with the reasoning for the order.
• For each need, a recommendation to build, to buy, or to keep what you have.
• Rough sizes for the work, so that budgets can be planned.

If the report is a long list of findings with no order, it has done half the job. Anyone can find fifty things wrong with a ten-year-old system. The useful part is knowing which three matter this year.

What to leave alone

Not everything old needs replacing. A system that is stable, understood and does its job is an asset, even if it is unfashionable. Replacing it brings cost and risk, and sometimes no benefit a customer would notice.

A trustworthy audit says so. Be cautious of any review that concludes everything should be rebuilt, particularly when the reviewer would be paid to do the rebuilding.

How to prepare

• Gather what exists: system lists, contracts, diagrams, licence and hosting bills.
• Name one person on your side who can open doors and answer questions.
• Tell your team why it is happening. People speak more openly when they know it is not an assessment of them.
• Decide in advance what decision the audit is meant to inform.

The last point matters most. An audit commissioned to answer a specific question, such as whether to replace the ERP or whether the platform can handle three times the customers, produces a sharper report than one asked to look at everything.

Using the result

Treat the roadmap as a plan to revisit, not a contract. The first items are usually clear and worth starting at once. Later items depend on what you learn from the early ones.

You should also be free to act on it with whoever you choose. The findings and the plan belong to you, and they should be written clearly enough that another team could pick them up and deliver.