Code Audit Checklist: 12 Sections for Founders (2026)

Why founders need a code audit checklist

A code audit checklist exists so that inheriting, buying, or scaling software becomes a decision backed by evidence instead of optimism. Founders rarely get burned by code they wrote; they get burned by code someone handed them with a confident smile. Poor software quality cost the US an estimated $2.41 trillion in 2022, with roughly $1.52 trillion of that in accumulated technical debt (CISQ). That debt does not announce itself. It sits in a repository looking fine until the day you try to scale, sell, or hand it to a new team.

We have shipped 250+ software products since 2005, and a large share of them started as someone else's codebase that we had to inspect before we would touch it. That experience is where this checklist comes from. It is the same 12-section list our auditors run for clients in M&A diligence, vendor handovers, and pre-scaling reviews. Below you get the checklist, the tools, the report template, and the red flags that move deal prices — not a definition and a shrug. If you want the definitional groundwork first, our companion guide on what a code audit is and how to conduct one covers the fundamentals.

Here is the whole thing at a glance before we break it down section by section.

Figure 1. The 12-section code audit checklist at a glance — accent colour marks how severe the typical finding in each section tends to be.

What a code audit checklist actually is

A code audit checklist is a fixed set of sections an independent reviewer scores a codebase against, so two auditors reach the same verdict and nothing important gets skipped. Without a checklist, an audit becomes whatever the reviewer happened to notice that week. With one, it is a repeatable process: every section gets inspected, rated, and turned into a finding with a severity and a fix.

The checklist is not the same thing as running a scanner. Tools generate raw signal; the checklist is the judgement layer that decides what matters for your situation. A missing test suite is a shrug for a throwaway prototype and a deal-breaker for a payments platform. Same finding, different verdict — and only a human working through a structured list can tell them apart.

Code audit vs technical due diligence vs pentest

A code audit is a white-box review of source code and its surrounding practices; technical due diligence wraps that audit in commercial questions a buyer cares about; a penetration test attacks the running system from the outside. They overlap, but buying the wrong one wastes money and leaves gaps. Here is how they line up.

A mature buyer runs all three at different moments: the code audit to grade the asset, diligence to price the deal, and a pentest before go-live to confirm the running system holds. This article is about the first one, which is the foundation the other two lean on.

The four triggers for a code audit

Four situations justify a code audit, and each one scopes the work differently: vendor replacement, M&A due diligence, pre-Series-A scaling, and post-incident review. Tell the auditor which one you are in — the depth and the sections that matter change completely.

1. Vendor replacement. You are firing the current dev shop. Before the new team starts, audit what you are inheriting. This catches abandoned tech debt, undocumented hacks, missing tests, and broken CI/CD — the exact things the outgoing vendor will not volunteer in handover. Pair it with a clean source-code handover process so nothing walks out the door with them.

2. M&A technical due diligence. The acquirer commissions the audit before signing. Findings re-price the deal, add escrow holdbacks, or kill it. A seller who refuses audit access has just told you something; treat that refusal as a finding in itself.

3. Pre-Series-A scaling readiness. A seed-stage MVP is about to meet real traffic. The audit finds the scaling cliffs — the N+1 query, the single database, the synchronous call in the hot path — before they find you during the launch you raised money to fund.

4. Post-incident review. After a breach, outage, or data loss. A forensic audit identifies root cause, lateral risk, and a remediation plan. This one is often legally mandated, and it focuses hard on security, logging, and the failure paths nobody tested.

Figure 2. The trigger tells you the scope. A board or buyer needs the full audit; your own team scaling up can safely narrow it.

The 12-section code audit checklist

The full code audit checklist runs twelve sections, from architecture down to cost of ownership, and takes about eleven auditor-days on a moderate codebase. Figure 1 above is the map; the table below is the detail, with what each section inspects and roughly how long it takes a single senior auditor.

That is roughly eleven working days for one senior auditor on a moderate codebase. We usually run two auditors in parallel and finish in five to seven calendar days, with the second auditor cross-checking findings so false positives don't reach the report. Section 3 leans on the current OWASP Top 10:2025, where software supply-chain failures climbed to the number-three risk, which is precisely why open-source licences and dependency provenance now get their own hard look in any acquisition.

Those sections are not abstractions. Log4Shell (CVE-2021-44228, 2021) turned a single logging dependency into a remote-code-execution hole across millions of applications. Equifax's 2017 breach traced back to one unpatched Apache Struts library (CVE-2017-5638). Heartbleed (CVE-2014-0160, 2014) was a two-line bug in OpenSSL that leaked memory from a large slice of the internet. Every one of those is a section 3 or section 10 finding at heart: a dependency nobody was watching. An audit that walks the checklist catches that class of problem while it is still a line item, not a headline.

How deep should each section go?

Depth scales with codebase size and with the cost of being wrong, not with a fixed template. On a 50k-line MVP, every section gets a day or less; on a 500k-line multi-service platform, security and architecture alone can each take a week. The trick is to spend auditor-hours where a miss is expensive: a payments or health platform earns a deep compliance and security pass, while an internal tool does not.

The other lever is non-functional requirements. An audit can only judge whether a gap is acceptable if it knows the target — the SLA, the concurrency ceiling, the regulatory posture. Bring a written spec, or the auditor is guessing. Our non-functional requirements checklist is a good way to write that target down before the audit starts.

Five red flags that kill an acquisition

Five findings do more than lower a score — they re-price or end deals, and all five surface in the first three days of an audit. Each one is cheap to detect and expensive to ignore.

1. No source-code escrow. If the seller has not deposited code and build instructions with a neutral escrow agent, recovery on bankruptcy or a vendor's refusal to cooperate is uncertain. The acquirer should require escrow setup before close.

2. Single-developer keys to the kingdom. One person runs every deploy from a personal laptop and holds all credentials in their head. That person leaving means the company stops shipping. Auditors call it a bus factor of one, and buyers price it like a loaded gun.

3. PII or PHI in plain-text logs. Patient names, customer emails, or card numbers sitting in application logs. A secrets scan finds it in minutes, and it is a GDPR, HIPAA, or PCI-DSS violation with immediate breach exposure. For anything health-related, our HIPAA and SOC 2 guide shows what "done right" looks like, and projects like CirrusMED are where we have shipped it under real compliance pressure.

4. Hidden proprietary frameworks. The dev shop wrote its own ORM, framework, or component library and buried it inside the deliverable. Nobody outside that team can extend it — vendor lock-in wearing a different hat.

5. Consumer-grade SaaS as critical infrastructure. Production data flowing through a free Zapier tier, business logic in a shared spreadsheet, payments through someone's personal Stripe account. Common in pre-MVP, lethal at acquisition.

Figure 3. Every one of these surfaces inside the first three days, which is why a five-day red-flag scan is enough to walk away early.

The tools we use

Tools do the mechanical passes; the auditor does the judgement. A real audit layers static analysis, dependency scanning, and dynamic testing, then a human decides what the output means for your context. Here is the stack, by layer.

We also use Claude and other frontier models to read source for architectural insight and hotspot detection — in addition to the tools above, not instead of them. Be honest about what that buys you: a 2025 controlled study found experienced engineers were about 19% slower using AI tools on code they already knew, so we treat AI as a fast first reader, never the final judgement. That same nuance runs through our piece on AI in software testing and technical debt.

What a two-week audit produces

A two-week audit produces a 30–60 page report with four parts: an executive summary, findings by section, a remediation plan, and appendices with raw tool output. The point is a document a non-engineer board and an incoming engineering team can both act on.

Executive summary (1 page). Top three risks, top three strengths, total remediation estimate, and a plain recommendation: buy as-is, buy with a holdback, remediate first, or walk away.

Findings by section (2–6 pages each). Every finding carries a severity, an impact description, evidence (a code snippet, a log excerpt, a screenshot), and a recommended fix. Severity uses CVSS v4.0 for anything security-related so scores are comparable across audits.

Remediation plan (2–4 pages). A prioritized list of work with effort estimates, suggested order, and dependencies. This is the part that turns complaints into a project.

Appendices. The raw SonarQube report, Snyk scan, dependency tree, and infra cost breakdown. Delivered as PDF plus machine-readable JSON so a buyer's diligence tooling can ingest it.

A finding is only useful if an engineer can act on it, so each one pairs the evidence with a fix. Here is what a single critical finding looks like on the page.

# Vulnerable: input goes straight into the query
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

# Fix: bind the parameter, never concatenate
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))

The same shape repeats across sections. Three more findings, in the shorthand a founder can skim, each tagged with severity, a CVSS score, and its OWASP or CWE category:

# Vulnerable
STRIPE_KEY = "sk_live_9a8b7c6d5e4f"
# Fix: read from the environment, then rotate the exposed key
STRIPE_KEY = os.environ["STRIPE_KEY"]

# Vulnerable
invoice = Invoice.get(request.args["id"])
# Fix: scope every lookup to the authenticated user
invoice = Invoice.get(id=request.args["id"], owner=current_user)

# Vulnerable: CVE-2021-44228
"org.apache.logging.log4j:log4j-core:2.14.1"
# Fix: upgrade past the patched release (2.17.1+)
"org.apache.logging.log4j:log4j-core:2.24.3"

Figure 4. Two auditors run in parallel and cross-check before the report ships — parallelism is where the calendar time is won.

How to brief an external auditor

Brief an external auditor by handing over context and read-only access up front, because the auditor cannot find what they cannot see. Five things make the difference between a sharp audit and a shallow one.

1. Disclose the trigger. M&A, vendor replacement, scaling, or incident — each scopes differently. Tell the auditor which; don't make them guess.

2. Give read-only access to everything. All branches, CI/CD, infrastructure (read-only IAM), monitoring dashboards, and billing. Gaps in access become gaps in the audit.

3. Provide the target context. Who the users are, the SLA, the regulatory posture. Without it, the auditor can't judge whether a non-functional gap is critical or fine.

4. Book one hour with the engineering lead. An interview catches undocumented context an audit would otherwise miss — and if the team refuses, that is itself a finding.

5. Keep the auditor independent. The team that wrote the code cannot grade it. Use a third party, such as a dedicated team you are considering hiring next.

How to scope remediation after the audit

Scope remediation by triaging findings by severity, estimating each in person-weeks, and adding a buffer — the audit hands you the inputs, you build the budget. Critical findings (security holes, compliance violations, single points of failure) ship first, in weeks one to four. High findings (coverage gaps, monitoring, scaling cliffs) follow in weeks four to twelve. Medium and low roll into a quarterly tech-debt sprint.

The arithmetic is simple, and worth doing out loud. Sum the person-week estimate for each finding, multiply by your blended rate, and add a 15% buffer for discovery. On a 108k-line SaaS, six weeks of critical work plus eight of high plus four of medium is eighteen person-weeks; at $6,000 per week that is $108,000, and a 15% buffer brings the remediation budget to $124,200. A comprehensive audit typically surfaces a remediation bill of 15–30% of the original build cost. For the estimation discipline behind those numbers, our CTO's software estimation guide goes deeper.

Figure 5. The remediation budget, built from the audit's estimates, next to the rebuild-or-remediate decision line.

Remediate or rebuild? The 50% rule

Rebuild instead of remediating when the remediation budget tops roughly 50% of a clean rebuild — below that line, fixing is almost always cheaper and faster. In the worked example above, $124,200 of remediation against a $260,000 rebuild is under the halfway mark, so you fix. Flip the numbers and the maths flips with them.

The rule is a starting point, not a verdict. A codebase built on an abandoned framework or a language nobody hires for can justify a rebuild even under the 50% line, because remediation buys you a cleaner version of a dead end. When rebuild is on the table, our guide on what to do with legacy code walks through the strangler-fig path that avoids a risky big-bang rewrite.

Mini case: an inherited platform, stabilized

A Milan-based simultaneous-interpretation company came to us with a real-time platform they had inherited and could not keep stable. Sessions dropped, the real-time flows were fragile under load, and the previous team was gone. Before we wrote a line of new code, we audited what was there: architecture, the WebRTC and real-time media streaming path, the database, and the operational gaps.

The audit pointed straight at the core real-time layer and a handful of single points of failure. We stabilized those flows first, then extended the platform for reliable high-load multilingual events, adding a machine-translation voice-over fallback so a session keeps running even when a live interpreter drops. That is the vendor-replacement trigger playing out exactly as the checklist predicts: audit first, stabilize the criticals, then build.

Rafiky now runs 30,000+ events with 6,000+ professional interpreters across 200+ languages, is ISO 27001 certified, and scales to 5,000 participants per session. It is one of 250+ products we have shipped since 2005, and a clean example of why the audit comes before the roadmap. You can see more of that work in our project portfolio, or book a call if you have an inherited platform of your own.

Pick your audit depth in five questions

Pick your audit depth by answering five questions about the trigger, the size, the compliance posture, team access, and urgency. Run them in order and the scope falls out.

If two of those answers push toward "deep," trust the deeper one. An audit that comes back too thin is worse than no audit, because it hands you false confidence at exactly the moment you're writing a cheque.

Pitfalls to avoid

1. Self-audit by the shop being audited. A conflict of interest, always. The team that wrote the code has every incentive to grade it kindly. Use an external auditor.

2. Skipping the engineering interview. An audit with no team interview misses 20–40% of the context that explains why the code looks the way it does. One hour pays for itself.

3. Treating tool output as the deliverable. A SonarQube export is not an audit. Tools generate noise; the audit interprets, prioritizes, and decides what is acceptable for your situation.

4. No remediation plan attached. Findings without effort estimates and an order of work are complaints, not action items. The plan is the reason you paid.

5. Trusting the seller's own attestation. A SOC 2 badge describes controls on paper. Audit against the controls that are actually present in the code — the two do not always match.

KPIs that prove the audit paid off

Quality. Critical-finding count (finding them is the job, not avoiding them) and the false-positive rate on findings, with a target under 10% retracted after engineering review.

Business. Audit-driven price changes in M&A, and avoided remediation cost in vendor replacement — a good audit routinely returns two to five times its fee.

Reliability. Completion within the budgeted days, and the accuracy of the remediation estimate measured at six months, with a target of plus or minus 15%.

When a code audit is overkill

A code audit is overkill when the code is disposable, the team already owns it, or you are only screening early options. Honesty here builds more trust than a reflexive "always audit," so here are the three cases where we tell founders to save the money.

Pre-MVP or hackathon code. The codebase is throwaway by design. Skip the audit and rebuild after product-market fit. Auditing a prototype for maintainability grades it against a bar it was never meant to clear — the same trap teams fall into with fast AI-generated app code.

Continuing with the same team. If you are happy with the team and just adding features, the team already owns the codebase and its risks. An audit adds process, not insight.

Screening many targets. Evaluating thirty acquisition candidates when only three will close? The one-page red-flag scan is the right tool. Save the full audit for the targets that survive it.

FAQ

What to read next

Ready to audit a codebase you don't yet trust?

A two-week code audit costs $18–45k and pays for itself two to five times over in M&A re-pricing or vendor-replacement savings. Work the 12-section checklist, pair tool output with judgement, keep the auditor independent, and insist on a remediation plan with effort estimates — not a list of complaints. Five red flags surface in the first three days: escrow gaps, single-developer dependencies, plain-text PII, hidden proprietary frameworks, and consumer-grade SaaS holding up production. Catch them before they catch you.