When a crypto firm is breached, the technical response begins in minutes: containment, forensics, key rotation. But there is a second response running in parallel, one that most firms have never rehearsed and that ultimately determines whether the organisation survives the incident with its community, regulators and investors intact. That is crisis communications: the deliberate, sequenced process of deciding who speaks, what they say, when they say it and to whom.
Security teams tend to treat communications as a side issue, something for the marketing department to handle once the "real" incident response is under way. This is a mistake with measurable consequences. A firm that goes silent for six days invites regulatory scrutiny, community panic and permanent reputational damage, regardless of how well its engineers contained the breach. A firm that communicates within hours, even with incomplete information, tends to retain user trust and regulatory goodwill even when the financial loss is severe. Crisis communications is not a public relations afterthought. It is a core function of the incident response programme, built on the same People, Process and Technology (PPT) foundations as containment and recovery.
Why Crisis Communications Is an Operational Security Function
Security incidents in Web3 play out in public in a way that incidents in traditional finance rarely do. On-chain transactions are visible to anyone running a block explorer. A large outflow from a protocol treasury or exchange hot wallet is often spotted by independent researchers before the firm itself has confirmed a breach internally. This means the communications clock starts ticking the moment the transaction is broadcast, not the moment the firm chooses to say something.
This dynamic changes the calculus entirely. In most industries, an organisation controls the timeline of disclosure. In Web3, the blockchain itself often discloses the incident first. The firm's only remaining choice is whether to lead the narrative or be dragged behind it by speculation, screenshots and unverified theories circulating on Twitter and Telegram within minutes of an anomalous transaction.
Treating crisis communications as a genuine operational security function means giving it the same planning rigour as technical incident response: a named owner, a rehearsed process, pre-approved templates and clear escalation paths. It sits alongside your incident response plan as a parallel workstream, not a downstream task that begins once the engineers have finished.
Before the Incident: Building Your Crisis Comms Plan
Firms that communicate well during a breach did not improvise. They rehearsed. A crisis communications plan built and tested in advance is the single biggest determinant of how composed and credible a firm appears when it matters.
Designate a single spokesperson
Every credible crisis response has one authoritative voice. Multiple executives posting slightly different accounts of the same incident, even when well-intentioned, creates the appearance of confusion or concealment. The spokesperson is usually the CEO or a nominated senior executive with the authority to speak for the organisation, not the head of engineering and not a community moderator. Technical staff should feed information upward; they should not post independently on official channels during an active incident.
Pre-draft holding statements
Waiting until an incident occurs to write the first public statement wastes precious time and increases the risk of error. A holding statement template, drafted and legally reviewed in advance, should acknowledge that the firm is aware of unusual activity, confirm that the incident is being investigated, and commit to a specific time for the next update. It should never speculate on cause, scale or blame.
Map your stakeholders and channels
A crypto firm typically needs to speak to several distinct audiences simultaneously: retail users on Discord and Twitter, institutional counterparties by direct email or call, regulators through formal notification channels, and media through a press contact. Each audience needs a tailored message delivered through the right channel, coordinated so that no group receives materially different information from another.
Align comms with your recovery posture
Crisis communications cannot be planned in isolation from technical recovery. The comms team needs visibility into containment status, estimated losses and recovery timelines so that public statements do not contradict what the technical team is doing. This is why the communications plan should be built and tested alongside your disaster recovery procedures, with joint tabletop exercises that rehearse both tracks together.
Ronin's six-day silence did more lasting damage to trust than the $620 million loss itself. Communities and counterparties can forgive a breach. They rarely forgive the appearance of concealment.
The First 24 Hours: What to Say and When to Say It
The first day after detection is the highest-risk window for reputational damage, and it is also the window with the least verified information available. This tension defines the entire discipline of crisis communications: firms must say something meaningful before they know everything.
Hour zero to three: acknowledge
The goal in the first few hours is not to explain what happened. It is to demonstrate that the organisation is aware, in control and actively responding. When Bybit suffered a theft of roughly $1.5 billion from its cold wallet infrastructure in February 2025, CEO Ben Zhou posted an initial acknowledgement on X within roughly three hours of the incident being detected, confirming the platform was investigating a security breach and that customer funds remained backed one to one. He then ran a two-hour live stream to field questions directly, at a point when the full forensic picture was still being assembled. The content of that early messaging mattered less than its timing and tone: present, honest about uncertainty, and specific about what was being done.
Hour three to twelve: stabilise
Once the holding statement is out, attention shifts to operational stability. Bybit's decision to keep withdrawals open throughout the incident, rather than freezing the platform, was itself a communications decision as much as a technical one. It signalled solvency and confidence, and the firm processed over 350,000 withdrawal requests within twelve hours while continuing to update users on progress. Contrast this with the instinct many firms have to go dark and freeze everything while they figure out what happened. Silence during this window is read by the market as either incompetence or an attempt to buy time to hide losses.
Hour twelve to twenty-four: contextualise
By the end of the first day, the firm should provide a fuller, though still preliminary, account: what type of attack occurred, what has been contained, what remains under investigation, and what the firm is doing to protect remaining assets. This is also the point at which legal and regulatory notification tracks, discussed below, should already be well under way in parallel.
Regulatory Notification vs Public Disclosure: Sequencing the Response
One of the most common errors in crisis planning is treating regulatory notification and public disclosure as a single sequential process, where the firm waits for legal sign-off before saying anything publicly. This is both operationally slow and strategically wrong. The two tracks should run concurrently, managed by different teams, coordinated through a single incident commander.
Regulatory notification runs on its own clock
Statutory and licence-based notification obligations, whether to a financial regulator, a data protection authority, or a banking partner, typically have fixed deadlines that are not negotiable and are not dependent on the state of public messaging. Legal counsel should trigger these notifications the moment a reportable incident is confirmed, drawing on the same evidence base used for the public holding statement. Firms that have already mapped their regulatory reporting obligations ahead of time can execute this track in hours rather than days, because they already know which regulators need to hear from them and in what format.
Public disclosure should not wait for regulators
Firms sometimes delay public statements because legal teams want to complete regulatory filings first, worried that a public statement might complicate the regulatory narrative. This is generally the wrong trade-off in a market where on-chain activity is already visible. A carefully worded holding statement that avoids speculation and legal admissions can, and should, go out publicly well before every regulatory filing is finalised. Legal review of the public statement should be measured in minutes, not days.
Keep the two narratives consistent
Whatever the firm tells a regulator and what it tells the public must be consistent in substance, even if the regulatory filing contains more technical detail. Any daylight between the two, once discovered, is treated by both regulators and the community as evidence of bad faith.
Community Management: Discord, Twitter and the Crowd
Web3 communities are unusually well organised, technically literate and fast-moving. Within minutes of a suspicious on-chain transaction, independent researchers will often post their own analysis, sometimes accurate, sometimes not, on Twitter and in Discord servers. A firm that does not actively manage its own channels during this period cedes the narrative to whoever posts first.
Moderate, do not delete
Community managers should keep official Discord and Telegram channels open and actively moderated during an incident, removing scams and phishing links that inevitably appear, without deleting genuine questions or criticism. Deleting critical comments during a crisis is one of the fastest ways to convert a security incident into a trust crisis.
Centralise the source of truth
Pin a single official update thread and repeat it consistently across every channel. Community managers should be equipped with an approved script and a clear escalation path for questions they cannot answer, rather than improvising answers that may contradict the official position.
Watch for impersonation
Every major crypto incident triggers a wave of phishing accounts impersonating the firm's official channels, often promising compensation or urgent action to "secure" user funds. Community and security teams should coordinate to flag and report these accounts immediately, and the firm should proactively warn users that it will never ask for private keys or seed phrases during an incident. This coordination sits naturally alongside the broader DeFi security operations function, since impersonation monitoring is itself a security control, not purely a communications one.
Handling Media Enquiries: Journalist Contacts and What Not to Say
Crypto-focused media move quickly, and journalists will often have their own sources inside a firm's community or technical circles. A poorly handled media enquiry can introduce inaccurate figures or speculative causes into the public record that are then repeated widely and become difficult to correct.
Route everything through one contact
All media enquiries, regardless of who receives them, should be routed to a single designated media contact who works directly with the spokesperson. Engineers, support staff and community managers should be briefed to decline comment and redirect journalists, politely and consistently, rather than answering off the cuff.
What not to say
Certain categories of statement should never appear in early communications with media or the public: speculative root cause analysis before forensics are complete, guarantees of full reimbursement before the financial position is verified, direct blame assigned to a named vendor or individual, and any technical detail that could help the attacker or compromise a live investigation. Journalists will press for these details precisely because they make a better headline. The discipline of the spokesperson is to give a complete, honest, but appropriately bounded answer every time.
Provide something concrete
Refusing to engage entirely tends to backfire, producing coverage based solely on anonymous sources and speculation. A brief, factual statement, even one that says only what is confirmed and what remains under investigation, gives journalists an accurate anchor point for their reporting and reduces the spread of inaccurate figures.
Post-Incident: Rebuilding Community and Institutional Trust
The communications job does not end once the immediate incident is contained. Rebuilding trust with users, counterparties and regulators is a longer programme that typically runs for months after the technical recovery is complete.
Publish a full post-mortem
Once forensics are complete, firms should publish a detailed technical post-mortem explaining root cause, impact and remediation steps taken. Euler Finance's public engagement after its March 2023 exploit is a useful reference point. The protocol communicated openly about the ongoing situation, engaged visibly with the attacker through public channels, and kept the community informed throughout the negotiation that eventually recovered the large majority of stolen funds. That sustained transparency, rather than a single announcement, was central to the protocol's ability to rebuild credibility and continue operating.
Demonstrate structural change, not just apology
Trust is rebuilt through visible, verifiable change: new custody architecture, additional signers, independent audits, or a rebuilt monitoring stack. Simply apologising without demonstrating what has structurally changed reads as hollow to both users and institutional counterparties.
Re-engage regulators proactively
Firms that treat regulators as an adversary to be managed during a crisis tend to fare worse than firms that proactively re-engage afterwards with remediation evidence and an invitation for ongoing dialogue. This proactive posture is far easier to sustain when it builds on an existing relationship established through routine regulatory reporting rather than one built from scratch under pressure.
Run a communications retrospective
Just as technical teams run a post-incident review of the breach itself, communications teams should run their own retrospective: what was said, when, through which channel, and how the market and community responded. This retrospective should directly update the crisis communications plan and pre-drafted templates, closing the loop so the organisation improves with each cycle.
None of this replaces strong technical incident response. Firms still need rapid containment, forensics and recovery, all covered in detail in Security4Web3's analysis of the Bybit breach response. But technical excellence alone does not protect an organisation's relationship with its users, its investors or its regulators. That relationship is protected, or lost, in the words chosen in the first three hours and the consistency maintained over the following months.
Frequently Asked Questions
Who should be the designated spokesperson after a crypto security incident?
A single, pre-designated spokesperson, usually the CEO or a nominated executive, should communicate publicly. Having one voice prevents contradictory statements. Technical leads should brief the spokesperson but should not themselves post public updates during an active incident.
How quickly should a crypto firm disclose a security breach publicly?
Firms should aim to acknowledge unusual activity within one to three hours of detection, even before full facts are known. A holding statement that confirms awareness and commits to updates is far better than silence, which the market interprets as concealment or incompetence.
Should regulatory notification happen before or after public disclosure?
Regulatory notification obligations and public disclosure usually run in parallel, not sequentially. Legal counsel should trigger statutory notifications immediately while communications teams issue a public holding statement. Neither process should wait for the other to complete.
What should never be said in the first public statement after a breach?
Avoid speculative root cause claims, guarantees of full reimbursement before verification, blame directed at named vendors or individuals, and technical details that could assist the attacker or compromise an ongoing investigation.
How does poor crisis communication affect a crypto firm beyond the immediate incident?
Delayed or evasive communication damages regulator relationships, accelerates user withdrawals, invites litigation, and can end a firm's ability to raise capital, often causing more lasting harm than the financial loss from the breach itself.