When a ransomware attack hits, the technology an organisation normally relies on to coordinate its response may be among the first things to become unavailable or untrusted.
Email may be inaccessible. Microsoft Teams may be unavailable. Corporate identity services may be compromised. VPN access may be deliberately disabled. Even mobile phones can become unreliable if teams are trying to coordinate at scale.
For an MSSP, this creates a problem that sits outside the technical remediation of the attack: how do you keep communicating with the client when the client's normal communication infrastructure cannot be trusted?
A dedicated crisis communication platform provides an independent environment for coordinating the response, maintaining an auditable record and keeping the right people connected while the primary IT environment is being investigated or recovered.
But not every platform provides the same level of resilience.
This guide sets out the key criteria MSSPs should consider when evaluating a crisis communication platform for ransomware response.
During normal operations, organisations have a huge choice of collaboration tools. Email, Microsoft Teams, Slack, Zoom and other platforms are designed to make day-to-day communication easy.
Ransomware changes the requirements.
The priority is no longer simply whether people can send messages or join a video call. The organisation needs to know:
These are resilience questions rather than conventional collaboration questions.
A ransomware response therefore needs a secure communication environment designed specifically for the conditions in which normal systems may not be available.
There are six core areas to assess:
Let's look at each in turn.
The first question should be simple:
Is the platform genuinely independent of the client's primary IT environment?
A platform that relies on the same identity provider, network or infrastructure being investigated during an incident may not provide meaningful fallback.
This is particularly important for organisations using cloud identity and collaboration platforms extensively. If an attacker compromises administrative accounts or identity infrastructure, simply having another application that depends on the same authentication environment does not necessarily provide an independent communications channel.
A resilient crisis communication platform should therefore be architecturally separate from the client's primary corporate environment.
Look for:
The principle is straightforward:
Your fallback communications platform cannot depend on the system it is supposed to replace.
A platform being cloud-hosted does not automatically make it an out-of-band solution.
If access still depends on the client's corporate identity provider, network or security controls, the organisation may find that its supposedly independent communication channel disappears at exactly the wrong moment.
MSSPs should therefore evaluate the complete dependency chain, not simply where the software is hosted.
Once an independent channel exists, the next requirement is secure collaboration.
Ransomware incidents generate highly sensitive information. Teams may need to discuss:
Using ordinary consumer messaging applications or improvised communication channels creates obvious security and governance problems.
A dedicated crisis environment should provide controlled communication between the people involved in the response.
A mature crisis communication platform should support more than text messaging.
Depending on the incident, teams may need:
Secure chat and channels - For rapid coordination between technical teams, executives, legal advisers, communications teams and external specialists.
Video crisis rooms - For incident briefings, technical discussions, executive decision-making and coordination with external experts.
Secure document access - Critical response documents, procedures, action cards and checklists should remain accessible even when the primary IT environment is unavailable.
Controlled access - Different groups should be able to access only the information relevant to their role or incident.
The objective is not to recreate Microsoft Teams with another interface.
It is to create a resilient crisis environment that can be trusted when the normal collaboration environment cannot.
An MSSP has an additional requirement that an individual organisation does not. It may be supporting multiple clients experiencing different incidents at the same time.
That makes incident separation particularly important.
Each client should have an isolated crisis environment where the MSSP can work alongside the client's authorised personnel without creating unnecessary overlap between customers.
For example, an MSSP might need to coordinate:
Client A - Ransomware affecting core infrastructure.
Client B - Suspected identity compromise requiring investigation.
Client C - A third-party incident requiring emergency coordination.
Each incident needs its own communications environment, participants, documents and audit trail.
A platform designed for MSSPs should therefore make it easy to establish and manage separate client environments while retaining appropriate oversight.
Ask whether the platform provides:
This becomes particularly important when an MSSP wants to provide crisis communications as part of a managed resilience or incident response service rather than simply recommending software to clients.
During an incident, communication is part of the response record.
Teams may make significant decisions through chat, video meetings and emergency notifications. After the incident, the organisation may need to establish:
A crisis communication platform should therefore provide a reliable audit trail.
Look for:
This is particularly important for MSSPs because the communications record can form part of the evidence supporting the incident response service delivered to the client.
Incident response teams often focus heavily on technical logs.
But the decisions made by people during an incident matter too.
A properly controlled communications environment can provide an additional record of the response: decisions, instructions, escalation and coordination.
That can help organisations demonstrate how they responded, rather than simply reconstructing the technical timeline afterwards.
Ransomware response is rarely limited to the security team.
Depending on the incident, an organisation may need to communicate with:
That means an MSSP should assess the platform's emergency communications capabilities as well as its collaboration features.
Look for multiple delivery channels, such as:
The benefit of multiple channels is resilience.
If one route is unavailable or unsuitable for a particular group, another can be used.
This distinction is important. An emergency notification system may be excellent at sending thousands of messages, but it may not provide the collaborative environment needed to manage the incident afterwards.
Likewise, a collaboration platform may provide excellent chat but lack the ability to rapidly notify an entire workforce.
MSSPs should therefore assess notification and collaboration as complementary capabilities, rather than assuming that one automatically provides the other.
A platform may satisfy all the technical requirements and still be difficult for an MSSP to operate commercially.
The question is: Can the platform become part of the MSSP's service?
Ideally, the MSSP should be able to provision crisis environments for clients, establish the appropriate access controls and then support the client during an incident without creating a significant administrative burden.
Important considerations include:
How quickly can a new client environment be established?
If ransomware has already started, waiting days for an environment to be configured defeats the purpose.
Can the client access its own crisis environment without relying entirely on the MSSP?
The MSSP should provide support and oversight without becoming a single point of failure.
Can the platform be incorporated into the MSSP's existing resilience or incident response proposition?
For some providers, white-labelling or branded environments may be important.
Can the MSSP manage multiple client environments without compromising separation?
This is particularly important for providers supporting large numbers of organisations.
Consider whether licensing works for:
The commercial model needs to make sense for something that may be used infrequently but becomes critical when it is needed.
Before selecting a crisis communication platform, ask vendors questions that test the platform under realistic ransomware conditions.
That last question is particularly important. A resilience platform should itself have a clear resilience story.
There are several approaches that look sensible but can create gaps during a real incident.
Buying another Teams-like application does not necessarily provide an independent fallback.
If it shares the same identity or network dependencies, the organisation may still lose access during a cyber incident.
WhatsApp and similar tools may appear convenient, but they create problems around governance, retention, access control and auditability.
They should not automatically become the organisation's crisis communications strategy simply because they are familiar.
SMS is valuable because it provides an alternative communication channel.
But sending messages is not the same as managing a crisis.
Incident teams still need secure collaboration, documentation, decision-making and auditability.
A crisis communications system is most valuable when it has already been configured, tested and understood.
Trying to establish emergency communications while simultaneously responding to ransomware introduces another operational problem at precisely the wrong time.
Technology alone does not create resilience.
People need to know:
The best platform will still fail if nobody knows how or when to use it.
For MSSPs, crisis communications should be treated as part of the wider incident response service rather than an emergency add-on.
A practical approach is to define a communications playbook covering:
Before an incident - Configure users, groups, escalation paths and critical documents.
At activation - Move authorised personnel into the independent crisis environment and establish the incident structure.
During response - Use secure communication channels for technical coordination, executive decision-making and stakeholder updates.
During recovery - Continue communications while systems are restored and progressively transition users back to normal collaboration tools.
After the incident - Retain the appropriate communications and audit records and use the incident to improve future exercises and response procedures.
This turns the platform from a piece of software into part of the organisation's operational resilience capability.
When comparing platforms, score each against the following criteria:
| Capability | What to look for |
|---|---|
| Out-of-band access | Independent of corporate IT, network and identity |
| Secure communication | Controlled, encrypted crisis communications |
| Collaboration | Chat, channels and incident-specific spaces |
| Video | Secure crisis meetings and external participation |
| Emergency communications | SMS, email, voice and other notification channels |
| Document access | Critical information available during IT outages |
| Client separation | Isolated environments for each customer |
| Access control | Role- and group-based permissions |
| Auditability | Comprehensive, reliable activity records |
| Incident coordination | Tools for managing people, information and actions |
| MSSP management | Central oversight across client environments |
| Provisioning | Rapid deployment before or during an incident |
| Testing | Exercises and rehearsals supported |
| Resilience | Platform has its own robust availability model |
| Commercial model | Works for multiple clients and emergency usage |
The most useful way to evaluate a crisis communication platform is to stop asking how well it works on a normal Tuesday.
Instead, ask what happens during the first hour of a serious ransomware incident.
The client's Microsoft 365 environment may be unavailable.
Corporate email may be inaccessible.
Identity accounts may be compromised.
The security team may have isolated parts of the network.
Executives may be working from different locations.
External incident response specialists may need to join.
The MSSP needs to coordinate the response while maintaining separation between its other customers.
Can everyone who needs to communicate still do so securely?
If the answer is yes, the platform is doing something fundamentally different from another business collaboration tool.
It is providing an independent operating environment for crisis response.
For MSSPs, the strongest approach is to make crisis communications part of the resilience architecture rather than treating it as an emergency workaround.
The right platform should provide an independent channel when normal IT cannot be trusted, secure collaboration for the incident team, reliable emergency notification, controlled access to critical information and a defensible audit trail.
It should also work at the MSSP level, allowing providers to support multiple customers while keeping each client's incident environment appropriately isolated.
Most importantly, it should be ready before ransomware strikes.
Because when the client's systems go down, the question isn't whether the organisation has a communication tool.
It's whether it has a communication environment that was designed to keep working when everything else has stopped.
YUDU Sentinel is designed as an independent crisis communications platform for exactly this scenario.
Sentinel provides MSSPs with separate Sentinel Spaces for client organisations, creating an independent environment where the MSSP and the client's authorised crisis and IT teams can coordinate during an incident.
Each Space can provide secure chat and channels, video crisis rooms, emergency notifications and access to critical documents, while maintaining separation between client environments.
For an MSSP, this creates a practical bridge between its own incident response capability and the client's crisis management team — without requiring the client's normal collaboration environment to be available.
The result is not simply a backup for Teams or email. It is a dedicated communications environment for the period when those systems cannot be relied upon.
When your client's network goes down, their crisis response doesn't have to.