What a good audit report actually contains
An audit is not the PDF. The work is the thinking that happened against your code. But the report is the only part you keep, the only part your investors and users see, and the thing you will reach for when something goes wrong at 3am. A report you can act on looks very different from a checklist with a logo on it, and the difference is visible before you understand a single finding.
If you are choosing an auditor or reading a draft, here is what a useful one carries.
Scope pinned to a commit
The first page should state exactly what was reviewed: the repository, the precise commit hash, the files in scope, and the files deliberately left out. A report that reviewed "the contracts" without a hash is describing a moving target. Code changes after the review, and without a fixed commit nobody can later tell whether a bug was in what the auditors saw or in something added the week after.
A threat model, not just a finding list
Good reports say what the system was assumed to protect and against whom. Which roles are trusted, what an attacker is assumed to control, what is out of scope by design. This matters because most severe findings are not exotic bugs. They are a mismatch between what the team assumed and what the code permits, and you can only see the mismatch if the assumptions are written down.
Findings you can reproduce
This is the line between a report and an opinion. Every finding of consequence should come with enough to reproduce it: the conditions, the steps, and ideally a proof-of-concept test that fails against your code. We hold ourselves to that bar, for reasons we wrote up in gating disclosure on a working proof. A claimed vulnerability you cannot reproduce is a claim, and acting on claims wastes engineering time chasing ghosts while real issues wait.
Each finding should also carry a severity with a stated rationale, the affected code location, and a concrete remediation. "Consider reviewing access control" is not remediation. "Add the onlyOwner modifier to setFeeRecipient at line 142, since it currently lets any caller redirect fees" is.
Honest severity, including the absence of findings
A wall of low-severity informational notes can be a way to look thorough while saying nothing. The reverse also happens: inflating severities so the report appears to have earned its fee. Both erode trust. A credible report ranks issues by realistic impact and likelihood, is willing to report that a contract was sound in an area, and does not pad. The point is an accurate picture of your risk, not a high finding count.
A clear statement of what was not covered
This is the section weak reports omit, and the one experienced readers turn to first. No audit is exhaustive. Time was finite, some paths were deprioritized, certain assumptions were taken on trust, and some components were out of scope. A report that names its own limits is telling you where residual risk lives, so you can decide whether to extend the review or accept the gap. A report that implies it found everything is the less trustworthy of the two, because the claim cannot be true.
Remediation review
Findings are half the engagement. The other half is confirming the fixes work and introduced nothing new. A useful report records which findings were resolved, which were acknowledged and accepted, and which remain open, each against the fix commit. A fix is a code change like any other, and a change made under deadline pressure is exactly the kind that needs a second look.
The short version
A report worth its fee is reproducible, scoped to a commit, honest about severity, and explicit about what it did not examine.
Everything above is something you can check on the first read, before you have the context to evaluate the findings themselves. If a report pins its scope, hands you tests you can run, ranks issues by real impact, and states its own limits, the team behind it did the work. If it does none of those, the logo on the cover is doing a lot of load-bearing.
If you want a review whose report you can actually act on, with reproducible findings and verified fixes, that is the engagement we run. See how we work or start a conversation.