What should every finding in an audit report include?

Four fields, consistently: a severity rating on a defined scale, evidence down to file and line, the impact stated in business language as well as technical terms, and a concrete recommendation with a rough effort size. A finding without a path out is a complaint, and a claim without receipts cannot be verified, prioritized, or fixed.

How do I tell a padded audit report from a real one?

Ten minutes of skimming usually settles it. Red flags: the bulk is raw scanner output, findings lack file-and-line evidence, everything is rated severe or there is no severity scale at all, and nothing in the codebase is declared fine. A real report commits to a verdict, shows its receipts, and survives pushback on individual findings.

Is it acceptable to just not fix some findings?

Yes, and a good report plans for it with an explicit accepted category. Consciously living with a documented finding is a legitimate business decision; the failure mode is being surprised by a risk nobody wrote down. A remediation roadmap that pretends every finding must be fixed was written for an imaginary codebase.

Why should the report say what is fine, not just what is broken?

Because a clean result is information you paid for. Knowing that payment handling showed no significant issues directs your remediation budget elsewhere, and in a due diligence context it is leverage. A report with zero positive findings on a shipping product is performing rigor rather than practicing it.

What to Expect in a Code Audit Report

Q: Should severity ratings reflect how bad the code looks?

No. Honest severity is a function of exploitability and consequence. A hideous 2,000-line function that has been stable for years and touches nothing sensitive is a Low; a tidy one-liner that skips an authorization check is a Critical. Auditors who rank by ugliness are reviewing style, not auditing risk.

The report is the audit. Everything else (the access, the reading, the tooling) exists to produce this one document, and if the document is bad, the whole exercise was theater. Unfortunately, bad audit reports are common: 80-page scanner exports, vague architecture essays, severity ratings assigned by vibes.

Here’s what a genuinely useful report contains, section by section, and how to tell a real one from a padded one.

The two-audience problem

A good report serves two readers with opposite needs. The CEO or board member wants the answer in five minutes: how bad is it, what does it cost, what do we do. The engineer wants the opposite: exact files, exact lines, enough detail to open a ticket without a follow-up call.

Reports that fail usually fail by picking one audience. The all-executive version (“the codebase exhibits significant technical debt”) gives engineering nothing actionable. The all-engineer version (400 raw findings, unranked) gives leadership nothing decidable. The structure below exists to serve both.

Section 1: Executive summary

One to two pages, no jargon, written last. It should state:

The overall verdict, committed to. “The codebase is fundamentally sound with three serious security issues and significant maintainability debt in the billing module.” A summary that can’t be disagreed with (“areas of strength and areas for improvement”) is a summary that says nothing.
The finding counts by severity, and the two or three that matter most, in business terms.
What’s fine. Explicitly. “We found no significant issues in payment handling” is a result you paid for; silence about it wastes information and, in a diligence context, wastes leverage.
The recommended sequence, compressed: fix these now, these this quarter, accept these.

Section 2: Scope and method

Brief but essential: which repos and commits were reviewed (a report should be pinned to a commit hash; code moves), what was explicitly out of scope, what tooling was used, and how much was manual review. This section is what makes the report citable (to an acquirer, an insurer, or your own future team) rather than just an opinion. It’s also your protection against scope confusion later: “the audit didn’t catch X” is only meaningful if X was in scope.

Section 3: The findings (anatomy of a good one)

The core of the report. Each finding should carry the same fields, consistently:

Severity: typically Critical / High / Medium / Low, with the scale defined somewhere. Critical usually means “exploitable now or actively losing you money”; Low means “worth knowing, fine to schedule never.”
Evidence: file, line, commit or code excerpt. Not “input validation is inconsistent” but “orders.controller.ts:214 interpolates req.query.sort into the SQL string; the same pattern appears in 3 other handlers (listed).”
Impact, in business language: what actually happens if this stays. “Any authenticated user can read any other tenant’s invoices by iterating IDs” lands differently than “IDOR in invoice endpoint,” and both phrasings should be present.
Recommendation with effort: a concrete fix and a rough size (hours / days / weeks). A finding without a path out is a complaint.

A structure like this also makes the report diffable: next year’s audit can state plainly which findings were resolved, which persist, and what’s new.

What severity should mean

Watch for severity inflation: reports where everything is High because High looks thorough. Honest severity is a function of exploitability and consequence, not of how bad the code looks aesthetically. A hideous 2,000-line function that’s been stable for four years and touches nothing sensitive is a Low. A tidy one-liner that skips an authorization check is a Critical. Auditors who rank by ugliness rather than risk are reviewing style, not auditing.

Section 4: Thematic assessment

Beyond itemized findings, a good report reads the codebase’s patterns: the state of test trustworthiness, dependency health, architecture coherence, bus factor, deployability. This is where the report explains the “why” behind clusters of findings: fifteen individual validation bugs are less useful than the observation that validation has no single home, which is one fix, not fifteen. It’s also where structural topics like accumulated design debt get treated properly; for background on how that debt behaves, see technical debt, explained.

The best thematic sections also calibrate you: not just “here’s what’s wrong” but what good looks like for a codebase of your stage and size, a standard we’ve written up separately in what good code looks like to an auditor. A seed-stage MVP and a Series C platform should not be graded on the same curve, and a report that pretends otherwise is posturing.

Section 5: Remediation roadmap

The ranked to-do list, sequenced by risk-per-effort rather than by discovery order:

Now (days): live secrets in git history, exploitable authorization gaps, critical CVEs in dependencies.
This quarter (weeks): untested critical paths, the systemic fixes behind finding clusters, EOL runtime upgrades.
Scheduled (roadmap): architecture consolidation, module extractions, documentation debt.
Accepted (documented): findings you’ll consciously live with (legitimate, as long as they’re written down).

That fourth category is the mark of a report written for a real business rather than for an imaginary perfect codebase.

Red flags: how to spot a padded report

You can evaluate an audit report in about ten minutes:

It’s mostly tool output. Pages of unranked scanner findings, many inapplicable. You paid for triage; you received a export button.
No file-and-line evidence. Claims without receipts can’t be verified, prioritized, or fixed.
No severity scale, or everything is severe. Undecidable input isn’t input.
Nothing is fine. A report with zero positive findings on a shipping product is performing rigor, not practicing it.
It doesn’t survive questions. A good auditor welcomes pushback on findings and either defends them with evidence or downgrades them. Defensiveness is diagnostic.

For context on where in the process the report gets built (and why the pre-report questions call with your team matters so much to its accuracy), see how a professional code audit actually works.

Get a free code audit

The fastest way to calibrate all of the above is to hold a real report about your own code. Webisoft produces exactly the kind of document described here, free: a Webisoft engineer manually reviews your repository and sends a written findings report: severity-ranked, evidence-backed, with a remediation order. Genuinely free, no obligation; the report is yours regardless of whether we ever speak again.

Get a free code audit and judge our report against this article. We wrote the rubric; we’re happy to be graded on it.