What is a technical audit, and when do you need one?

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. Its job is to replace opinion with evidence, so the next decision is made on facts. It answers three questions: what state is the system really in, what is the risk, and what should happen first.

What it covers

Most audits look at the same six areas:

1. Code and structure. How the software is organised, how easy it is to change safely, and whether tests would catch a mistake.
2. Hosting and infrastructure. Where it runs, how it is deployed and backed up, and what happens if a server fails.
3. 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.
4. Performance and reliability. Where it is slow, where it fails and whether anyone would know.
5. Dependencies and licences. Which third-party libraries and services it relies on, and which are out of date or unsupported.
6. 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 you need one

• Something keeps going wrong and nobody can explain why.
• The person who built it has left, and the knowledge lived in one head.
• You are about to make a large decision: a rebuild, a replatform, buying a company or raising investment.
• Costs are rising without a clear reason.
• You inherited the system and need 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 a useful report looks like

• 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?

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. Support keeps a system running day to day.

Getting the most from one

Say what decision it should inform: "should we rebuild?" produces a different report from "is this safe to keep running?". Give access early. Ask for the first three things to fix. And where you can, keep the author separate from the fixer, since a reviewer who will also win the follow-on work has a reason to find more to fix.

The full guide, with FAQs, is on the Cognivise blog. If you are unsure where your system stands, planning and technical advice starts with this kind of review.