How Long Does a Code Audit Take? A Realistic Answer

A code audit takes anywhere from a single day to several weeks, and the honest answer depends on three things: how big the codebase is, how much access you have, and how deep you actually need to go. A tooling-driven overview of a mid-size repo is a day. A due-diligence review that has to hold up in an acquisition is one to two weeks. A forensic audit of a large, undocumented system by people who did not build it can run a month. The mistake is picking a depth that does not match the decision the audit is supposed to inform.

What actually drives the timeline

Three variables move the number more than anything else. Codebase size, obviously, but not linearly, because a small tangled repo can take longer than a large clean one. Access is the quiet one: full access to clone, run, grep, and read the git history is fast, while read-only data room access with a deadline forces a slower, more constrained review. And depth, which is really a function of the decision. An audit that informs a "should we refactor" call needs less certainty than one that informs "should we wire five million dollars."

Match depth to stakes. Spending three weeks to confirm a small internal tool is fine is waste. Spending a day on a codebase you are about to bet the company on is negligence. Decide the decision first, then the depth, then the timeline falls out.

The one-day audit

A day gets you an automated overview plus a skim. A repo intelligence scan produces the coupling map, hotspot list, ownership concentration, dead-code estimate, and dependency health in an afternoon, and a human spends the rest of the day reading the structure and the worst hotspots. This is enough to answer "is this roughly healthy and where is the pain," which is often all you need to decide whether a deeper audit is even warranted.

The one-day pass is also the right first step in a longer engagement, because it tells you where to aim the expensive human hours. It is the same logic as running repo intelligence before you refactor: the scan is not the answer, it is the targeting.

The one-to-two-week due diligence audit

When the audit informs a real decision with money attached, budget one to two weeks. That buys the automated pass plus a human going deep on the load-bearing modules, reading the tests to see if they assert anything real, checking the dependency tree for drift and supply chain risk, reading the git history for authorship and pacing red flags, and turning it all into a findings list ranked by cost to fix.

This is the tier most acquisition and vendor reviews should sit at. Less than this and you are guessing. More than this rarely changes the decision, because after two weeks you have found the expensive problems, and the remaining time only refines estimates you can already defend. Use the repo due diligence checklist to make sure the two weeks cover the right ground instead of drifting into whatever the reviewer finds interesting.

The multi-week forensic audit

The month-long audit is for large, old, undocumented systems where the stakes are high and the code is genuinely opaque, or for regulated products where you need security depth. Here reviewers who did not build the system have to reconstruct its logic, which is slow. This is the tier where you are auditing a codebase you inherited at full depth, and the time goes into understanding, not just measuring.

Most audits do not need this, and buying it when you do not is how audits get a reputation for being slow and expensive. Reserve it for when the decision genuinely requires that much certainty.

The real answer to give a stakeholder

When someone asks how long a code audit takes, do not quote a number, ask what decision it informs. A gut check is a day. A deal is a week or two. A forensic reconstruction is a month. The audit that goes wrong is not the one that took too long, it is the one whose depth did not match the decision, either burning weeks on a low-stakes call or rushing a bet-the-company review into an afternoon. Size the audit to the decision, and the timeline stops being a guess.