The direct answer

Use one incident authority, one verified fact log, one approved public channel and a fixed update cadence. Publish what is known, what is unknown, what users should do and when the next update will arrive.

Do not speculate about cause, losses, attribution, recovery or safety before the responsible technical, legal and leadership owners approve the wording.

1. Define incident classes before they occur

• security or suspected compromise;
• service outage or degraded functionality;
• incorrect token, contract or listing information;
• impersonation, phishing or account takeover;
• rumor or misinformation;
• partner or market-infrastructure failure;
• regulatory or legal event.

Each class needs an escalation owner, communication threshold and required reviewers. CISA describes an incident response plan as a formally approved document that helps an organization prepare roles, responsibilities and communication flows.

2. Establish authority and channels

Name the incident commander, technical fact owner, communications lead, legal reviewer and publishing operator. Decide which channel is canonical: status page, website, verified social account or another controlled location.

Every secondary update should link to the canonical source. Do not let support, community, founders and partners improvise different versions.

3. Maintain a verified fact log

Separate observation from diagnosis. “Withdrawals are delayed” is different from “the wallet is safe” or “no funds were lost.”

4. Use a holding statement that does real work

A useful first statement contains:

1. what the organization has observed;
2. which product or users may be affected;
3. the immediate action taken;
4. what users should or should not do;
5. where official updates will appear;
6. the next update time.

Avoid “everything is fine,” blame, invented precision and promises that depend on unresolved investigation.

5. Set an update cadence

Choose a realistic interval and publish even when the update is that investigation continues. A predictable cadence reduces rumor without forcing unsupported conclusions.

If the incident changes materially, update immediately. Preserve previous statements where practical and label corrections rather than silently rewriting the record.

6. Coordinate affected stakeholders

Prepare tailored factual routes for users, employees, moderators, partners, media and regulators where required. The facts should remain consistent, while instructions and timing may differ.

Do not give influencers or partners an unverified narrative to repeat. Give them the canonical link and approved language.

7. Close with evidence and review

A recovery statement should explain what is restored, what remains limited, what users need to do, how claims or support will work and when a fuller review will be available.

Afterward, record timeline, approvals, corrections, unanswered questions, channel failures and recurring misinformation. Update the incident plan and rehearse it.

The first 60 minutes

This is a planning scenario, not a universal deadline. A severe incident may require faster safety instructions or mandatory notifications through separate legal and regulatory processes.

What Crynet can help decide

Crynet's Web3 reputation management work covers risk monitoring, response governance and recovery communication. Crypto PR and communications coordinates external stakeholders, while Web3 community management keeps owned channels aligned during fast-moving incidents.

Send Crynet the incident classes, current escalation chart, public channels, approval owners and recent failure scenarios. We can build a communications runbook and holding-statement library for review before the next incident.