Most Web3 organisations treat a security audit as a procurement event: find a firm, agree a price, wait for the report, publish the badge. That approach explains why so many exploited protocols held a valid audit report at the time they were drained. The audit itself was never the point of failure. The process around it was: who was engaged, what they were asked to look at, how the findings were handled, and whether anyone actually closed them out.
Managing third-party security audits well is an operational discipline, not a single purchase decision. It sits squarely inside the People, Process and Technology framework that governs all effective security programmes. The people dimension covers who selects the vendor and who owns remediation. The process dimension covers scoping, information handling, report classification and follow-up. The technology dimension covers the tooling used to track findings and verify fixes. Organisations that get the audit lifecycle right treat it as a managed programme with named owners at every stage, not a document that arrives once and gets filed away.
This guide sets out that lifecycle from the buyer's side: how to qualify a vendor, how to write a scope that produces useful results, how to protect sensitive information during the engagement, how to manage the report once it lands, and how to make sure findings actually get fixed. This is the part of blockchain security audit work that almost never gets discussed, because most content on the subject is written from the auditor's perspective rather than the client's.
Vendor Qualification: How to Assess a Web3 Security Firm
Selecting an audit vendor is a due diligence exercise in its own right, and it deserves the same rigour an organisation would apply to any critical supplier. The people dimension matters most here: a firm's brand and marketing say little about who will actually be assigned to your codebase or your infrastructure.
Ask for the specific individuals who will perform the work, not a generic team biography. Review their track record on comparable systems: a firm with deep experience in ERC-20 token contracts is not automatically qualified to assess a novel consensus mechanism, a cross-chain bridge, or the operational security of a custody stack. Request references from past clients who had a similar system profile, and ask those references directly whether the auditor found anything material and whether post-audit support was responsive.
Check the firm's own disclosure history. Have any protocols they audited been exploited shortly after receiving a clean report, and if so, was the exploited vulnerability inside or outside the agreed scope. This is not about penalising a firm for an isolated miss; it is about understanding how they respond when their work is publicly challenged, since that behaviour tells you a great deal about how they will behave with you.
Vendor qualification should also assess the firm's own operational security. A security auditor that stores client source code in an unencrypted shared drive, uses personal devices for client communications, or has no formal incident response process of its own is a liability, regardless of how skilled its reviewers are. This connects directly to broader vendor risk management practice: the auditor is itself a third party with access to your most sensitive assets, and should be assessed with the same standard you would apply to a custodian or an infrastructure provider. A structured security due diligence questionnaire covering data handling, staff vetting, subcontracting practices and breach history should be a standard part of vendor selection, not an afterthought reserved for larger engagements.
Finally, resist the temptation to select purely on price or turnaround speed. A firm quoting a fraction of the market rate for a short, fixed-fee engagement on a complex system is signalling something about the depth of review you will receive. Audits are not commodities, and the cheapest bid is rarely the best defence against the kind of loss a serious vulnerability can cause.
Scoping for Results: Writing an Engagement Brief That Works
A vague scope produces a vague audit. The single most common reason an audit misses a critical issue is that nobody defined clearly enough what was actually being tested, and the auditor reasonably worked within the boundaries they were given.
An effective scope of work should specify the exact commit hash or version of the code under review, the network and environment (mainnet fork, testnet, staging), and any out-of-scope components with a clear rationale for the exclusion. If third-party libraries, oracles, bridges or upgrade mechanisms are excluded, that decision should be documented and owned by someone internally, not left implicit.
Scope should extend beyond smart contracts where relevant. Many of the largest losses in Web3 have originated from compromised signing infrastructure, misconfigured multisig thresholds, exposed private keys, or social engineering against employees with privileged access, none of which a contract-only audit will ever surface. If the engagement is meant to cover operational security, key management practices, or infrastructure configuration, say so explicitly and ensure the vendor has the relevant capability, since not every contract-focused firm can meaningfully assess a signer's device hygiene or a custody workflow.
Include acceptance criteria and a communication plan in the brief. Define how findings will be reported as they are discovered rather than only at the end (critical and high severity issues should be flagged immediately, not held until a final report), how many rounds of clarifying questions are expected, and what format the final deliverable will take. Agree a fixed delivery date and a process for what happens if the audit uncovers issues so severe that the engagement needs to expand or pause.
A well-scoped brief also states what "done" looks like from a remediation perspective, tying the engagement forward into the re-testing phase described later in this guide, so that the vendor relationship does not end the moment the report is delivered.
Information Security During the Engagement
An audit engagement is, by design, a period during which an external party has privileged access to your most sensitive systems: source code, architecture diagrams, sometimes staging environments with real or near-real data. This is a defined window of elevated risk that needs to be managed with the same discipline applied to any other privileged access grant.
Before any material is shared, a mutual non-disclosure agreement should be in place covering confidentiality of code and findings, restrictions on how the vendor may use access, and data destruction commitments once the engagement closes. Access should be provisioned on a least-privilege basis: read-only repository access scoped to the relevant branches, time-boxed credentials for any test environments, and no standing access that persists after the agreed engagement window.
Internally, treat the existence and details of the audit as sensitive information in its own right. Announcing publicly that a specific vulnerability class is under review, or discussing draft findings in channels visible to a wide internal audience, creates a window in which an attacker could act on information the organisation itself has not yet acted on. Limit internal distribution of engagement details to those with a direct need to know, consistent with the same classification discipline that should govern the report once delivered.
Where the audit involves live infrastructure rather than a static code review, agree explicit rules of engagement covering testing windows, notification protocols before any active exploitation attempts, and an emergency contact who can pause the engagement immediately if something goes wrong. This is the same discipline that governs red team engagements, and it applies equally to any third-party assessment that touches production or near-production systems.
At the close of the engagement, confirm in writing that the vendor has destroyed or securely returned all client materials, credentials have been revoked, and any temporary access has been removed. This step is frequently skipped once the report has been received, leaving stale access sitting unmonitored long after anyone is thinking about the engagement.
Report Management: Classification, Distribution and Retention
A security audit report describing unpatched vulnerabilities is one of the most sensitive documents an organisation will produce or receive. It should be handled with a classification scheme proportionate to that sensitivity, not treated as a routine internal memo.
On receipt, the report should be classified immediately, typically as strictly confidential or restricted, and stored in a system with access controls and audit logging, not a general shared drive or an email thread with a broad distribution list. Draft reports containing unresolved critical or high severity findings should never be forwarded without encryption, printed and left in shared spaces, or discussed in channels that include contractors, partners or other external parties without a specific need to know.
Access to the full report should be limited to those who need it to act: the engineering leads responsible for remediation, the security or risk function, and the executives who need visibility into residual risk. Where a summarised or redacted version is needed for board reporting, investor updates, or public disclosure, that version should be prepared deliberately, with technical detail on unresolved issues removed, rather than the full technical report being shared more broadly than necessary.
Retention matters as much as initial handling. Audit reports and their associated remediation evidence should be kept for the operational lifetime of the audited system plus a reasonable period beyond decommissioning, since they may be needed for incident investigations, insurance claims, regulatory enquiries or investor due diligence long after the original engagement is forgotten. This retention obligation should sit inside a formal document and records policy rather than depending on an individual's personal archive of PDFs, which disappears the day that person leaves the organisation.
The value of a security audit is not in the report document. It is in the remediation actions that follow. Too many organisations file a completed audit report, celebrate the milestone, and never verify whether the critical findings inside it were actually fixed.
Remediation Tracking: From Finding to Fix
Every finding in an audit report needs an owner, a target date, and a status that is tracked to completion, ideally inside the same issue tracking system engineering already uses for other work rather than a separate spreadsheet that quietly goes stale. Treating remediation as a project with accountability is the process control that converts an audit from a compliance artefact into an actual risk reduction exercise.
Prioritise remediation by severity and exploitability rather than by ease of fix. It is tempting to close out several low-severity findings quickly to show progress while a single critical issue remains open because it requires a more invasive change. Resist that temptation: a dashboard showing twenty resolved low findings and one open critical finding is not a good news story, it is the definition of residual risk that matters.
For findings the organisation decides not to fix, whether due to cost, a compensating control elsewhere, or a judgement that the risk is acceptable, document that decision formally with named sign-off from someone with the authority to accept the risk. An unaddressed finding that was never formally accepted is simply an open vulnerability with no owner; a finding that was reviewed and consciously accepted with documented reasoning is a governed risk decision. The difference matters enormously if the issue is later exploited and the organisation needs to demonstrate what it knew and what it decided.
Aggregate remediation data across engagements over time. If the same category of finding, say, access control issues in upgrade mechanisms or inconsistent input validation, keeps appearing across successive audits from different vendors, that is a signal of a systemic gap in the development process rather than a series of isolated bugs, and it warrants a process fix upstream rather than repeated point fixes downstream.
Re-Testing and Verification: Closing the Loop
A fix that has been implemented but never independently verified is an assumption, not a resolved finding. Re-testing is the step that converts a claimed fix into a confirmed one, and it is the stage most frequently skipped once budgets and attention have moved on to the next priority.
Wherever possible, re-testing should be performed by the original auditor, since they already understand the system and the original vulnerability, which makes verification faster and more reliable than starting from scratch with a new firm. Build the cost and timeline for a re-test into the original engagement scope and budget from the outset, rather than treating it as an optional add-on that gets cut when the invoice arrives.
Verification should confirm not only that the specific vulnerability has been addressed, but that the fix has not introduced a new issue elsewhere, which is a common and underappreciated failure mode, particularly with fixes made under time pressure after a critical finding. A patch applied hastily to close one finding has, on more than one occasion, opened a different and equally serious one.
Only once re-testing confirms a fix should a finding be marked closed in the tracking system. Until that point, it should remain open and visible to whoever owns risk oversight, regardless of how confident engineering is that the fix works. This discipline is what separates organisations that treat audits as a genuine control from those that treat them as a one-time report to file away.
Audit Programme Governance: Scheduling, Cadence and Budget
Individual audits are point-in-time assessments of a system that continues to change after the engagement ends. Programme governance is what turns a series of one-off engagements into continuous assurance that keeps pace with that change.
Establish a cadence tied to material events rather than an arbitrary calendar: before any mainnet deployment, after any significant protocol upgrade or new feature that touches value transfer, and at a minimum annual interval even for systems that have not materially changed, since the threat landscape and auditor tooling both continue to evolve. Systems handling substantial value, or those that have previously been targeted, warrant more frequent review than a low-value, low-traffic component.
Budget for the full lifecycle, not just the initial engagement fee. That means allocating funds up front for re-testing, for a second independent review from a different firm on high-value systems, and for a rolling bug bounty programme that extends coverage between formal audits rather than leaving the system unassessed in the gaps. Organisations that treat the audit line item as a single fixed cost consistently underfund the parts of the process that matter most for actually reducing risk.
Ownership of the audit programme should sit with a named individual or small group, not be distributed informally across whoever happens to be leading a given project at the time. That owner is responsible for maintaining the vendor roster, tracking the status of every open finding across every past engagement, reporting programme-level metrics to leadership, and ensuring that lessons from one audit inform the scope of the next. Without that continuity, each new engagement starts from zero, and the organisation never builds the institutional memory that makes its security posture genuinely improve over time.
Frequently Asked Questions
How many security audits should a Web3 project commission before launch?
Most protocols handling material value need at least two independent audits from different firms before mainnet launch, plus a final review of any code changed after the first audit. A single audit from a single vendor creates a blind spot: every firm has methodological gaps and areas of specialism, and no one review team catches everything. Layer in a bug bounty programme after launch to extend coverage on an ongoing basis rather than treating audits as a one-off gate.
Should we sign a non-disclosure agreement with a security audit vendor?
Yes, and it should be in place before any code, credentials or architecture documentation changes hands, not after the engagement starts. The NDA should cover confidentiality of source code and findings, restrict the vendor's use of your systems to the agreed scope, and specify data destruction timelines once the report is delivered and accepted. Reputable firms will have their own template ready and will not treat this as a point of friction.
Who should have access to a security audit report inside the organisation?
Access should be restricted to those who need it to act on the findings: engineering leads responsible for remediation, the security or risk function, and relevant executives. Draft reports containing unpatched critical vulnerabilities should never be forwarded by email without encryption, posted to shared drives with broad permissions, or discussed in channels that include external parties. Treat the report itself as one of the most sensitive documents the organisation holds until fixes are verified.
What is the difference between a finding being reported and a finding being resolved?
A finding is reported when the audit vendor documents it in the report with a severity rating and recommendation. It is resolved only when the fix has been implemented, deployed, and independently verified, ideally by the original auditor through a re-test. Many organisations conflate the two and treat the delivery of the report as the end of the process, which is precisely the gap that leads to exploited vulnerabilities that were previously identified but never closed out.
How long should a Web3 organisation retain historical audit reports and remediation records?
Audit reports and their associated remediation evidence should be retained for the lifetime of the audited system plus a reasonable extension beyond decommissioning, typically several years, to support incident investigations, insurance claims, regulatory enquiries and investor due diligence. Retention should sit within a formal document classification and records policy, not depend on individual employees keeping personal copies of PDFs.