A smart-contract audit checks the token code itself: access control, transfer-restriction logic, upgrade safety, reentrancy, and oracle/economic risks. It is not SOC 2, ISO 27001, or NIST CSF; those cover the organization, not the bytecode. A serious deal needs both.
Two different questions get confused here. A code audit asks “can this contract be made to misbehave?” The organizational frameworks ask “does the company operate securely?” For a tokenized security — where the contract is the ownership record and enforces who may hold — you need an answer to both, and one does not substitute for the other.
Why
The token contract holds the register and gates every transfer. If it can be tricked, drained, or upgraded out from under holders, the security is broken at the layer that matters most. That is what a smart-contract audit inspects.
A competent RWA audit covers, at minimum:
- Access control and privileged roles — who can mint, burn, freeze, force-transfer, or upgrade, and whether those powers are correctly gated.
- Transfer-restriction logic — does the compliance gate actually gate? An allowlist that can be bypassed is worse than none, because it looks compliant.
- Upgrade safety — for proxy or Diamond (EIP-2535) systems, the audit must cover the upgrade authority and storage layout, not just today’s implementation. A safe contract behind an unsafe upgrade path is unsafe.
- Reentrancy and external-call safety, arithmetic and rounding, and denial-of-service — the classic exploit classes. (Ethereum.org — smart contract security)
- Oracle and economic/mechanism risk — anything that reads a price or runs incentives is an attack surface.
- Recovery mechanics — forced transfer and key-recovery functions are features a security needs (court orders, lost keys) and a centralization risk an audit must scope explicitly.
What the audit does not cover: key management, cloud and operational controls, personnel, and the issuer’s processes. That is the job of the organizational frameworks — and it is a large gap if you only have the code audit.
The edge cases
SOC 2 / ISO 27001 / NIST CSF are about the company, not the contract. SOC 2 reports a CPA firm’s opinion on a service organization’s controls; ISO/IEC 27001 certifies an information-security management system; NIST CSF is a risk-management framework. None of them inspects the deployed bytecode. A vendor can be fully SOC 2 compliant and ship an exploitable token. (AICPA, ISO, NIST)
“Verified” on a block explorer is not an audit. It means the source matches the deployed bytecode — useful, but it is a checksum, not a security review.
One audit is a data point, not a guarantee. Institutional deals increasingly expect more than one independent audit of the same contract, and confirmation that the audited code is what is actually deployed at the address.
What this means for your structure
Ask for four things, and treat any gap as a finding:
- The token contract’s audit reports — ideally more than one, from independent firms.
- Proof that the audited code is what is deployed (address and bytecode match).
- The vendor’s SOC 2 report and/or ISO 27001 certification for its operations.
- A clear statement of who holds upgrade and admin keys, and under what controls.
The code audit protects the asset’s on-chain logic. The organizational frameworks protect the operation around it. Buy from a vendor that can show you both, and be suspicious of one presented as if it were the other.
Gene Deyev’s take
I have watched issuers treat a SOC 2 report as if it clears the contract, and it does not. A clean org-controls audit tells you the company runs a tidy shop; it says nothing about whether the token can be frozen, drained, or upgraded out from under holders. When the contract is the ownership record, the transfer-restriction logic and the upgrade authority are where the real risk sits, and only a code audit reads that. Ask for both, insist the audited bytecode is what is actually deployed, and get a straight answer on who holds the admin keys and under what controls — that last one is where continuity lives.
— Gene Deyev, CEO & Co-Founder, Stobox. Co-author of the Stobox Tokenization Framework and the STV3 protocol; ERC-7943 backer; SEC Crypto Task Force roundtable participant (2025).
Related questions
- How to choose a tokenization platform — the buyer’s-checklist version of this question.
- What if the platform disappears? — why upgrade authority and key control belong in due diligence.
- ERC-3643 vs ERC-7943 — the transfer-restriction standards an audit checks.
Last updated: 2026-07-12.