Audit Drift Checklist

This checklist structures a decision. It does not make one. Every severity 2+ item requires a named human to sign off — the template will not pretend an LLM approved anything. It is a review aid, not a security certification: completing it does not mean a protocol is safe, fully audited, or free of vulnerabilities. The artifact is the product.

What this checklist does

One pass over your protocol that produces a defensible re-audit decision instead of a vibe. You diff the audited snapshot against what is running now, classify every gap, attach evidence, and let a human make the call on the record.

When to use it

• It has been more than 90 days since your last audit and you have not mapped the drift. (Primary trigger.)
• Before a risky upgrade, migration, or new-chain deployment.
• After a role, multisig, or oracle change.
• Before governance executes a material proposal.
• When an auditor or counterparty asks "is this the system you were audited on?" and you cannot answer in one page.
• On a recurring cadence, so the report is cheap and boring instead of expensive and urgent.

How to use it

Suggested cadence

Checklist template

The full blank template is in the panel — use Copy template or Download .md and drop it in your repo. One file per audited snapshot. It captures review metadata, the audited and current snapshots, a per-category drift review, the drift register, severity, an evidence log, the human decision, and the one-page report.

Drift category taxonomy

Eight places drift hides. Walk each; a "no" you cannot back with evidence is a drift item.

• Code — New contracts deployed via factories since the audit? Storage layout changed under any proxy? Compiler or optimizer settings changed? New external libraries imported?
• Config — Fee parameters, thresholds, or caps changed? Timelock delays shortened? Pause guardians reassigned?
• Roles — Multisig signers added or removed? Threshold (m-of-n) changed? Any role moved from a contract to an EOA?
• Oracle — Price feed source or heartbeat changed? Fallback oracle added? Staleness or deviation bounds altered?
• Integrations — New protocols called or integrated? An integrated dependency upgraded or migrated? New approvals granted to external contracts?
• Governance — Voting parameters changed? Emergency powers added? Treasury controls altered?
• Deployment — Deployed to a new chain? New proxy implementation pushed? New pools or markets spun up via factory?
• Assumptions — Re-read the audit's stated assumptions. Does each still hold? This is the category that gets missed, because it lives in the report, not the code.

Re-audit decision rubric

Five severities. Score the worst applicable; when unsure, round up. Severity is always labeled by name, never by color alone.

Evidence required before signoff

No item closes without evidence. Evidence types: git diff or commit range, deployed-bytecode or proxy-implementation address, on-chain tx hash, config dump, and the relevant audit-report section.

Human decision

Tooling structures the decision; a human makes it. Every severity-2+ item needs a named person — not a role — on the record.

Fields per item: owner, decision, date, rationale, linked evidence. Decision options:

• Accept — within audited intent.
• Block — do not proceed until resolved.
• Escalate — route to external review.
• Defer — explicit deadline and owner required. No Accept is permitted on severity 4.

One-page drift report

The artifact you hand up: audited snapshot, current snapshot, item counts by severity, highest severity, blocking items, the overall re-audit decision, owner, and date. Fill in one summary sentence:

As of [date], [protocol] has drifted from its [firm] / [date] audit (commit [audited]) by [N] tracked items ([n] at severity 2 or higher). The current system at commit [current] is [not cleared / cleared / cleared with conditions] for continued operation; required action: [full re-audit / lightweight re-audit of a named surface / senior review / none].

Filled example

A worked example on a fictional protocol — DroidVault, an ERC-4626 yield vault with upgradeable contracts, oracle-based pricing, a multisig admin, and a timelocked governance path. The audit covered commit abc1234 (Example Security Labs, 2026-03-15) on Ethereum. The current system is commit def5678 (v1.2.0) on Ethereum and Base. Six drift items came out of the pass:

Decision: Release is blocked until AD-002 and AD-003 receive senior review. AD-001, AD-005, and AD-006 require a focused external (lightweight) re-audit before production. AD-004 may proceed after internal confirmation that the fee remains within previously reviewed bounds.

Download the full worked example from the panel (Filled DroidVault example) to see the evidence log, per-item human decisions, and the one-page report filled in end to end.

GitHub-ready usage

Download the blank checklist and drop it in your repo at /security/audit-drift/ as one file per audited snapshot, or grab the shorter GitHub issue template from the panel and add it to .github/ISSUE_TEMPLATE/ so anyone can open a drift-review issue before risky releases, governance proposals, or deployment changes. Reference drift items from security-sensitive PRs. Everything is diffable and renders in any Markdown viewer.

For teams with frequent post-audit changes, wire the same structure into PR review and release checklists.

Related resources

• Security-Sensitive PR Review Card — the per-PR companion to this checklist.
• AI Agent Permission Boundary Checklist — scope what coding and ops agents may touch in the same repo.
• Drift Was Audited. That Was Never the Point. — the why behind this checklist.
• The Release Review — senior review of the changes this checklist flags, against your audited baseline.

Version history