Crypto exchange incident response is not the document you open after a breach. It is the operating system that decides whether a hot wallet incident stays contained or turns into a solvency scare, regulatory problem, and internal breakdown.
For a mid-tier exchange, the hardest part is rarely one technical action. It is coordination under pressure. Wallet ops wants to sweep funds. Security wants to preserve evidence. Compliance wants facts before reporting. Support wants a script. The founder wants to reassure users. If those actions are not pre-sequenced, your own team can become the second incident.
This is why a 72-hour playbook matters. In the first minutes, you need scope and authority. In the first day, you need forensics, tracing, and reporting discipline. By hour 72, you need controlled recovery and a message that calms users without overpromising. The steps below turn crypto exchange incident response into a practical runbook rather than a policy artifact.
Why crypto exchange incident response needs a 72-hour playbook
Generic cyber response plans assume you can isolate a server, patch later, and keep the problem mostly private. Exchanges do not get that luxury. Funds move on-chain, attackers adapt fast, and every delay can be visible to users and counterparties.
A hot wallet breach also creates a decision bottleneck. Who can pause withdrawals? Who can change MPC thresholds? Who can speak to regulators or post to X? If those answers are not defined before the event, people improvise. That is where losses widen.
What a crypto exchange incident response plan must define before an incident
A workable plan needs named roles, not vague departments. At minimum, define:
- Incident commander with final operational authority
- Wallet operations lead for sweeps, threshold changes, and address rotation
- Forensics lead for host, IAM, signer, and deployment evidence
- MLRO/compliance lead for suspicious activity and regulator coordination
- Communications lead for customer, partner, and media statements
The plan should also define hard rules:
- Which severity level triggers a withdrawal pause
- Which assets can move to quarantine wallets without fresh approval
- Which admin roles get frozen during a live incident
- Which channels are official for decisions and evidence logging
- Which external partners are called in hour one
One mid-tier exchange learned this the hard way after a suspicious withdrawal cluster on Tron and Ethereum. Engineers began rotating credentials while another admin restarted a wallet service. The result was a broken evidence trail and six extra hours to confirm root cause. A stricter incident command model later reduced their simulated containment time from 97 minutes to 28 minutes.
That leads directly to custody design, because your response options depend on how keys and approvals are structured.
Custody response options compared: single-sig, multi-sig, MPC, and cold quarantine paths
Custody architecture changes what “containment” actually means during crypto exchange incident response. A single-sig hot wallet can move fast, but it gives you very few safe options in a compromise. MPC and multi-sig can slow attackers, but only if emergency paths are predefined.
| Custody path | Emergency policy change | Sweep speed | Insider control risk | Forensics visibility |
|---|---|---|---|---|
| Single-sig hot wallet | No | 1–5 mins | High | Low |
| Multi-sig hot wallet | Partial | 5–20 mins | Medium | Medium |
| MPC signing | Yes | 2–10 mins | Lower | High |
| Cold quarantine wallet | Yes | 15–60 mins | Low | High |
A few practical notes:
- Single-sig is operationally simple but dangerous for live exchanges.
- Multi-sig helps, but signer separation and approval policy matter more than the label.
- MPC gives the best emergency flexibility if threshold rules can be tightened without service collapse. See this MPC custody guide.
- Cold quarantine works only if destination addresses, approvals, and funding procedures are already tested.
Once those paths are defined, the next problem is the first two hours, where most teams either gain control or lose it.
Crypto exchange incident response in the first 0–2 hours
The first objective is simple: confirm scope before anyone starts fixing production. You need to know what is compromised, what is only suspected, and what remains under your control.
During crypto exchange incident response, speed matters. Blind speed does damage.
Confirm scope before anyone “fixes” production in your crypto exchange incident response
Start with evidence, not assumptions. Confirm:
- Affected wallets and chains
- Assets moved or at risk
- Last known legitimate signer activity
- Admin actions in the prior 24 hours
- Recent deployments, config changes, and IAM events
Pull signer logs, wallet service logs, cloud IAM logs, VPN access, and withdrawal API events into one timeline. If you support multiple chains, check for node sync drift before assuming all balances are accurate. A lagging Solana or EVM node can distort initial scope.
Most teams should impose an immediate change freeze on nonessential production actions. No restarts. No ad-hoc key rotation. No “quick patch” pushed by a tired engineer.
A practical rule: if the action changes state, requires privileged access, or can overwrite logs, it needs incident commander approval.
Contain a hot wallet hack: pause withdrawals, tighten signing rules, and freeze risky admin actions
Containment should follow pre-approved paths only. That usually means:
- Pause withdrawals for affected assets
- Move the withdrawal queue to manual review
- Raise signing thresholds for all hot wallet transactions
- Disable API keys with withdrawal permissions
- Freeze risky admin actions such as address whitelisting changes and role edits
- Sweep remaining funds to a quarantine or cold path if you still control the signer path
A post-launch exchange with 18 staff saw unauthorized BTC and USDT outflows late on a Sunday. They paused withdrawals within 11 minutes, changed MPC approvals from 2-of-4 to 3-of-5, disabled all admin role changes, and swept untouched balances to quarantine wallets in 34 minutes. Losses stopped at low six figures. Their later review found the initial access vector was a compromised admin session, not a wallet code bug.
Containment buys time. The next 22 hours decide whether you preserve enough truth to recover cleanly.
Crypto exchange incident response in hours 2–24
Once the bleed is contained, the work splits in two directions at once. You need host and access forensics, and you need on-chain tracing. Doing one after the other is too slow.
This is the phase where mature crypto exchange incident response separates technical facts from noise.
Run crypto exchange incident response forensics in parallel: signer logs, IAM, deployment history, and on-chain tracing
Preserve first. Analyze second.
Capture and protect:
- Wallet signer logs
- MPC or multi-sig approval records
- IAM role changes
- VPN and SSO logs
- CI/CD deployment history
- Secrets access events
- Container or VM snapshots
- Database audit trails
- Withdrawal queue states
In parallel, begin on-chain tracing. Tag attacker addresses, cluster related flows, and identify bridge hops, mixers, or deposits into other venues. Good tracing partners can help notify counterparties quickly. The Chainalysis blog and Rekt News both show how fast stolen funds can fragment across chains and services.
Do not wait for root cause before tracing. Do not stop host forensics because the on-chain trail looks obvious. Many exchange breaches start in access control, build systems, or signer environment exposure, not only in wallet logic.
Bring legal, compliance, regulators, and the MLRO into crypto exchange incident response early
Compliance should not hear about the breach after engineering already made public commitments. Bring in legal counsel, the MLRO, and your reporting owners in the first day.
They need to assess:
- Suspicious activity reporting duties
- Local VASP or exchange incident notification rules
- Data breach overlap if user data was exposed
- Sanctions screening of attacker addresses
- Whether partner banks or fiat providers need notice
A mid-tier exchange processing about 800 new accounts per month built compliance into its incident command process after a near miss. In later simulations, regulator-ready summaries were drafted in under 90 minutes instead of almost half a day. That matters when facts are still moving.
With evidence preserved and legal tracks active, the next challenge is controlled recovery without triggering customer panic.
Crypto exchange incident response in hours 24–72
By now, users may notice withdrawal issues, market makers may ask questions, and rumors may already be circulating. You need a message that is accurate, narrow, and calm.
This stage of crypto exchange incident response is less about speed than control.
How to communicate a crypto exchange security incident without triggering solvency panic
Your public statement should do three things:
- Acknowledge the incident
- State what services are affected
- Explain what you are doing next
It should not guess at totals, attacker identity, reimbursement, or full restoration timing unless confirmed.
Good first statements follow this structure:
- We detected unauthorized activity affecting specific wallets
- We paused withdrawals for affected assets as a precaution
- Trading remains active or is operating in restricted mode
- We are working with forensics, compliance, and external partners
- User balances are being reviewed and updates will follow at a defined cadence
Keep one spokesperson. Lock support scripts. Give market makers and liquidity partners a direct briefing if withdrawal restrictions may affect quote quality. If you need help thinking through trading-side stability, this overview of liquidity aggregation strategies is a useful reference.
Should we halt trading and withdrawals after a security breach?
Not always. Treat trading and withdrawals as separate decisions.
| Service | Default response | When to halt | When to keep running |
|---|---|---|---|
| Withdrawals | Pause affected assets | Scope unclear | Segmented wallets intact |
| Deposits | Partial pause | Address mapping at risk | Fresh addresses ready |
| Spot trading | Continue cautiously | Solvency uncertain | Assets fully backed |
| Margin/lending | Restrict fast | Collateral at risk | No custody impact |
A few rules help:
- Halt withdrawals first if wallet control is in doubt.
- Keep trading on only if balances, reserves, and market integrity are still reliable.
- Move to cancel-only mode if you cannot guarantee fair operation.
- If deposit addresses may be exposed, rotate them and verify mapping before reopening.
Many operators forget the customer support load here. A withdrawal pause can look like insolvency within minutes. Prewritten FAQs, a status page cadence, and aligned support responses reduce that risk.
That leaves the operator questions most teams ask when they finally sit down to build the playbook.
FAQ
What is the first thing to do when a crypto exchange is hacked?
Start crypto exchange incident response by confirming scope and freezing nonessential privileged actions. Identify affected wallets, assets, signer paths, and recent admin changes before anyone edits production. Then activate incident command and execute only pre-approved containment steps.
How do we move funds from a compromised hot wallet without corrupting evidence?
Preserve signer, host, and IAM evidence first or in parallel through snapshots and log exports. Then move remaining funds only through the emergency quarantine path already defined in your runbook. Record transaction IDs, approvals, timestamps, and operator actions in one incident log.
What are the legal requirements for reporting a crypto theft?
They depend on your jurisdiction, license type, and whether customer data was also exposed. Most exchanges need legal and MLRO review in the first day to assess regulator notice, suspicious activity reporting, sanctions exposure, and partner notification. Build those steps into crypto exchange incident response before the breach, not after.
Can stolen cryptocurrency be recovered?
Sometimes, but do not plan your response around recovery. Recovery depends on traceability, speed, whether funds hit cooperating venues, and whether bridges, mixers, or privacy layers were used. Fast on-chain tracing and early counterparty outreach improve odds, but many cases end with only partial recovery.
How do we create a crypto exchange incident response runbook?
Build it around a 72-hour timeline. Define roles, severity triggers, custody-specific containment options, evidence preservation steps, legal workflows, communication rules, and tabletop exercises. If your wider stack is still being formalized, start with a broader crypto exchange development guide and align the runbook to wallet, admin, and compliance architecture.
Conclusion
A good crypto exchange incident response plan does not just tell your team how to react to a breach. It tells them how not to make it worse. That means confirming scope before touching production, containing hot wallet exposure through tested paths, running forensics and on-chain tracing together, and bringing legal, compliance, and the MLRO in before narratives harden.
For mid-tier exchanges, the hidden risk is internal chaos under pressure. One engineer restarts the wrong service. One executive posts too early. One support reply contradicts the public line. A real 72-hour playbook prevents those mistakes as much as it stops attacker movement.
If your exchange has never tested a live hot wallet breach scenario with wallet ops, security, compliance, and customer teams in the same room, that is the next step. Review your custody paths, drill the first two hours, and pressure-test decision rights now. That is how crypto exchange incident response becomes survivability, not paperwork.
Get a free consultation today!
Book a free demo with Code Elevator IT Solutions.
Call Now: +91 91045 04898
