The Smart Contract Audit Process, Step by Step

The Seven Stages at a Glance

Every audit is adapted to the codebase, architecture, and risk in scope, but the operating sequence stays the same. Knowing it in advance helps teams plan their release dates around review and remediation instead of discovering the gap a week before launch.

Before the Audit: Contact, Scope, and Preparation

The first conversation covers the project, the target date, and the components the team expects to include. The audit team performs an initial review and responds with questions, availability, and next steps. This is where a provider should look at the actual code before quoting.

Scope definition fixes the review boundary: repositories, files, a specific commit, architecture, assumptions, exclusions, and deliverables. A fixed commit matters because it makes the report unambiguous. Development can continue on another branch, but changes to the audited scope need to be agreed.

Preparation is the cheapest security work a team can do. The better the auditors understand intended behavior on day one, the more of their time goes into finding real issues.

• A stable commit and an exact list of in-scope files.
• Architecture notes, intended behavior, and invariants the system must preserve.
• Privileged roles, upgrade paths, and deployment configuration.
• External integrations and the assumptions made about them.
• A working test suite and fixes for issues static analysis already reports.
• Known issues and explicit exclusions.

Kickoff: Setting Up the Working Relationship

At kickoff, a direct communication channel and a private reporting workflow are established, and researchers receive the final code, documentation, tests, and technical contacts. A short walkthrough of the architecture by the developers often saves days of reverse engineering.

Agree on how questions will be answered and how quickly. Researchers will ask about intent repeatedly, because the most important bugs live in the gap between what the code does and what the team meant it to do.

The Security Review: Where Findings Come From

Engagements are typically staffed with 2 to 4 researchers. Each first reviews the code independently, line by line, comparing behavior with protocol intent and tracing how value and authority move through the system. Independent review avoids everyone anchoring on the same first impression.

The team then collaborates on the highest-risk areas: accounting, access control, state transitions, integrations, and economic attack paths. Tooling supports the work, with static analysis, fuzzing and invariant tests, and targeted symbolic or formal checks where they fit. Every candidate issue is reproduced and validated before it is reported.

Material findings can be shared as they are validated, so the team can begin fixing critical issues before the review ends.

The Preliminary Report

The preliminary report records the scope and methodology and explains each confirmed finding with its severity, technical impact, evidence, and remediation guidance. Severity combines the impact of an issue if exploited with the likelihood that the conditions for exploitation are met.

Read the report with the researchers, not only on your own. Discussing root causes often reveals that several findings share one underlying design issue, which leads to a better fix than patching each symptom separately.

Fix Verification: The Step Teams Skip at Their Peril

After the team submits remediations, researchers re-test the affected paths and assess whether each original issue is resolved without an obvious regression in the reviewed area. Fixes are new code, and new code can introduce new bugs.

Each finding then receives a final status: fixed, partially fixed, or acknowledged. An honest report records an acknowledged risk as acknowledged rather than implying it was resolved.

A finding is not closed when a patch is written. It is closed when the patch has been re-tested against the original issue.

Final Delivery and What Comes After

The final report reflects the agreed scope, the reviewed commits, the findings, and their verified statuses. Publication follows the engagement terms; many teams publish to give users and integrators evidence they can inspect.

Security continues after delivery. Deploy exactly what was reviewed, monitor the system, prepare for incidents, and schedule another review for significant upgrades and new integrations. You can see how Kann Audits runs each stage on our audit process page, and the audit cost guide explains how scope affects pricing. When comparing providers, see our comparison of smart contract auditing companies.

Questions About the Audit Process

Short answers to the questions teams ask about how an audit engagement runs.