# What is a technical audit, and when do you need one? A technical audit tells you what state a system is really in. Here is what it covers, what you should receive, and the signs it is time to ask for one. - Page: https://www.cognivise.co.uk/blog/what-is-a-technical-audit - Topic: Running software - Published: 2026-10-09 - Updated: 2026-10-09 - Author: Cognivise ## Key takeaways - A technical audit is an independent review of how a system is built, hosted, secured and maintained. It ends in a written report, not in changes to the system. - It answers three questions: what state is the system really in, what is the risk, and what should happen first. - Commission one when something is going wrong and nobody can say why, before a major decision such as a rebuild or sale, or when a key person is about to leave. - A good audit names the evidence it used, ranks findings by business impact and says what it could not check. ## What is a technical audit? A technical audit is a structured look at a piece of software and the environment it runs in. A reviewer who did not build it reads the code, inspects the infrastructure, talks to the people who run it and writes down what they found. It is not a rebuild plan and it is not a quote for fixing everything. Its job is to replace opinion with evidence, so that the next decision is made on facts. ## What does an audit usually cover? The scope depends on the system, but most audits look at the same six areas. - **Code and structure.** How the software is organised, how easy it is to change safely, and whether there are tests that would catch a mistake. - **Hosting and infrastructure.** Where it runs, how it is deployed, how it is backed up and what happens if a server fails. - **Security.** Access control, how secrets such as passwords and keys are stored, how dependencies are kept up to date, and how personal data is protected. The [NCSC](https://www.ncsc.gov.uk) publishes practical guidance for small organisations. - **Performance and reliability.** Where it is slow, where it fails and whether anyone would know. - **Dependencies and licences.** Which third-party libraries and services it relies on, and which of them are out of date or no longer supported. - **People and process.** Who understands the system, how changes are released, and what is written down. An audit does not have to cover everything. A narrow audit of one worry, such as security or hosting cost, is often more useful than a broad one that skims the surface. ## When do you need one? The most common triggers are practical rather than technical. - **Something keeps going wrong and nobody can explain why.** Outages, slow pages or bugs that return after being fixed usually have a cause that sits deeper than the symptom. - **The person who built it has left.** If the knowledge lived in one head, an audit turns it into a document before it is lost for good. - **You are about to make a large decision.** Rebuilding, replatforming, buying a company or raising investment all go better when the current state is known. Investors and buyers often ask for this kind of review. - **Costs are rising without a clear reason.** Hosting, support and developer time can grow quietly for years. - **You inherited the system.** A new owner or new technical lead needs an honest starting point. If none of these apply and the system is stable, understood and maintained, you probably do not need an audit yet. ## What should you receive? A useful report is short enough to read and specific enough to act on. Look for: - a summary a non-technical director can follow in a few minutes - findings ranked by business impact, not by how interesting they are to engineers - the evidence behind each finding, so you can check it - a clear statement of what was not reviewed, and why - a suggested order of work, with rough effort ranges rather than false precision Be cautious of a report that is mostly a list of tools run and warnings produced. Automated scans are a starting point, not an audit. ## Audit, discovery or support: what is the difference? These are easy to confuse because they involve some of the same people. - An **audit** looks at something that already exists and reports on its condition. - A **discovery** looks at something that does not exist yet and works out what to build. Our guide to [technical discovery](https://www.cognivise.co.uk/blog/technical-discovery-explained) explains how it works. - **Support** keeps a system running day to day. See [what application support and maintenance cover](https://www.cognivise.co.uk/blog/what-application-support-covers). An audit often leads into one of the other two. If it shows the system is too costly to keep changing, the next step may be [legacy system modernisation](https://www.cognivise.co.uk/blog/legacy-system-modernisation). ## How do you get the most from an audit? - **Say what decision it should inform.** "Should we rebuild?" produces a different report from "is this safe to keep running?". - **Give access early.** The code, the hosting accounts and the people who run the system are what make the review accurate. - **Ask for the first three things to fix.** Even a long report needs a clear starting point. - **Keep the author separate from the fixer where you can.** A reviewer who will also win the follow-on work has a reason to find more to fix. It can still work if you ask them to be explicit about that. ## Frequently asked questions **How long does a technical audit take?** It depends on the size of the system and the scope you choose. A focused review can be quick, while a broad review of a large system takes longer. A good reviewer will agree the scope and timeline before starting. **Will an audit disrupt the team?** Rarely. It needs some access and a few conversations, but it does not change the live system. **Do we need one if we are about to rebuild?** Often yes. It tells you which parts are worth keeping and which risks a rebuild would simply repeat. **Who should own the report?** You should. It describes your system, so make sure it is delivered in a form you can keep and share. If you are unsure where your system stands, our [planning and technical advice](https://www.cognivise.co.uk/services/planning-and-technical-advice) service starts with exactly this kind of review, and you can [contact us](https://www.cognivise.co.uk/contact) to talk it through. ## Related - [Planning and technical advice](https://www.cognivise.co.uk/services/planning-and-technical-advice) - [Technical discovery: what happens before a software project](https://www.cognivise.co.uk/blog/technical-discovery-explained) - [Legacy system modernisation](https://www.cognivise.co.uk/blog/legacy-system-modernisation)