What is the difference between a code review and a code audit?

A code review looks at one change before it is merged, by a colleague, as part of everyday development. A code audit looks at the whole system at a point in time, by someone outside the team, to answer a business question: is this safe to build on, what would it cost to fix, should we rewrite. Reviews are continuous and narrow. Audits are occasional and broad, and they produce a report you can act on.

How long does a code audit take?

It depends on the size of the codebase, how many services and integrations it has, and whether the auditors get working access to the repositories, the infrastructure and someone who knows the history. A small application with one repository is a short engagement. A platform with several services, a mobile app and years of history takes longer. Ask for a scoped estimate before it starts, and for a written report at the end.

Do I need a code audit before a rewrite?

Yes. A rewrite is the most expensive and risky decision you can make about software, and the usual reason given, that the code is too bad to fix, is a claim that should be checked. An audit tells you which parts are genuinely unsalvageable, which are fine, and whether a targeted modernisation would get you most of the benefit at a fraction of the cost and risk. Many rewrites are avoided this way.

Can you audit an app built with AI tools or by a freelancer who left?

Yes, and these are two of the most common reasons people ask for one. An audit does not need the original developer. It needs access to the code, the infrastructure and any documentation that exists, plus a conversation with whoever uses the system. The report maps what is there, flags what is risky and sets out what it would take to make the system safe to keep building on.

What Is a Code Audit? What It Covers

A code audit is a structured, independent examination of a software system's source code, architecture, dependencies, tests, security and documentation, carried out to answer a business question: is this software safe to keep building on, what are the risks, and what would it cost to fix them? That is the plain answer to what is a code audit. It is not a code review, which looks at one change at a time. It is not a penetration test, which attacks the running system from outside. It is a map of what you actually own, written by someone with no stake in the answer.

Owners ask for one when they are told their application "needs a rewrite", when a vendor or developer is leaving, when an investor or acquirer wants to see inside the box, or when an app built quickly, often with AI tools, has started to misbehave. In every one of those cases, an audit is the cheap way to replace an opinion with evidence.

What a code audit covers

Ask three firms what is a code audit and you will get three checklists. A good software code audit checklist covers six areas. The weighting changes with the system, but a report that skips any of them is incomplete.

Architecture and structure

How the system is put together: the services, the layers, where the business rules live, how data flows, and whether the structure matches what the application does today or what it did three years ago. The auditor is looking for the things that make change slow: logic duplicated in several places, modules that depend on everything, a database schema that no longer matches the domain. Our post on why small software changes take so long describes the symptoms; the audit finds the causes.

Code quality and maintainability

Consistency, readability, error handling, naming, dead code, and the size and complexity of the parts people change most. This is not about taste. It is about whether a competent engineer who has never seen the system can make a safe change in a reasonable time. Automated tooling helps here (static analysis, complexity measures), but the judgement is human.

Security

Authentication and authorisation on every route, secrets kept out of the code and the repository history, input validation, how passwords and tokens are stored, what is logged, how the application talks to the database, and whether the common classes of vulnerability are handled. An audit reads the code for these; it does not attack the live system, which is the next section's distinction.

Dependencies and infrastructure

Every library and framework the system uses, its version, whether it is still maintained, and whether it has known vulnerabilities. Also how the system is built, deployed and hosted: is there a repeatable deployment, are there separate environments, are backups taken and tested, is anything running on a version its vendor no longer supports. This section often produces the most urgent findings, because an unmaintained dependency with a known vulnerability is a risk today, not a risk eventually.

Tests and quality assurance

What automated tests exist, what they cover, whether they run, and whether the parts of the system that would cost money if they broke are protected by any of them. Many codebases have tests that nobody has run in a year. The audit checks, rather than counts.

Documentation and knowledge

What is written down, what is only in someone's head, and how many people could keep the system running if one of them left. This is where the bus factor is assessed, and in a system built by one freelancer or a small vendor it is frequently the biggest finding.

Across all six, the auditor also notes the cost of ownership: hosting, licences, the engineering time the system currently consumes just to stay up. That number is what makes the rest of the report meaningful to a business reader.

Code review vs code audit vs penetration test

These three get confused, and the confusion costs money, because people buy one when they need another.

	Code review	Code audit	Penetration test
Looks at	One change, before merge	The whole system, at a point in time	The running system, from outside
Done by	A colleague on the team	An independent engineer or firm	Security specialists
Answers	Is this change good?	Is this system safe to build on, and what would it cost to fix?	Can an attacker get in?
Output	Comments on the change	A written report with prioritised findings	A list of exploitable vulnerabilities
Frequency	Every change	At decision points	Periodically, or before a launch

A code audit includes a security pass through the code, but it is not a substitute for a penetration test on a system that handles payments or sensitive data. Equally, a clean penetration test says nothing about whether the system can be changed safely, which is usually the question an owner actually has. If you are asking what is a code audit because someone proposed one, check which of these three questions you need answered. Sometimes it is two of them.

What a code audit report should contain

The report is the product, and it is the most concrete answer to what is a code audit: a written map with prioritised findings. If it is a list of tool output or a page of opinions, you have not received an audit. Ask for, and expect:

An executive summary in business language: overall condition, the three to five most important findings, and a recommendation. Someone who will never read the rest should be able to act on this page.
A system map: what the components are, how they connect, what runs where, and what talks to the outside world. Many owners see this for the first time in an audit.
Findings, prioritised by risk, each with what was found, where, why it matters, and what it would take to fix. Severity should reflect business impact, not how interesting the bug is.
A dependency and infrastructure inventory, with versions, support status and known issues.
Test and documentation coverage, stated honestly, including what is not covered.
Options with rough effort: stabilise, modernise in place, or rebuild, with the trade-offs. This is the part that answers the question that prompted the audit.
A recommended first ninety days: what to fix first, what can wait, what should never be touched without a test around it.

What the report should not contain: a recommendation to rewrite everything with the auditor's preferred technology, unsupported by findings. If the firm that audits also builds, as we do, insist that the report stands on its own and that the options section includes paths that do not involve them.

When to get a code audit

Knowing what is a code audit matters less than knowing when to commission one. Four moments justify the cost nearly every time.

When someone tells you it needs a rewrite. A code audit before rewrite is the single most valuable use of one. Rewrites are long, expensive, and restart the clock on every bug you have already fixed. Often the audit shows that two subsystems are genuinely unsalvageable and the rest is fine, which turns a rewrite into a targeted modernisation. Our post on legacy software modernisation options sets out the choices the audit should help you pick between.

When a developer or vendor is leaving. Before handover, not after, while the people who know the system can still answer questions. The audit becomes the onboarding document for whoever comes next.

Before investment, acquisition or a major contract. Investors and acquirers increasingly want technical due diligence, and large customers sometimes require evidence of security practice. An audit you commissioned yourself puts you ahead of the one they will commission.

When an app built fast has started to wobble. Applications built under deadline, by a single freelancer, or substantially with AI coding tools often work well at launch and degrade as real usage arrives. Our post on why AI-generated code breaks in production describes the pattern. An audit tells you whether the foundation can carry the business or needs replacing before the next feature goes on top.

A fifth, quieter reason: you have never had one, the system matters to the business, and nobody can tell you with confidence what would happen if the lead developer resigned on Friday.

What to do with the findings

Part of what is a code audit for is what happens next. A report that sits in a drawer was an expensive way to confirm a worry. Turn it into a plan the week it arrives.

Fix the urgent security and dependency findings first. These are usually small, specific pieces of work with outsized risk attached, and they should not wait for the strategic decision.
Decide the strategic question the audit was commissioned for: keep, stabilise, modernise or rebuild. Use the options section and the effort estimates, and resist the pull of the clean-slate rewrite unless the report genuinely supports it.
Put tests around the parts you will change. Before any modernisation work starts, the rules that would cost money if they broke need protection, otherwise the modernisation introduces as many problems as it fixes.
Write down what the audit discovered. The system map and the inventory are documentation your organisation did not have. Keep them current.
Re-audit at the next decision point, not on a calendar. The system will change; the report is a snapshot.

This is the sequence we follow in our application modernisation work: audit, stabilise, then move the parts that need moving, without a risky rewrite of the parts that do not.

Before you accept the rewrite quote

If you remember one thing about what is a code audit, make it this: it is the cheapest way to check an expensive claim. "This needs rebuilding" is a claim. "The payments module has no tests and three critical dependency vulnerabilities, the rest is sound, and here is what it would take to fix the payments module" is a finding. Decisions made on findings are cheaper, and they are yours.

If you have a system you are unsure about, or a rewrite quote on your desk, book a free 30-minute discovery call. A senior engineer will talk through what you have and what you are worried about, and we will send a written approach, timeline and estimate for an audit within two business days.

What is a code audit, and what does it actually cover?