When Systems Go Silent: Staying Connected During a Cyberattack

Imagine a cyberattack paralyzes your internal IT infrastructure – email, chat, and phone systems all go offline at once. How do you communicate? Many companies don’t have an answer until it’s too late. Using a fictional example, we’ll illustrate the consequences a communication outage can have during a cyber incident.

What matters most in the first few hours after a cyberattack?

Monday, 7:32 a.m.: The server stopped responding. An IT team member reports this to Sandra K., Head of IT at Muster AG, a medium-sized supplier with 320 employees across three locations. Her first thought: a technical issue, perhaps an update that went wrong overnight. Twelve minutes later, however, it becomes clear: Muster AG has fallen victim to a ransomware attack.

The systems are down, and a ransom demand appears on the screen. What happens next will determine whether the company overcomes this crisis or unnecessarily exacerbates the damage.

The Vacuum When Everything Grinds to a Halt

The real problem becomes apparent the moment Sandra tries to alert her crisis team. The company email is unavailable, the internal chat tool is dead, and the VoIP phone system is down. Everything runs on the same compromised infrastructure.

All that’s left is her personal mobile phone. Sandra starts searching for her colleagues’ personal numbers, but she hasn’t saved all of them. She also can’t reach the external IT service provider, as their contact information is stored on the intranet – which is currently inaccessible.

It is now 8:14 a.m. Sandra has known for 42 minutes that something is wrong, yet there is no coordinated communication. In the first few hours of a cyberattack, it’s not the technology that matters – since it’s offline – but the answer to the question: Who needs to be informed, when, how, and through which channel?

Muster AG has no answer. So they improvise: A WhatsApp group is spontaneously created for executives, the IT department, and a few select employees. Screenshots of internal system data are sent back and forth. The rest of the workforce is left in the dark at first. They sit in front of dead systems, unsure whether to go home or try to work around the problem. Eventually, a team lead loses patience. He takes it upon himself to update his team, getting some facts wrong. Soon several versions of the situation are making the rounds. Even management hears conflicting information.

Private messaging apps are often the only available tool in these moments. However, they are neither secure nor compliant with data protection regulations, and they are certainly not designed to coordinate a corporate crisis. Metadata is collected, and there is no control over who in these improvised groups has access to which information. For three days, Muster AG is flying blind.

Where did Muster AG fail?

A few weeks after the attack, management reviews the incident. The findings are sobering but instructive.

Mistake 1: No alternative communication channel was defined in advance. All internal communication relied on the very infrastructure that failed first during the attack. Without a plan B, the only option was to rely on private messaging apps.

Mistake 2: There was no crisis contact list stored outside the systems. Internal contacts were stored exclusively digitally and were therefore inaccessible during the outage. Even basic information, such as the data protection officer’s number, was unavailable offline.

Mistake 3: There were no defined communication roles. Who is authorized to communicate what to whom? Since this was not regulated, in an emergency, either everyone communicated or no one did.

Mistake 4: NIS2 was not on the radar. As a regulated supplier, Muster AG is subject to the new NIS2 regulations. The company was unaware of the obligation to report a security incident within 24 hours, which could lead to legal consequences.

Mistake 5: There were no tests or drills. Having a BCM plan in place is one thing; knowing it and practicing it regularly is another. Muster AG lacked both.

What a Functioning BCM Plan Looks Like in Practice

Business continuity management sounds like something for giant corporations and hundred-page manuals. But it doesn’t have to be that way. At its core, it boils down to three questions:

• What are our critical processes, and what do we need to keep them running in an emergency?

• Who communicates with whom, through which channel, and with what priority?

• Have we ever practiced for an emergency?

For crisis communication, this means: The channel you use during an emergency must not be the same one that fails when your infrastructure is compromised. It must work independently of your daily IT operations, be secure, and remain immediately operational – even when VPN, email, and the intranet are unavailable.

How are other companies preparing?

iSPIN AG wanted to avoid improvising in an emergency. As an IT service provider with high security requirements, they needed a solution that would work even if their own infrastructure came under attack – and one that is intuitive to use and compliant with data protection regulations.

With Threema Work, iSPIN AG introduced a communication channel that is completely separate from the rest of its IT ecosystem: it doesn’t rely on the company’s own servers, features end-to-end encryption, and isn’t linked to personal phone numbers or accounts. In an emergency, the right people can be reached within minutes, organized into predefined groups with clear communication roles.

Waiting Is Not a Strategy

Cyberattacks are becoming more frequent. The question is no longer if, but when a company will be affected – and how it will communicate when it happens.

To ensure you’re prepared for the worst, we invite you to try our trial version.

If you’d like personalized advice for your company, book a demo. We’ll show you how Threema Work fits into your specific BCM structure.