Incident Response Communication Plan Template

Standard Operating Procedure: Incident Response Communication Plan

1. Document Control Block

• Document ID: SOP-TR-IRCP-042
• Effective Date: October 24, 2023
• Version: 2.4.0
• Review Cadence: Semi-Annual (Every 6 Months)
• Owner: Chief Architect, Template Registry (Julian Vance)

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional framework, protocol, and templates for internal and external communications during critical system outages, security breaches, and infrastructure degradations at Template Registry.

The purpose of this document is to eliminate ambiguity during high-stress operational events, ensure strict compliance with regulatory disclosure mandates, maintain stakeholder trust, and provide structured channels for engineering, executive, and public-facing updates.

---

3. Scope & Prerequisites

3.1 Scope

This procedure applies to all engineering teams, site reliability engineers (SRE), product owners, customer support representatives, and executive leadership within Template Registry and its wholly owned subsidiaries. It governs all incidents classified as Severity 1 (Sev-1) and Severity 2 (Sev-2).

3.2 Prerequisites & Tooling

• Primary Communication Platform: Enterprise Slack (#inc-command, #sys-alerts)
• Secondary/Failover Communications: PagerDuty, Microsoft Teams (Out-of-Band)
• Incident Management Platform: Jira Service Management / PagerDuty Incident Response
• Public Status Page: Statuspage.io (status.templateregistry.internal / external)
• Conference Bridge: Dedicated Zoom/Webex Bridge (Always-On URL pinned in #inc-command)

---

4. Roles & Responsibilities (RACI Matrix)

• Responsible (R): The role that performs the activity.
• Accountable (A): The role with final approval and ownership.
• Consulted (C): The role providing advisory input.
• Informed (I): The role kept updated on progress.

---

5. Step-by-Step Procedure

Phase 1: Triage and Initial Notification (T+0 to T+15 Minutes)

• 1.1 Detect anomaly via automated monitoring or user report; declare Sev-1 or Sev-2 via PagerDuty.
• 1.2 Incident Commander (IC) spins up the dedicated Zoom bridge and activates the #inc-[YYMMDD]-[slug] Slack channel.
• 1.3 Communications Lead drafts and publishes the initial internal notification within 10 minutes of declaration.
• 1.4 Communications Lead updates the external Status Page to "Investigating" within 15 minutes of Sev-1 confirmation.

Template: Initial Internal Broadcast

[SEV-1 ALERT] Incident Declared: [System/Service Name]
- Time Detected: [UTC Timestamp]
- Impact: [Brief description of user/system impact]
- Incident Commander: @[Handle]
- Bridge: [URL] | Slack: #[Channel]
- Next Update: T+30 Minutes

Phase 2: Active Investigation & Cadenced Updates (T+15 to Resolution)

• 2.1 Engineering Response Lead provides technical telemetry updates to the IC every 20 minutes.
• 2.2 Comms Lead issues structured status updates every 30 minutes for Sev-1 incidents (60 minutes for Sev-2).
• 2.3 Legal and Compliance review draft communications if the incident involves data exfiltration or regulatory impact.
• 2.4 Post updates to the public status page only after validation by the Engineering Lead.

Template: Status Update Broadcast (Internal/External)

[UPDATE - SEV-1] Template Registry [Service Name] Outage
- Current Status: [Investigating / Identified / Monitoring]
- Summary: [Non-technical summary of current mitigation steps]
- ETA to Resolution: [Time or "Under Investigation"]
- Next Update: [UTC Timestamp]

Phase 3: Resolution & Incident Closure (T+Resolution)

• 3.1 Engineering Lead confirms service recovery, metric stabilization, and removal of feature flags/rate limits if applicable.
• 3.2 IC updates the public Status Page to "All Systems Operational" and archives the incident status.
• 3.3 Comms Lead publishes the "All Clear" notification to internal channels.
• 3.4 IC schedules the Post-Mortem (Blameless Retrospective) for within 48 business hours.

Template: Resolution Broadcast

[RESOLVED] Template Registry [Service Name] Restored
- Resolution Time: [UTC Timestamp]
- Root Cause Summary: [1-2 sentences on what failed and how it was fixed]
- Post-Mortem Link: [Jira/Confluence URL]

---

6. Quality Assurance & Pro-Tips

6.1 Best Practices

• Single Source of Truth: Direct all external inquiries exclusively to the public status page and designated PR representatives. Never speculate on root cause in public channels.
• Asynchronous Clarity: Use clear timestamps (UTC) in all written communications to eliminate timezone confusion across distributed teams.

6.2 Common Pitfalls to Avoid

• Premature Root Cause Analysis: Do not communicate definitive causes until logs and traces are verified. State symptoms, not unconfirmed causes.
• Communication Blackouts: Even if there is no new information, issue an update on schedule to prevent stakeholder panic.

6.3 Metric Thresholds

• Time to Acknowledge (TTA): $\le 5\text{ minutes}$ for Sev-1.
• Initial Public Status Update: $\le 15\text{ minutes}$ from incident confirmation.
• Update Cadence Adherence: $\ge 95%$ compliance with scheduled update intervals.

---

7. Frequently Asked Questions

• Q: Who has the authority to update the public status page?
  • A: Only the designated Communications Lead and the Incident Commander hold the permissions and authority to update the public status page. This prevents conflicting messaging.
• Q: What triggers a mandatory legal review of an incident communication?
  • A: Any incident involving suspected PII/data exposure, third-party SLA breaches, or active extortion/ransomware vectors requires sign-off from Legal and Compliance prior to external publication.