Build a fan-community incident response plan before a raid or harassment wave

A fan community incident response plan is what keeps a bad hour from becoming a week of confused bans, deleted evidence, exposed hosts, and contradictory statements. Here is the sequence: detect, contain, preserve, decide, communicate, recover, review.

A bad hour, or a bad week

A fan community incident response plan prevents a bad hour from becoming a week of confused bans, deleted evidence, exposed hosts, and contradictory public statements. Raids, impersonation, targeted harassment, and coordinated reporting all move faster than ordinary moderation, and your team has to contain the immediate harm without making permanent decisions under pressure.

What follows is a practical sequence: detect, contain, preserve, decide, communicate, recover, and review. Write it before an incident, assign each decision to a named role, and rehearse the first fifteen minutes. The payoff is not perfect prevention. It is a controlled response that protects people while preserving the information needed for fair decisions later.

Why ordinary moderation breaks during an incident

Routine moderation assumes reports arrive one at a time. A moderator reads the context, applies a published rule, and records the outcome. An incident changes all three conditions at once: reports arrive faster than anyone can review them, attackers manufacture misleading context, and the people making the decisions may themselves be targets.

Platform policy still matters. The Discord Community Guidelines prohibit harassment, threats, impersonation, and coordinated abuse, which gives a team grounds to act. They do not tell a particular creator who should lock a channel, preserve screenshots, contact a host, or publish an update. The creator has to convert platform rules into an operating sequence.

Video platforms leave the same gap. YouTube’s harassment and cyberbullying policy explains prohibited targeted abuse and reporting boundaries, but it cannot coordinate your Discord discussion, email, membership access, social posts, private messages, or the safety of each person associated with the show. Those responsibilities belong in your own plan.

Multi-host channels carry an extra failure mode. An attack may target one person while the shared account, the sponsor relationship, and the fan community belong to the whole show. A generic response can expose the targeted person, or imply that every host has signed off on a statement. Treat person protection and channel communication as two separate decisions.

Define an incident before you need the definition

Routine violation One account breaks a rule, no credible threat exists, and normal moderation capacity can absorb it. No emergency powers.
Elevated event Several related accounts, repeated impersonation, a sudden report spike, or targeted posts create a credible risk of wider disruption.
Critical incident Credible threats, doxxing, account compromise, sustained coordinated abuse, or harm crossing several platforms. Requires immediate containment and creator involvement.

Not every rude message is an incident. Too broad a label and moderators reach for emergency powers during ordinary conflict; too narrow and they wait while coordinated harm spreads.

Write observable triggers beside each level: ten new accounts posting the same link within five minutes, a fake host account contacting fans, private information appearing in public, a named person receiving credible threats. Avoid triggers based only on tone or on a moderator’s intuition.

Decide what is NOT covered, too. A sponsor disagreement, an editorial correction, and criticism of a host can all be difficult without being safety incidents. Route those through the appropriate editorial or commercial process unless they involve threats, impersonation, or coordinated abuse.

Assign roles and emergency authority

Incident lead Sets severity, keeps the timeline, closes the incident. Authority: starts and ends temporary containment.
Platform operator Applies channel restrictions and account actions. Authority: preapproved reversible controls only.
Evidence recorder Captures reports, links, timestamps, and action history. Authority: maintains the restricted incident record.
Person liaison Contacts the targeted host, guest, or moderator privately. Authority: shares only confirmed, necessary information.
Communication owner Drafts internal and public updates. Authority: publishes once the named approver confirms.
Creator or safety owner Makes high impact and external escalation decisions. Authority: approves permanent actions and the public position.

A plan fails when everyone can advise and nobody can decide, so assign the roles before you add any tools. In a small community one person may hold two roles, with one exception: the incident lead should not also be the only evidence recorder. The lead needs enough distance to compare reports and challenge assumptions.

Platform guidance helps moderators understand which controls exist. Discord’s Safety Library and moderation resources cover moderation and safety practice, but your internal plan has to narrow those capabilities into explicit permissions. A junior moderator might enable slow mode or hide a channel; only the safety owner removes a long-standing member or issues a public accusation.

Keep an emergency contact sheet OUTSIDE the affected platform: incident lead, backup lead, creator, platform owner, person liaisons. If the Discord server or the shared social account is compromised, a contact list stored only there is useless exactly when you need it.

The seven step sequence

1. Detect and classify Open an incident record when an observable trigger is met. Log the first known event, affected surfaces, reported targets, and initial severity. Look for two independent signals of coordination where you can: a membership surge plus repeated identical posts beats either alone. A report from the targeted person can justify immediate protection even while coordination is still uncertain. Do not copy unverified allegations into a public channel.
2. Contain with reversible controls Reduce the attacker’s ability to cause new harm using the smallest control that buys the team time.
3. Preserve evidence and privacy Capture enough context to support a decision without building a public spectacle.
4. Decide with a time box Set the next review time the moment containment begins, then choose one of four paths at review.
5. Communicate on a need-to-know basis Three different updates, not one universal statement.
6. Recover in stages Restore one control at a time and watch for recurrence after each change.
7. Review the system, not just the attackers Within two working days, hold a short review that produces owners and due dates.

Follow them in order. The order is the whole point: it stops the team from making permanent decisions while the facts are still changing. The sections below expand the steps that carry the most risk.

Reversible controls, smallest first

Tighten the front door Pause new invitations, or tighten posting rights for new members.
Slow the room Enable slower posting, or restrict the one affected channel rather than the whole server.
Quarantine links Hold suspicious links rather than letting them propagate while you review.
Hide, do not delete Hide targeted threads while preserving access for the evidence recorder.
Cut risky integrations Remove a compromised integration from sensitive permissions.
Shield the person Temporarily separate the targeted person from public notifications.

Prefer controls you can undo. A temporary read-only channel preserves history far better than deleting it, and a short access restriction gives the team time to review before anyone applies a permanent ban.

Do not announce a suspect’s identity during containment. Attackers imitate innocent members, and a rushed accusation can point the harassment at the wrong person.

What the incident record holds

Identity and severity An incident id and the current severity level, so every later note attaches to one case.
Started at, and next review at The first known event time and the scheduled review time. The review time is what stops open-ended containment.
Affected surfaces and targeted persons Which spaces are involved, and who is being targeted. Both drive protection decisions.
Containment in force The controls currently applied, so recovery knows exactly what to unwind.
Evidence items Per item: the original URL or message identifier, account identifier, timestamp, surrounding conversation, and the reporter.
Decisions and owners Each decision, the action taken, the person responsible for it, and the communication owner for the incident.

Store the record somewhere restricted, and strip unnecessary private details out of working summaries. Preserving evidence does not mean every moderator needs a copy of a threat or of a targeted person’s personal information.

Decide with a time box

Fifteen to thirty minutes is a reasonable review window for an elevated event; a credible safety threat requires immediate escalation instead. At review, pick exactly one of four paths: downgrade to routine moderation, continue containment, apply a documented permanent action, or escalate outside the community team.

Separate facts, interpretations, and unknowns when you write it up. Fact: fourteen accounts posted the same link within six minutes. Interpretation: the posts appear coordinated. Unknown: whether one person controlled the accounts. That format stops an early guess from hardening into accepted history, and it means permanent actions cite the violated rule and the evidence item rather than a moderator’s emotional summary.

If a credible threat or exposed private information may require emergency or legal help, use the relevant local process. A community playbook cannot determine legal obligations across every jurisdiction. What it can do is make sure the evidence and the decision owner are unambiguous when someone else needs them.

Three updates, not one statement

The moderator update Names the active controls, the current severity, and the next review time.
The targeted-person update Explains what is known, what protection is active, and who will contact them next.
The public update Says only what members need to do, and when normal service will be reviewed.

A useful first public message is short: "We have temporarily limited posting while moderators review coordinated rule violations. Please do not repost targeted material or speculate about the accounts involved. Existing content is being preserved for review. We will update this channel at 15:00 UTC."

Do not promise an exact resolution when the team only knows the next review time, and do not ask fans to help identify attackers. That turns an incident response into an uncontrolled investigation, which is a second incident.

Recover in stages

Restore one control at a time: read access before posting, posting before new invitations, routine permissions before any integration with broad access. Watch for recurrence after each change rather than lifting everything at once.

Tell members which temporary rules have ended and which remain. If a host-specific discussion is what triggered the abuse, return first to episode-focused discussion instead of immediately reopening the contested space. That protects the named person without punishing the whole community indefinitely.

Then go back for the people your bulk actions caught by mistake. Contact legitimate members who were swept up, give them a private appeal path and a response window. Recovery includes correcting your own errors, not just reopening channels.

Review the system, not just the attackers

Which trigger started the plan, and was it early enough A trigger that fires late is a trigger that needs rewriting.
Which action reduced harm fastest Promote it up the sequence for next time.
What evidence was missing or overshared Both directions are failures: too little to decide, or too much exposed.
Did the targeted person receive useful updates Ask them, rather than assuming the liaison step worked.
Were any permissions unavailable or dangerously broad Both block a good response, in opposite ways.
Did the public message reduce speculation If speculation grew after you posted, the message was the wrong shape.
Which temporary actions still need reversal or appeal review Emergency state left switched on becomes the new normal by accident.

Hold it within two working days, and give every improvement an owner and a due date. Avoid the retrospective that just praises the team’s speed or blames one moderator. The purpose is to make the next response less dependent on memory and improvisation.

The fifteen minute exercise

Who is the incident lead, and the backup If two people name different leads, you do not have a lead.
Which exact trigger changes this from routine moderation The answer should be observable, not a feeling.
What is the first reversible containment action Named specifically, and the operator must actually hold that permission.
Where is evidence recorded, and who can see it A location nobody can name under pressure is not a location.
Who contacts the targeted person One named liaison, not whoever notices first.
Who approves a public update Approval and drafting are different jobs; say who holds each.
When will containment be reviewed A specific time, set at the moment containment starts.

A plan that has never been exercised is a document, not a capability. Run a tabletop once a quarter, and after any major platform or team change. Give the team a scenario: twelve new accounts arrive during a livestream, post an impersonation link, and target one rotating host. The lead classifies it, the platform operator names the first reversible control, the recorder opens the incident record, the communication owner drafts all three updates.

Do not perform real bans or publish test messages in the live community; use a private test channel or simply talk the controls through. The exercise passes when the team answers all seven questions within fifteen minutes. Record the elapsed time and any missing access, because a moderator discovering mid-raid that they cannot pause invitations is a preventable failure.

Common mistakes to remove from the plan

Do not delete the attacked channel before preserving context. Do not make the targeted person answer every moderator separately. Do not treat a high report count as proof, because coordinated reporters can manufacture that signal on demand. Do not let every host publish a separate explanation. Do not leave emergency permissions switched on after recovery.

Waiting for certainty can be just as damaging while the abuse continues. The team may well have to act before it knows who organized the attack: restrict posting, protect the target, preserve context, and schedule a review. Make the permanent decisions only after reviewing the evidence.

A good plan is short enough to use under pressure. Keep the first page to roles, triggers, immediate controls, evidence location, communication owner, and next review time. Everything platform-specific goes behind that page.

So put the first rehearsal on the calendar. Create the incident record template, assign the six roles, and schedule the fifteen minute exercise this week, using a raid plus impersonation scenario that targets one person in a multi-host channel. Fix the missing permissions and unclear approvals immediately afterwards. The plan is ready when the team can contain harm, preserve evidence, protect the targeted person, and state the next review time without waiting for the creator to improvise every step.