The first hours after a serious cyber incident are filled with activity. Security starts investigating, IT works to contain the impact, legal begins assessing potential obligations, and executives want to know what happened and what the company is doing about it. Most teams rely on the same tools they use every day to coordinate that work, which usually means email, Slack, Teams, shared documents and video calls.Coordination gets much more complicated when the company’s email or collaboration environment is part of the incident. Email may still work, employees may still be able to join meetings, and nothing on the surface may suggest that the organization has lost control of its communications. Meanwhile, an attacker with access to accounts used by responders may read the team’s messages, monitor containment plans or impersonate someone involved in the response.When that happens, the company faces a second crisis inside the first. The systems people depend on to manage the incident can no longer be trusted.After more than two decades in the privacy and breach space, and in my weekly conversations with security and legal teams, I see the same pattern. Most incident response plans account for email or collaboration tools becoming unavailable. Teams have phone trees, personal contact information and backup conference lines. They know whom they need to call. What they often lack is a systematic approach for the harder case. Far fewer plans address the more ambiguous situation in which those systems remain functional while the organization can no longer be certain who is reading, sending or altering messages inside them.That scenario requires a preplanned way to move the response out of band while investigators determine what has been compromised.When the attacker may be inside the responseThis problem is easy to see during ransomware. Systems go down, employees lose access and the need for alternative communications becomes obvious. Compromised communications make judgment harder because the affected environment may appear completely normal.Suppose the security team discovers that an attacker has gained access to email and collaboration accounts used by incident response team members. The team needs to determine the scope of that access, remove the attacker and contain the intrusion, but discussing those actions in the regular incident channel could tell the attacker exactly what is coming. Legal needs the latest facts to evaluate notification requirements, the comms team is preparing for questions from customers, and leadership expects regular updates. Every one of those conversations may reveal something valuable to the person the company is trying to remove. The attacker is in the meeting.Responders then must answer a basic question before they can safely coordinate anything else: Who can see what we are saying?Countless companies rely on Teams or Slack during incidents because those are the systems their employees already use. The tradeoff is that the response stays inside an environment the attacker may already access and has every reason to monitor. I’m aware of several cases where attackers joined or recorded Zoom and Teams bridges used for incident meetings.What was already saidAs I discussed in my previous CSO article, putting a lawyer in a large incident channel does not make every conversation privileged. Operational facts and legal advice serve different purposes, and a crisis does not remove the need to control who participates in sensitive discussions. If the attacker was reading the channel, assume that every containment plan, every candid assessment of how the intrusion happened, and every draft customer statement posted there is now outside the company. Some of it may surface in an extortion demand. All of it may surface in discovery.Plan as though the company will end up in court. The out-of-band channel should give teams a place to separate operational coordination from legal analysis, limit participation and begin building the record that regulators and plaintiffs may later examine: what was decided, by whom, on what facts and why. Legal should design that structure before the incident. Trying to create it during one, in a channel the attacker may be reading, compounds the problem.What an out-of-band plan must solveThe mistake I see is starting with a backup application. Start with the failure scenario and map every dependency shared by the primary and emergency communications environments, including identity services, managed devices, mobile device management, administrative credentials and employee directories. If both channels depend on the same underlying component, that component remains a single point of failure.Then decide how participants will prove who they are. An attacker with access to email or calendars may know that an emergency meeting is taking place and have enough context to impersonate an executive or responder. The verification process cannot depend on the accounts under investigation.The same preparation should cover outside counsel, forensic investigators, insurers and communications advisers. Maintain current contact information, define who can authorize their participation, and establish how the team will verify them before an incident begins.Devices also matter. An alternative channel provides little value if responders can reach it only through corporate laptops they have been instructed to disconnect. The plan should specify which devices responders can use and what information they may access through them.The specific approach will depend on the company’s size, risk profile and existing systems. The test is whether the response can continue without relying on the environment under investigation.Practice moving the responseMost organizations that test backup communications focus on whether the channel works. They should also rehearse the judgment call that activates it. Participants need to recognize when the primary environment has become untrustworthy, alert the response team without exposing the move, and continue operating in the alternate channel.A tabletop exercise can begin with evidence that an attacker has accessed email and collaboration accounts used by several responders, even though both services still appear to function normally. The team must decide what evidence is sufficient to trigger the move, who has the authority to make that call, and how everyone’s identity will be verified after they arrive.The exercise should bring in security, legal, executives and essential outside partners. Add the complications that make real incidents difficult, such as an executive sending conflicting instructions through corporate email, someone joining a meeting from an unfamiliar account, an outdated emergency contact or a third party unable to authenticate.Those moments reveal whether the company has a working capability or only a document describing one. I would measure how long it takes to recognize the need to move, activate essential stakeholders, establish a verified response group, and brief leadership. Every point at which participants fall back on the affected environment exposes a dependency the written plan missed.Most incident response plans assume the company will have somewhere safe to coordinate. That assumption deserves the same scrutiny as backups, recovery procedures and containment playbooks. The decision to leave familiar systems should have defined triggers, a clear owner and a destination everyone has already practiced using.When the communication environment becomes part of the breach, legal deadlines, business decisions, customers and employees do not wait. The company needs to know when to move, where to go and how to keep operating once it gets there.