Code audit checklist: what a review should cover beyond security

Code review vs code audit: what's the difference?

Both involve reading code. They answer different questions.

A good code review checklist (naming, error handling, a test for the change) is still worth having. It keeps new problems out. A code audit finds the ones already in.

The code audit checklist, area by area

Work through the areas in order. Each check should end with a note of where the answer came from: a file, a config setting, a log, or a person who confirmed it. An answer with no source is an opinion.

1. Architecture and boundaries

• List every running part: applications, services, databases, scheduled jobs and scripts on servers. Mark which ones are in source control.
• Check whether modules talk through clear interfaces or reach straight into each other's data.
• Find where the business rules live. Rules scattered across screens, stored procedures and batch jobs are a finding.
• Compare the official diagram with what you found. For a deeper pass, use our software architecture review checklist.

2. Dependencies and versions

• List every runtime, framework, database and library, with its version.
• Look up each support date on the vendor's own lifecycle page. Anything past support goes near the top of the report.
• Run a dependency scanner for known vulnerabilities and license problems.
• Note libraries that are abandoned upstream, or forked and patched in-house.

3. Tests, and how much they're trusted

• Can the tests run from a clean checkout on any developer's machine?
• Which business-critical flows have no automated test at all?
• How many tests are skipped, or fail at random and get ignored?
• Ask the team: would you ship on a green build alone? The answer tells you more than a coverage figure.

4. Build and deployment

• Trace one recent change from commit to production and count the manual steps.
• Check that a release can be rebuilt from source control alone.
• Find configuration that exists only on the servers.
• Ask when a rollback was last done, not whether one is possible.

5. Data and integrations

• List every connection in and out: APIs, file transfers, queues and database links.
• Find tables that more than one application writes to.
• Check what happens when an integration fails halfway, and whether a retry creates duplicates.
• Name the system of record for customers, accounts and orders.

6. Documentation versus what the code does

• Pick three documented business rules and find them in the code. Check that they match.
• See whether the setup guide gets a new developer to a running system.
• Look for documents that describe features the code no longer has.

7. Security

• Credentials in source code or plain-text config files.
• Accounts shared between people, or between systems.
• Input handling on anything reachable from the internet.
• Sensitive data stored or logged without masking.
• Audit logs that record a change but not who made it.

8. Logging and operations

• What is monitored, and who gets alerted?
• Is there a runbook, and did anyone use it during the last incident?
• Would someone notice a failed overnight job before the users did?

9. Knowledge concentration

• Check version control for who has changed each module recently.
• Find the modules only one person has touched.
• Ask who could release a fix if that person were away for a month.
• Note the code nobody will change because nobody remembers what it protects.

What the audit report should contain

A report that lists every finding in file order gets read for a page and filed. A useful one has four parts.

• Findings ranked by risk. Rank by what each finding could cost the business, not by how often a pattern appears in the code.
• The evidence for each finding. The file, setting, log line or person, so your own team can check it.
• What it would take to fix. A rough size and the order of work.
• A one-page summary. Written for the people who pay for the system and don't read code.

An illustrative example of one finding: the nightly invoice job writes to the same tables as the order screen and has no automated test. Evidence: the job's source file and the database permissions. Risk: a change to either can break month-end billing without warning. Fix: add tests around the job, then route both writers through one service.

Many findings will look like familiar technical debt examples. To size them for the business, see how to measure technical debt.

Code audit tools, and what they can't judge

Tools do part of the job well. Static analysis finds code smells, duplicated code and risky patterns across a large codebase quickly. Dependency scanners match your libraries against public vulnerability databases. AI assistants can explain an unfamiliar file or point at a suspicious pattern.

What tools can't do is weigh the result. A scanner can tell you a library is out of date, but not that it sits inside the billing module the business changes every week, or that the one person who understands that module retires next spring. Deciding which findings matter still takes people who read the code and talk to the team that runs it.

What the 30-day assessment covers

The checklist above is close to what the 30-day assessment covers, applied to one system by people outside your team. It is fixed in scope, at a price agreed before we start. Over 30 days we go through the codebase and the architecture around it, map how the system fits together, find the hidden architectural debt, and flag the security and compliance gaps, including every dependency past its vendor's support date and every module only one person can change.

The report says in plain language what is broken and what it would take to fix it, ranked by risk, with the evidence behind each finding. Your own team can take it from there, or we can do the work as a separate project with its own scope and price. Either way, the report stands on its own. Not sure which system to audit first? Score your systems with a legacy system assessment.

Pick a time to talk about the system you'd audit first.