# 5.4 Communication, Escalation, and External Support

# Goals

During an incident, poor communication can create as much damage as the technical issue.

Leadership may not know what is happening. Employees may keep using affected systems. Vendors may delay support. Customers may hear inconsistent information. Cyber insurance reporting deadlines may be missed. Legal or contractual obligations may be overlooked.

This section defines who needs to be informed, who is allowed to communicate, when outside support is needed, and how communication is recorded.

The goal is controlled communication, not silence and not panic.

# Step 1: Assign a Communication Owner

Assign one person to coordinate incident communication.

This may be the incident response lead, executive sponsor, operations manager, communications lead, legal contact, or another assigned role.

The communication owner does not need to make every technical decision. Their role is to make sure the right people receive accurate updates at the right time.

They should coordinate:

• Leadership updates
• Employee instructions
• Vendor and MSP communication
• Legal and insurance communication
• Customer or partner communication, if needed
• Regulatory or law enforcement communication, if needed

No one should improvise public or customer-facing statements during an incident.

# Step 2: Notify Leadership Early

Leadership should be notified when an incident may affect operations, finances, customer data, employee data, legal obligations, reputation, or recovery capability.

The first leadership update should be short and factual.

Include:

• What happened
• When it was detected
• What systems, users, or data may be affected
• Whether the incident appears active
• What immediate actions have been taken
• What decisions are needed
• What support is required
• When the next update will be provided

Leadership does not need every technical detail at the beginning. They need enough information to make business decisions.

# Step 3: Give Clear Instructions to Employees

If employees need to change behavior during the incident, tell them clearly.

Examples include:

• Do not open suspicious emails.
• Do not use the affected system.
• Do not approve unexpected MFA prompts.
• Do not restart or wipe affected devices.
• Do not delete suspicious messages.
• Do not contact customers about the incident unless authorized.
• Use an alternate communication channel if email or chat may be compromised.
• Report any related suspicious activity immediately.
• Employee messages should be short, specific, and action-oriented.
• Avoid vague warnings that create confusion.

# Step 4: Escalate to Technical Support When Needed

Escalate to the MSP, IT provider, hosting provider, cloud provider, SaaS vendor, endpoint protection vendor, backup provider, domain registrar, DNS provider, or external incident response provider when the company cannot safely contain or investigate the issue alone.

Escalate quickly when the incident involves:

• Ransomware
• Active attacker access
• Compromised administrator accounts
• Cloud or SaaS compromise
• Domain, DNS, or website compromise
• Backup deletion or tampering
• Sensitive data exposure
• Multiple affected systems
• Unclear scope
• Systems managed by a vendor

Technical support requests should be precise. Ask for logs, access history, session records, admin changes, recovery options, containment support, and confirmation of actions taken.

# Step 5: Contact Cyber Insurance, Legal, or Compliance When Required

Some incidents may trigger insurance, legal, regulatory, contractual, or customer obligations.

The company should review its cyber insurance policy, contracts, and compliance requirements before making assumptions.

Contact cyber insurance, legal, or compliance support when the incident may involve:

• Data theft
• Personal information
• Customer confidential data
• Employee data
• Payment fraud
• Ransomware
• Business interruption
• Legal claims
• Regulatory notification
• Customer notification
• Third-party systems or vendors

Do not delay required notifications because the technical investigation is still incomplete. Early notice may be required even while facts are still being confirmed.

# Step 6: Control External Communication

External communication should be approved before it is sent.

This includes communication to customers, partners, vendors, regulators, law enforcement, media, website visitors, and the public.

External statements should be accurate, limited to known facts, and reviewed by the appropriate business, legal, and leadership contacts.

• Avoid speculation.
• Avoid blame.
• Avoid promising timelines or outcomes that are not confirmed.
• Avoid saying “no data was affected” unless that has been verified.

If facts change, update the message carefully.

# Step 7: Use Safe Communication Channels

If the incident may involve email, chat, identity systems, or admin accounts, consider whether normal communication channels are still safe.

The company may need an alternate channel for the response team, such as phone calls, a separate secure chat, personal phone numbers, an emergency contact list, or a vendor-supported bridge.

• Do not discuss sensitive incident details in a compromised mailbox or system.
• Do not send passwords, tokens, evidence files, or sensitive logs through casual chat.
• Use controlled storage for incident evidence and documents.

# Step 8: Record Communication and Decisions

Keep a communication log.

Record:

• Date and time
• Who was contacted
• Who made the contact
• What was shared
• What decision was made
• What action was requested
• What response was received
• Follow-up required

This log should include internal updates, vendor support requests, MSP actions, insurance notices, legal guidance, customer communications, and leadership decisions.

Clear records help prevent confusion and support later review, insurance claims, legal review, customer questions, and post-incident improvement.

# Helpful Tools and Supporting Infrastructure

# Communication Log Template

Use a simple log with these fields:

• Incident ID
• Date and time
• Communication type
• Person or organization contacted
• Contact method
• Message summary
• Decision made
• Action requested
• Owner
• Deadline
• Response received
• Follow-up required
• Evidence or document location

# Expected Outputs from This Section

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

• A named communication owner.
• A leadership notification process.
• Employee instruction templates or guidance.
• MSP, vendor, and external technical support contact paths.
• Cyber insurance, legal, and compliance contact paths.
• Rules for external communication.
• A backup communication method.
• A communication log.
• A process for recording major decisions.

# Objective

During an incident, communication should be fast, factual, controlled, and recorded.

A company should leave this section able to say:

“We know who communicates, who approves messages, who must be contacted, which channels are safe, and where communication decisions are recorded.”

That is communication, escalation, and external support.

---