How to Build a Ransomware Communication Playbook

When a ransomware attack disrupts your organisation, the immediate challenge is not just restoring systems. It is maintaining control of the incident while the technology your teams rely on to communicate may no longer be available or trustworthy.

Email, Microsoft Teams, corporate messaging and shared document repositories can all become inaccessible during a cyber incident. If attackers have compromised identity services or the wider corporate network, even apparently available systems may not be safe to use.

Without a reliable alternative, incident responders can lose contact with business leaders, recovery teams can work from conflicting information, and the board may struggle to make time-critical decisions.

A ransomware communication playbook addresses this risk before an attack occurs. It defines how people will communicate, who has authority to make decisions, where incident information will be recorded and how critical updates will reach the right people when normal systems fail.

This guide explains how to build a practical cyber incident communication playbook that supports incident response, business continuity and executive oversight throughout a ransomware attack.

1. Identify your critical communication requirements

Start by identifying the conversations that must continue during a ransomware incident, regardless of which systems are affected.

Not every employee needs the same information, and not every communication channel needs to remain available. Your playbook should prioritise the functions that enable the organisation to assess the situation, make decisions and coordinate its response.

Consider the requirements of four key groups:

• Incident response teams: Need to exchange technical findings, coordinate containment and recovery activities, and share verified information.
• Executive leadership and the board: Need concise situation reports, an understanding of business impact, clear options and recommendations, and a record of significant decisions.
• Business continuity and operational teams: Need to coordinate alternative working arrangements, protect critical services and understand which activities can continue safely.
• External stakeholders: Customers, suppliers, regulators, specialist incident responders and other relevant parties may need timely, approved communications.

Map these requirements against your critical business services. For example, a financial services organisation may need to coordinate the protection of customer services while assessing the potential impact of a disruption on its regulatory obligations.

The objective is to establish which communications are essential, who needs to participate and what information each group requires.

2. Map the systems that could fail together

A communication playbook is only effective if its alternative channels remain available when the primary environment is compromised.

Document the systems your organisation relies on for communication, collaboration and incident management. This should include email, collaboration tools, identity and access management, mobile applications, telephony and document storage.

Then examine the dependencies between them.

For example, an alternative application may appear independent but still require authentication through your corporate identity provider. If that identity service is compromised or unavailable, the application could become inaccessible precisely when it is needed most.

Your assessment should establish:

• Which communication tools depend on the corporate network.
• Which rely on the same identity provider or authentication infrastructure.
• Whether emergency contacts and instructions are accessible without corporate credentials.
• Which channels can operate independently of the affected environment.
• How users will authenticate and access alternative services securely.

This is where out-of-band communication becomes particularly important.

Out-of-band communication provides an alternative route for exchanging information that does not depend on the systems affected by an incident. Depending on your risk assessment, this might include separately hosted secure messaging, independent crisis communication software, dedicated emergency telephony or pre-agreed alternative channels.

The important distinction is that an alternative channel must be genuinely independent of the dependencies you are trying to bypass. Simply moving a conversation from email to another application may not be enough.

3. Establish an independent crisis communication platform

Once you understand your dependencies, select the communication arrangements that will support the response when primary systems become unavailable.

Consumer messaging applications, personal email accounts and ordinary telephone calls may provide temporary workarounds, but they can introduce security, privacy, access-control and auditability concerns. They may also become difficult to manage when an incident involves dozens of people across multiple teams and locations.

For enterprise organisations, dedicated incident response platforms can provide a more structured approach to emergency communications.

Look for capabilities that support your actual response requirements, including:

• Independent hosting: The platform should remain accessible if the corporate network or primary identity environment is compromised.
• Secure messaging: Incident teams need a controlled environment for sharing updates and coordinating actions.
• Crisis conferencing: Teams must be able to escalate from messaging to secure voice or video discussions when decisions require direct collaboration.
• Mass notification: Designated personnel should be able to alert the right people quickly through appropriate channels.
• Critical documentation: Response plans, contact lists and recovery instructions should be accessible when normal document repositories are unavailable.
• Access controls: Users should only access the spaces and information appropriate to their responsibilities.
• Audit trails: Important communications and decisions should be recorded to support incident review, governance and evidence requirements.

These capabilities serve different purposes. Mass notification helps alert people to an incident; a crisis communication platform helps them coordinate the response that follows.

For example, YUDU Sentinel providesindependently hosted crisis communications, secure chat and video, mass notification, mobile access to critical documents and audit trails. Its Sentinel Spaces architecture can support separate incident or team environments while allowing appropriate central oversight.

The right solution will depend on your threat model, operating environment and recovery requirements. What matters most is that your organisation can activate and access its alternative communications without relying on the infrastructure under attack.

4. Define activation triggers and decision-making authority

A communication playbook should make it clear when normal channels can no longer be relied upon and who has the authority to activate the alternative arrangements.

Without predefined triggers, teams may waste valuable time debating whether an incident is serious enough to warrant escalation.

Establish activation criteria that reflect your organisation's risks. These might include:

• Confirmed or suspected compromise of corporate identity services.
• Loss of access to email or primary collaboration tools during a suspected cyber attack.
• Evidence that attackers have compromised administrative accounts or communication systems.
• A ransomware incident affecting critical business services.
• A security team's instruction to stop using potentially compromised channels.

Not every incident requires the immediate activation of every emergency arrangement. Your playbook should distinguish between initial escalation, partial activation and full crisis communications.

Assign clear responsibilities for each stage. For example:

Define deputies for key roles and establish who can authorise activation if the primary decision-maker is unavailable.

The playbook should also specify who can approve a change in communication arrangements, when information can be shared externally and how conflicting instructions will be resolved.

5. Prepare contact lists and escalation routes

During a ransomware attack, the people responsible for responding may be unable to access the corporate directory or contact management system.

Prepare an emergency contact register that is available independently of those systems. It should contain the information required to reach essential personnel, without unnecessarily exposing sensitive personal information.

Include:

• Incident response and security personnel.
• Executive decision-makers and their deputies.
• Business continuity and disaster recovery teams.
• IT infrastructure, identity and application owners.
• Legal, compliance, risk and communications representatives.
• External incident response specialists and critical suppliers.

For each role, define the primary contact route, an alternative route and an escalation procedure if there is no response.

Contact information must be maintained, access-controlled and tested regularly. Outdated telephone numbers or former employees in an emergency contact list can undermine the entire process.

Consider how you will reach staff who are travelling, working remotely or unable to access corporate devices. You should also establish a process for verifying the identity of participants joining emergency communications, particularly before sensitive information is shared or significant decisions are made.

6. Create a standard incident communication structure

Once the alternative channel is activated, responders need a shared understanding of where information belongs and how updates should be presented.

Without a defined structure, conversations can fragment into multiple groups, critical information can be missed and decision-makers can receive contradictory accounts.

Establish dedicated communication spaces for the principal response functions. These might include:

• Incident command: Overall coordination, priorities and escalation.
• Technical response: Investigation, containment and recovery.
• Business continuity: Service impacts, workarounds and operational priorities.
• Executive updates: Business exposure, decisions required and strategic direction.
• External coordination: Approved communications with suppliers, specialist responders and other relevant parties.

The precise structure will depend on your organisation's size and complexity. Smaller organisations may combine several functions, while larger enterprises may need separate spaces for business units, regions or critical services.

Use a consistent format for incident updates so that information can be understood quickly.

A useful update should include:

1. Time: When the information was reported or verified.
2. Status: What is known about the incident at this point.
3. Impact: Which systems, services or business activities are affected.
4. Actions: What has been done and what is happening next.
5. Risks: What remains uncertain or could deteriorate.
6. Decisions required: What approval or direction is needed, from whom and by when.
7. Next update: When the next report will be provided.

Clearly distinguish confirmed facts from assumptions and unverified reports. This helps prevent speculation from becoming accepted as fact as information moves between technical teams and senior leadership.

7. Establish a reliable process for board communication

Board and executive communication requires particular attention during a ransomware incident. Directors need enough information to exercise oversight and make decisions, but they should not have to navigate a stream of unfiltered technical updates.

Your playbook should define how the incident commander or designated executive will brief the board, how frequently updates will be issued and which decisions must be escalated.

A board-level situation report should cover:

• The nature and current status of the incident.
• The critical services and business operations affected.
• The known or potential impact on customers, employees and suppliers.
• The containment and recovery strategy.
• Significant legal, regulatory, financial or reputational considerations.
• Decisions required from the board or executive team.
• The next expected update and any immediate changes in risk.

Agree a reporting cadence in advance, while allowing urgent updates when material developments occur.

For financial services organisations, this process should take account of applicable regulatory obligations, including relevant DORA requirements and UK FCA operational resilience expectations. For operators of critical national infrastructure, communications arrangements should also reflect sector-specific obligations and the potential consequences of disrupted essential services.

A robust communication process can support accountability and provide evidence of how decisions were reached. It does not, on its own, establish regulatory compliance: the organisation must still meet the requirements applicable to its activities and circumstances.

8. Maintain an incident record throughout the attack

Communication during a ransomware incident is not just about exchanging information. It is also about preserving a reliable account of what happened and why decisions were made.

During a prolonged incident, teams may change shifts, new specialists may join and assumptions may evolve as evidence emerges. Without a consistent record, it becomes difficult to reconstruct the sequence of events or understand the rationale behind key decisions.

Your playbook should define how to record:

• The incident timeline and significant developments.
• Information received and its verification status.
• Decisions, decision-makers and supporting rationale.
• Actions assigned, owners and deadlines.
• Changes to recovery priorities.
• Escalations and approvals.
• Communications with relevant external stakeholders.

Use a dedicated incident record wherever possible, with appropriate access controls and retention arrangements.

If the primary corporate environment is compromised, ensure the record remains accessible independently. Critical documentation should be available through an appropriately secured alternative, rather than relying on a shared drive that may be encrypted or inaccessible.

Where the platform supports it, an auditable record of communications and decisions can help with post-incident reviews, internal governance and the preparation of evidence for relevant regulatory or legal processes. Preserve records in accordance with your organisation's retention, privacy and legal requirements.

9. Test the playbook under realistic conditions

A playbook that has only been reviewed on paper may fail when people need to use it under pressure.

Testing should establish whether the communication arrangements work when normal systems are unavailable, participants are uncertain about the situation and key decision-makers are not immediately reachable.

Run exercises that simulate realistic ransomware scenarios, such as:

• Email and collaboration tools becoming unavailable.
• Corporate identity services being compromised.
• The incident commander being unreachable.
• Technical teams disagreeing about the status of containment.
• A critical supplier being unable to provide support.
• Senior leaders requiring an urgent decision while information remains incomplete.

Test the full process, from initial activation through to board updates and incident recording.

Measure practical outcomes: how long it takes to reach essential personnel, how quickly participants can access the alternative platform, whether the right people receive the right information and whether decisions are recorded consistently.

For a meaningful test, do not assume that everyone remembers their instructions or can access corporate contact lists. Require participants to use the procedures and alternative systems they would actually need during an incident.

Capture the lessons, assign corrective actions and retest significant changes. Review the playbook after major technology changes, organisational restructuring, supplier changes or real incidents.

10. Keep the playbook usable and accessible

The final step is to ensure the playbook can be used when people are under pressure and normal systems may be unavailable.

Keep the activation instructions concise and make the full playbook available through an independent, controlled access route. Provide offline access to the critical information needed to get the response started, including activation procedures, essential contacts, role assignments and initial communication instructions.

Avoid relying on a single individual to understand the process. Deputies should know their responsibilities, and relevant personnel should receive regular training.

Assign an owner to maintain the playbook, with a defined review schedule and a process for approving changes. Ensure the communication arrangements remain aligned with the organisation's incident response, disaster recovery and business continuity plans.

Most importantly, make activation straightforward. An emergency communication arrangement that depends on a lengthy approval process, inaccessible credentials or a complex setup procedure may not deliver the support your organisation needs.

Conclusion: Make communication part of ransomware readiness

Ransomware preparedness is often measured in terms of backups, recovery time objectives and technical containment. These are essential, but they do not address every challenge an organisation faces when its primary IT environment is disrupted.

Your incident response depends on people being able to communicate, share verified information, coordinate actions and make decisions even when normal systems cannot be trusted.

A well-designed ransomware communication playbook provides that structure. It establishes independent communication routes, defines responsibilities, gives boards a clear view of the incident and preserves a record of the decisions made throughout the response.

For enterprise security teams and business continuity professionals, the priority is to prepare these arrangements before an incident occurs, then test them under realistic conditions.

YUDU Sentinel helps organisations maintain crisis communications when their primary IT systems are unavailable. With independently hosted secure messaging, crisis conferencing, mass notification, access to critical documents and auditable communications, Sentinel can form part of a wider ransomware readiness and operational resilience strategy.

When your network goes down, your crisis response doesn't have to.

Explore YUDU Sentinel to learn how independent crisis communications can support your ransomware response planning.