Runbook: Out-of-Band Communications Plan

Purpose

When a serious incident — ransomware, account compromise, insider threat, Azure outage — hits, the normal communication channels we use every day may be the very channels the attacker now controls. Email running through a compromised Entra tenant, Teams chat on the same tenant, phone system routing through Azure Communication Services, Slack federated to the corporate IdP: none of these are safe to coordinate a response through.

This runbook defines the out-of-band (OOB) communications plan — the channel we use when we cannot trust the usual ones.

Why OOB Comms Are Needed

Three concrete scenarios drive the requirement:

1. Entra / M365 compromise. Attacker with Global Admin has full visibility of every email and Teams message. Using those channels to discuss containment tells the attacker what we know and what we're about to do. In the November 2024 incident we operated under this assumption for the first 12 hours.
2. Account takeover of a single privileged user. If attacker controls Rory's email, using email to coordinate with Kevin and Greg means the attacker reads the response plan in real time. Email is untrustworthy until session revocation and credential reset is complete and verified.
3. Azure / M365 outage. Not an attack — but Teams and Exchange Online can go dark for hours during a Microsoft incident. We still need to coordinate DR failover, customer communication, and vendor calls while the primary comms platform is down.

HIPAA doesn't mandate a specific OOB tool, but Security Rule 164.308(a)(6) (security incident procedures) and 164.308(a)(7) (contingency plan) both require that incident response can proceed even when the primary systems are compromised. OOB comms is how we meet that bar in practice.

Signal as the Primary OOB Channel

Signal Messenger is the designated OOB channel.

Why Signal

• End-to-end encrypted by default — Signal Foundation cannot read messages and neither can anyone who compromises our Azure tenant.
• Personal device only — installed on personal phones, not work-managed devices that might themselves be compromised.
• No federation to our corporate identity — attacker with Entra Global Admin gains nothing against Signal.
• Independent infrastructure — Signal servers are operated by the Signal Foundation, not Microsoft or Amazon.
• Cross-platform — iOS, Android, desktop all supported, so a phone loss doesn't cut someone off.
• Free — no billing relationship to break or payment chain to expose the group's existence.

What it is NOT used for

• Routine operational chat — that belongs in Teams. Keeping Signal quiet means when a message arrives it actually gets noticed.
• Long-form documentation — use bedrock-docs for procedures, not Signal.
• Tickets / tracking — SecOps platform is the source of truth for incidents and change management.
• Approvals — final approvals (apply, suppress, close) happen in SecOps app, not Signal.

Group Membership

Exactly three members, no more:

Member	Role	Contact
Rory	Primary IR lead, architect	Personal phone, Signal username on file in safe
Kevin	T1 DR Domain Admin, leadership escalation	Personal phone, Signal username on file in safe
Greg	T1 DR Domain Admin, leadership escalation	Personal phone, Signal username on file in safe

Rationale for a small group

Three is deliberate. Every additional member increases the chance that one personal device is compromised or lost and drags the whole OOB channel down with it. Paul, Adriana, Arctic Wolf, and external IR retainers are contacted via their own OOB procedures (phone calls, vendor portals) — they do not need to be in the Signal group.

Membership changes

• Adding a member requires Rory's approval and a physical verification (in person, not over Signal or email) of their personal phone number.
• Removing a member (someone leaves the organisation) is immediate — remove on the same day access is revoked elsewhere.
• Annual review of membership happens as part of the Annual Break-Glass Kit Verification runbook.

Pairing and verification

• All three devices must have safety numbers verified pairwise. Signal shows a green check when verified.
• If Signal notifies that a safety number has changed (reinstall, new phone), the group pauses until the change is confirmed in person or by phone call from a number on the printed contact list.

When to Use OOB Comms

Mandatory activation

Use Signal for coordination as soon as any of these is true:

• An incident has been classified P1 — active ransomware, account compromise with admin privileges, data exfiltration in progress.
• The SecOps kill-chain agents fire for execution, credential dumping, or lateral movement stages — because those stages imply attacker-in-tenant.
• Entra ID sign-in logs show admin sign-in from an unrecognised country or IP belonging to a known-malicious ASN, and the account cannot be immediately disabled.
• Microsoft 365 status page shows Exchange Online or Teams degraded or offline for estimated >1 hour and we have active response work to coordinate.
• Any event where the IR lead suspects but cannot prove the primary comms channel is compromised — err on the side of OOB.

Sensible usage

• Everyone acknowledges within 30 minutes of the first message. Silent members break the channel's purpose.
• Keep messages operational. Facts, decisions, next actions. No speculation, no informal chat that would be ambiguous if read later.
• No credentials in Signal, ever. Even end-to-end encrypted — a phone lost or unlocked exposes the message log. Break-glass credentials live in the printed kit; non-break-glass credentials stay in Key Vault.
• Record decisions back in SecOps after the fact. Signal is coordination, SecOps is record-keeping.

Deactivation

Stop using OOB channel and return to Teams once:

1. The primary comms channel has been verified uncompromised (sign-in log review complete, no anomalous admin activity in the last 24h, all compromised accounts disabled and credentials reset).
2. The incident has been contained and moved to the recovery phase.
3. Rory explicitly calls the group off Signal in a final message.

Leaving Signal "always active" defeats the purpose — when a message arrives it should mean something.

Fallback if Signal Is Unavailable

Signal can be unavailable for several reasons: app outage, personal phone loss, Signal Foundation service disruption, or in the worst case an attacker who has compromised the device the Signal app runs on. The fallback chain, in order of preference:

Fallback 1: Phone call to printed personal numbers

• Every member's personal cell number is written in the printed contact sheet in the physical safe (see runbooks/annual-bgkit-verification.md step 4b).
• Phone call is synchronous, voice-authenticated (you can hear the other person), and does not depend on any corporate infrastructure.
• Use for urgent coordination when Signal is dead.
• Limitation: no group chat. Use a rolling call: Rory → Kevin → Greg, each person repeating the message. Accept the delay.

Fallback 2: SMS to personal numbers

• Only if voice fails (no reception, voicemail). SMS traverses the carrier's SMS-C, not end-to-end encrypted, so:
  • Keep messages short and non-sensitive: "Call me on OOB. Rory."
  • Never send credentials, incident details, or response specifics.
  • Assume SMS is readable by the carrier and potentially by an attacker with SIM-swap.

Fallback 3: WhatsApp or iMessage

• Third preference, only if Signal is down but Signal's competitor is still online.
• Not preferred because both are tied to the same kind of personal device as Signal — if the attacker compromised the Signal device they likely compromised these too.
• Verify content via phone call before acting on it.

Fallback 4: Physical meeting

• If all digital comms are untrustworthy: drive to a pre-agreed meeting location.
• The meeting location is documented on the printed contact sheet in the safe (it is not in this document intentionally — don't put it in a file that could be read by an attacker who is browsing our repos).
• Used during the November 2024 event for the first 4 hours of response.

What is NOT a valid fallback

• Corporate email (Exchange Online, M365)
• Corporate Teams
• Slack, Discord, or any channel tied to the corporate IdP
• SecOps platform chat — it runs on Azure we are trying to contain
• Personal email over Outlook.com / Gmail — if the attacker has pivoted to credential phishing there may be credentials in there too

Testing

Test the OOB channel regularly — an untested comms plan is fiction.

Test	Frequency	Owner
Signal group ping ("acknowledge with name")	Quarterly	Rory
Full annual verification (included in BGKIT runbook)	Annually	Rory
Phone fallback drill (voice call to each member)	Annually	Rory
Safety-number re-verification after any phone replacement	On change	Device owner

Failures surface as SecOps stories, tracked, and closed.

Related Documentation

• Incident Response — where to activate OOB from
• Annual Break-Glass Kit Verification — testing
• Offline Backup Procedure — parallel offline control
• Crown Jewel Inventory — assets this protects

Document History

Date	Change	Author
April 2026	BGKIT-005: Initial OOB comms plan — Signal primary, phone/SMS/physical fallbacks	Kobe