# 6.4 Communication and Business Continuity During Recovery

# Goals

Recovery can take time.

Some systems may return quickly. Others may remain unavailable, limited, or under investigation. Employees may need temporary workarounds. Customers may need service updates. Vendors may need revised instructions. Leadership may need regular status reports.

This section defines how the company communicates during recovery and how the business continues operating safely while systems are being restored.

The goal is to avoid confusion, unsafe workarounds, duplicate work, customer misinformation, and premature return to normal operations.

# Step 1: Assign Recovery Communication Ownership

Assign one person to coordinate recovery communication.

This may be the recovery lead, communications owner, operations manager, executive sponsor, or another assigned person.

The communication owner should coordinate updates to leadership, employees, vendors, customers, MSPs, insurers, legal contacts, and affected business teams where needed.

This does not mean one person writes every message. It means one person controls the message flow so information stays accurate and consistent.

Why this matters:

During recovery, different teams may hear different versions of what is happening. A single communication owner reduces confusion and prevents unauthorized or inaccurate updates.

# Step 2: Define Who Needs Updates

Identify who needs recovery updates and how often.

Common groups include:

• Leadership
• IT or MSP
• Department managers
• Employees
• Customer service team
• Finance team
• HR team
• Sales team
• Operations team
• Vendors
• Customers or partners, if affected
• Legal, compliance, or cyber insurance contacts, if involved

Not every group needs the same level of detail.

Leadership needs business impact, decisions, timelines, and risk.

Employees need clear instructions on what systems to use, what not to use, and what to report.

Customers need accurate service information if their work or data may be affected.

Technical teams need restoration status, dependencies, blockers, and validation results.

# Step 3: Provide Clear System Status Updates

During recovery, maintain a simple list of system status.

Use clear categories such as:

• Unavailable
• Restoring
• Available for testing
• Available for limited use
• Available for normal use
• Restricted until further notice

Do not tell users a system is “back” unless it has been validated and approved for the intended use.

A status update should explain what users can do, what they should avoid, who is affected, and when the next update is expected.

Why this matters:

A system may be technically online but not safe for normal use. Clear status language prevents users from re-entering unsafe systems too early.

# Step 4: Manage Temporary Workarounds

Some business processes may need temporary manual or alternate procedures while systems are restored.

Examples include manual invoice review, phone-based customer support, alternate file access, delayed approvals, paper forms, temporary order tracking, offline payroll validation, or limited-access email procedures.

Every workaround should have an owner, start time, expected end time, security rules, approval requirements, and recordkeeping method.

Avoid unsafe workarounds such as personal email, unmanaged file-sharing links, shared passwords, uncontrolled spreadsheets, or unapproved messaging apps.

Why this matters:

Workarounds can keep the business moving, but they can also create new security, privacy, financial, and operational risks if they are not controlled.

# Step 5: Protect Customer, Vendor, and Partner Communication

If customers, vendors, or partners are affected, communication should be approved before it is sent.

Messages should be factual and limited to confirmed information.

Avoid speculation, blame, unsupported reassurance, or promises that have not been validated.

Customer-facing teams should be given approved talking points so they do not improvise.

If legal, insurance, regulatory, or contractual obligations may apply, external communication should be reviewed by the appropriate owner before release.

Why this matters:

Poor external communication can damage trust, create legal exposure, and make later corrections difficult.

# Step 6: Keep Business Continuity Decisions Recorded

Record major recovery decisions.

Include:

• Which systems are available
• Which systems remain restricted
• Which temporary workarounds are approved
• Who approved the workaround
• What risks are accepted temporarily
• Which customer or vendor messages were sent
• Which business processes are operating normally
• Which processes are still limited
• When the next status review will occur

Why this matters:

Recovery creates many small decisions under pressure. If those decisions are not recorded, the company may lose track of what was approved, what remains risky, and what still needs to be restored.

# Step 7: Confirm When Workarounds Can End

Temporary workarounds should not become permanent by accident.

As systems are restored and validated, business owners should confirm whether manual procedures can stop.

Before ending a workaround, confirm that the restored system works, required data is present, access is correct, security controls are active, and the business owner approves returning to the normal process.

Why this matters:

Old workarounds can create duplicate records, missed transactions, data inconsistencies, unauthorized sharing, and confusion over which version of information is correct.

# Step 8: Communicate Recovery Completion or Remaining Limits

When recovery is complete, communicate what has returned to normal and what still remains under review.

If recovery is only partially complete, say so clearly.

A recovery completion update should include:

• Systems restored
• Systems still limited
• Temporary procedures ending
• Temporary procedures still active
• Known remaining risks
• Who to contact for issues
• What employees should continue watching for
• When the incident moves to Review

Why this matters:

Recovery does not end just because the most visible system is back online. The company should close the recovery phase cleanly and prepare for review.

# Business Continuity Areas to Check

During recovery, confirm the status of:

• Email and communication
• Customer service
• Finance and payments
• Payroll and HR
• Sales and CRM
• Order processing
• Production or service delivery
• File storage
• Websites and customer portals
• Vendor access
• Remote access
• Backup and monitoring
• Legal, insurance, or customer obligations
• Manual workarounds

# Common Recovery Communication Mistakes

• Do not say a system is safe before validation is complete.

• Do not let each department create its own version of the recovery message.

• Do not allow employees to use personal email or unmanaged file sharing unless formally approved as an emergency exception.

• Do not restart customer communication without approved talking points where customers are affected.

• Do not leave temporary workarounds undocumented.

• Do not forget to tell employees when a workaround has ended.

• Do not make broad claims such as “no data was affected” unless that has been verified.

• Do not stop communicating just because technical restoration has started.

# Helpful Open Source and Affordable Tools

These tools may help to maintain secure communication and achieve business continuity:

# Practical Tool Stack for SMEs

# Very small company:

Use a recovery email group, shared recovery document, Uptime Kuma, Healthchecks.io, Trello or Kanboard, and a simple status tracker.

# Microsoft-based SME:

Use Teams, SharePoint, Microsoft Lists, Planner, Microsoft 365 email groups, Jira Service Management or Zammad, and Uptime Kuma for service visibility.

# Google Workspace SME:

Use Google Meet, Google Chat, shared Google Docs or Sheets, Google Groups, Zammad or Jira Service Management, and Uptime Kuma or Healthchecks.io.

# Cost-conscious open-source setup:

Use Mattermost or Zulip for internal communication, Nextcloud or CryptPad for recovery documents, Zammad or GLPI for tickets, Kanboard or OpenProject for task tracking, and Uptime Kuma for system status.

# Customer-facing service company:

Use Cachet or Statusfy for status communication, approved customer talking points, Jira Service Management or Zammad for customer issues, and a communication log for all external updates.

# Recovery Communication Log Template

Use a simple communication log with these fields:

• Incident ID
• Date and time
• Audience
• Communication owner
• Channel used
• Message summary
• Systems or processes mentioned
• Instructions given
• Decision made
• Approval required
• Approved by
• Follow-up required
• Next update time
• Document or evidence location

# Business Continuity Tracker Template

Use a simple tracker with these fields:

• Business process
• Business owner
• Current status
• System dependency
• Temporary workaround
• Workaround owner
• Security rules
• Approval required
• Customer impact
• Vendor impact
• Data handling notes
• Expected return to normal
• Validation required
• Final status
• Notes

# Expected Outputs from This Section

At the end of this section, the company should have:

• A recovery communication owner.
• A defined audience list for updates.
• Clear system status language.
• Approved employee instructions.
• Approved customer, vendor, or partner messages where needed.
• Documented temporary workarounds.
• A business continuity tracker.
• A recovery communication log.
• A record of major business continuity decisions.
• Confirmation of when temporary workarounds ended.
• A final recovery status update or remaining-limits update.

# Objective

Recovery communication should keep the business moving without creating new risk.

A company should leave this section able to say:

“People know which systems are available, which processes are limited, what temporary procedures apply, who approved them, and when normal operations can resume.”

That is communication and business continuity during recovery.

---