Scoping a penetration test for a crypto exchange
How to scope a penetration test for a crypto exchange: wallet and custody assets, RoE for live production funds, tiers, and what the report covers.
The short answer
Scoping a penetration test for a crypto exchange means fixing four things before an engineer touches production: which layers — external, internal, application — are in scope, which exchange-specific assets are named individually rather than folded into "the platform" (wallet and custody, the trading engine, the admin panel, KYC), a Rules of Engagement that defines how exploitation testing touches real funds and signing infrastructure without risking them, and which tier of depth and duration you're buying. Skip any of these and the quote you get is for a generic web-app test wearing a crypto exchange's logo.
Who this is for
This is written for whoever owns the statement of work at a licensed or regulated crypto exchange — a CISO, Head of Security, or platform owner who has to turn "get a penetration test done" (from a licensing regulator, a banking partner, or an internal audit finding) into a scoped, priced engagement against infrastructure where a missed finding means real on-chain funds move, not just a compliance flag.
It is not for you if what you're actually asking is whether to add continuous monitoring on top of a point-in-time test — that's a managed SOC decision, and the detection content that pairs with this kind of engagement is covered in building a SOC for a crypto exchange from scratch. It's also not the right read if the decision in front of you is how much starting access to grant the tester per system — that's a separate axis, covered in black-box vs grey-box vs white-box pentest, and it applies here the same way it applies to any other platform.
What's actually in scope
"Pentest our exchange" defaults, in practice, to a web-app test against the trading UI — which is exactly the surface an attacker cares about least, because it rarely holds custody of funds directly. A scope built for an exchange names each layer and, within it, the assets that actually carry financial and licensing risk:
- External network — perimeter, public API endpoints, load balancers. Standard across any vendor; rarely where exchange-specific risk lives.
- Internal network — lateral movement from a foothold toward systems that can initiate or authorize withdrawals, including any internal admin tooling reachable from the corporate network.
- Application layer — the trading web app and mobile clients (tested against OWASP MASVS where mobile is in scope), plus the server-side logic behind order placement, deposits, and withdrawals.
Within those layers, the assets a generic "full platform" scope statement tends to skip by omission:
| Asset | Why it belongs in scope by name |
|---|---|
| Wallet and custody infrastructure | Hot-wallet withdrawal automation, the handoff to cold storage, and the key-management or signing flow (in-house HSM or a third-party custody API) — the single highest-consequence surface on the platform, and the one most often left out of "web app" scoping language |
| Trading / matching engine | Order-book manipulation, market-data integrity, and privileged internal access that could front-run client orders — a threat class building a SOC for a crypto exchange from scratch also treats as its own detection layer for exactly this reason |
| Deposit / withdrawal blockchain integration | Address validation, confirmation-count logic, and the reconciliation between on-chain state and internal ledger balance — the exact class of flaw covered in why we still do pure-manual penetration testing, where a race condition in a deposit-confirmation flow could have credited one on-chain deposit to two accounts |
| Admin / ops back-office panel | Internal-facing and rarely load-tested, and the panel that decides whether a compromised employee or support account can pause trading, approve a manual withdrawal, or override a KYC flag |
| KYC / AML pipeline | Often bought from a vendor and wired in rather than built in-house — worth confirming during scoping which parts are yours to test and which sit behind a third-party API boundary |
Naming these individually — rather than trusting "full platform coverage" in a proposal — is what turns the scope into something a tester can actually be held to when the report lands.
The Rules of Engagement question specific to custody
Every casino or SaaS pentest asks "how do we know this won't take down production." A crypto exchange asks a sharper version: how do we know testing withdrawal and signing logic won't move real funds. The RoE has to answer that before anything else:
- A segregated test wallet and minimal-value or test-net addresses, named explicitly for any exploitation step that touches deposit or withdrawal logic — production custody balances are never the target.
- Third-party custody boundaries defined up front. If signing runs through a custody provider (an in-house HSM setup or an external API), the RoE states whether that provider's endpoint is in scope at all — testing against it without that provider's own authorization is not something an exchange can grant on its behalf.
- A named contact with authority to pause testing immediately — the same requirement as any RoE, but with a lower tolerance for delay given what a signing-logic finding could mean if left live.
- Explicit timing boundaries around settlement windows or scheduled on-chain batch withdrawals, so exploitation testing against the withdrawal flow doesn't collide with real batch processing.
Licensing regimes that cover exchanges commonly require evidence of independent testing as a condition of maintaining registration — the RoE and report both need to hold up to that scrutiny, not just internal sign-off.
How the engagement runs
| Step | What happens |
|---|---|
| 1. RoE and scope definition | Targets, custody boundaries, test-wallet arrangement, and stop conditions signed before any exploitation begins |
| 2. Reconnaissance and attack-surface mapping | External, internal, and application surfaces enumerated against the named scope — including wallet, admin panel, and KYC assets called out above |
| 3. Manual exploitation with chained vulnerabilities | Senior engineers hand-test for multi-step chains — an admin-panel privilege gap plus a withdrawal-approval bypass — the kind of chain an automated scanner tests in isolation and misses |
| 4. Post-exploitation impact analysis | Every successful path is traced to a business outcome: unauthorized withdrawal, ledger/on-chain mismatch, or account takeover — not just "endpoint vulnerable" |
| 5. Report drafting | Executive summary plus a developer-actionable technical report with reproduction steps |
| 6. Retest | Fixes validated against the same technique that found them |
This is 100% manual delivery, the same standard described in why we still do pure-manual penetration testing — automated tooling scales reconnaissance, but the chained findings that matter in custody and withdrawal logic only surface when a senior engineer reads the code and decides what to test next.
What drives the cost
The same three tiers that apply to any penetration test engagement:
| Tier | Price | Duration | Scope |
|---|---|---|---|
| Focused | €2,499 per engagement | Up to 5 days | One target — a single application, or one external/internal network |
| Standard | €5,999 per engagement | Up to 10 days | Full-stack — external + internal + one application + one mobile app, plus a purple-team debrief |
| Continuous | €12,000 per quarter | Ongoing | Quarterly full-stack cycle with out-of-band micro-engagements — fits exchanges shipping weekly |
What usually moves an exchange from Focused to Standard is not network size — it's whether wallet/custody, the admin panel, and the trading engine need to be tested as named, chained targets rather than a single high-priority asset on a tighter budget.
What you walk away with
- An executive summary in business-risk language for stakeholders who won't read a CVSS table.
- A technical report with developer-followable reproduction steps.
- Per-finding remediation guidance at the code or configuration level.
- A retest, confirming the fix closes the exact technique that found it.
A clean pass with no critical findings is still evidence — but only if the scope and RoE that produced it are documented well enough for a regulator or banking partner to trust the negative result.
Limitations — what this doesn't replace
A penetration test proves what an attacker can do against the named scope, on the day it runs. It doesn't audit a smart contract you've listed or built — that's a separate, specialized review, not a line item inside a general infrastructure pentest. It isn't continuous coverage either: a clean report this quarter says nothing about the trading feature shipped last week, which is what building a SOC for a crypto exchange from scratch is built to catch between engagements. And a test that skips wallet, admin-panel, and KYC assets in favor of "full platform coverage" on paper produces a report that satisfies a checkbox without ever touching the systems that carry real financial risk.
How to decide you're ready to scope one
Bring three things to the scoping call: which assets actually carry custody or financial risk (wallet, signing flow, admin panel — rarely just the trading UI), whether any listed token needs a separate smart-contract review, and any regulator or banking-partner requirement that names specific test types or timing. One more input worth deciding before the call: how much starting access to grant the tester per asset — black-box vs grey-box vs white-box pentest covers how that choice maps onto custody and admin systems specifically. Tell us your platform and scope and we'll turn it into a signed RoE, a test-wallet arrangement, a tier recommendation, and a cost estimate before any testing begins.
Sources and review
This guide reflects AnySec's Penetration Testing engagement methodology and standard industry scoping practice as codified in the Penetration Testing Execution Standard and the OWASP Web Security Testing Guide. Author: AnySec Engineering. Published 2026-08-16; last reviewed 2026-08-16.
Related reading
- Scoping a penetration test for an online casino — the same scoping method applied to a different vertical's asset list.
- Why we still do pure-manual penetration testing — the methodology behind the engagement, including the deposit-confirmation race condition this post's asset table refers to.
- Building a SOC for a crypto exchange from scratch — the detection layer that watches this platform between pentest cycles.
Rather not learn this in production.
Talk to the engineers behind these write-ups — thirty minutes, no sales script, a straight read on where you stand.
Book a call