Before the incident
Incident communication plan for small SaaS teams
Build a lightweight incident communication plan with clear triggers, one communication owner, verified facts, channel routing, stage templates, and handoffs.
Define the communication trigger
Write down the verified, team-owned condition that starts customer communication, such as confirmed customer-visible impact or a team-approved incident declaration. Your team defines the trigger; this guide does not set an incident classification.
Name one communication owner and one backup
Assign one person to coordinate drafting, review, publication, and the next-update commitment. Name a backup who can take over the same responsibilities without creating a second, conflicting message stream.
Choose the verified fact source
Identify the agreed place where the owner gets confirmed impact, scope, first-observed time, current state, unknowns, and the next-update commitment. The owner should publish from that record rather than infer progress.
Map audiences to channels
Record which audiences your team reaches through its status page, customer email, in-app notice, or support response. Keep the facts aligned across the channels you choose; there is no universal routing policy.
Prepare stage templates
Keep editable Investigating, Identified, Monitoring, and Resolved shells with explicit placeholders for verified facts. Templates should preserve unknowns and never turn a blank field into a remediation or recovery claim.
Assign next-update ownership
Name who owns each specific next-update time and who publishes a factual no-change update when investigation continues. Transfer that commitment explicitly if the owner changes before the promised time.
Mark review and escalation boundaries
Record which topics require your team’s security, legal, regulatory, contractual, or SLA review before publication. Route those questions through your own policies and reviewers instead of treating this writing guide as authority.
Define handoff and recordkeeping
Retain each published message, publication time, and channel. At handoff, transfer the verified fact source, current draft, open review items, and every active communication commitment, then have the incoming owner acknowledge them.
Free Markdown template
Copy-and-edit incident communication plan
Name the people, sources, channels, review routes, and handoff details your team owns before the next incident.
# Incident communication plan Replace every bracketed field with a team-owned answer before using this plan. ## Plan owner - Product or service: `[product or service]` - Plan reviewed: `[date, time, and timezone]` - Communication owner: `[name or role]` - Backup communication owner: `[name or role]` ## Communication trigger - Team-defined trigger for customer communication: `[verified condition]` - Trigger confirmed by: `[name or role]` - Team-owned incident record: `[record or link]` ## Verified fact source - Confirmed impact, scope, state, and time source: `[system, record, or role]` - Fact approver: `[name or role]` - Known unknowns are recorded at: `[record or link]` ## Audiences and channels | Audience | Channel | Publication owner | Access tested | | --- | --- | --- | --- | | `[audience]` | `[status page, email, in-app, or support]` | `[name or role]` | `[yes or no]` | Add one row for each audience and channel your team uses. ## Stage templates - Initial acknowledgment: `[template or link]` - Ongoing investigation or no-change update: `[template or link]` - Identified or mitigation update: `[template or link]` - Monitoring update: `[template or link]` - Resolution update: `[template or link]` - Customer follow-up: `[template or link]` ## Next-update ownership - Team-defined cadence or rule: `[interval or rule]` - Owner of the next specific update: `[name or role]` - Next update commitment: `[date, time, and timezone or team-defined state change]` - Backup or handoff route: `[name, role, or process]` ## Review boundaries - Security and privacy review route: `[role or process]` - Legal, regulatory, contractual, SLA, and notification review route: `[role or process]` - Information excluded from customer messages: `[sensitive categories under your process]` ## Handoff record - Current verified incident state: `[state]` - Last customer update: `[time, timezone, channel, and record or link]` - Next update commitment: `[time, timezone, or team-defined state change]` - Open reviews and owners: `[items and owners]` - Incoming owner acknowledgment: `[name or role, date, time, and timezone]` ## Pre-incident readiness - [ ] Communication owner and backup are named. - [ ] Publishing access for every planned channel was tested. - [ ] Stage templates were reviewed by their owners. - [ ] Every published time will include a timezone. - [ ] Audience and channel facts will be checked for agreement. - [ ] Security, privacy, legal, regulatory, contractual, SLA, and notification review routes are known. - [ ] Credentials and sensitive incident data are absent from this plan. This template supports communication planning only. Your team retains authority for incident triggers, remediation, security, privacy, legal, regulatory, contractual, SLA, and notification duties.
Draft from verified facts.
The free acknowledgment and resolution composer runs entirely in your browser.
Open the composer →