Incident Action Plan Template WORD

Standard Operating Procedure: Incident Action Plan (IAP) Development

Template Registry Engineering Operations

---

1. Document Control Block

---

2. Executive Summary & Purpose

This procedure defines the standardized generation of an Incident Action Plan (IAP) within the Template Registry ecosystem. The purpose is to formalize the tactical response to service disruptions, ensuring rapid stabilization, clear communication, and audit-ready documentation. This template serves as the authoritative structure for all high-severity incidents.

---

3. Scope & Prerequisites

• Scope: Applicable to all Tier-1 and Tier-2 engineering incidents affecting production services.
• Required Tools: MS Word (docx), Jira Service Management (linked), Slack (incident channel), PagerDuty.
• Prerequisites:
  • Incident Commander (IC) must have active credentials for the incident management suite.
  • Access to the "Master_IAP_Shell.docx" template.

---

4. Roles & Responsibilities (RACI Matrix)

---

5. Step-by-Step Procedure

Phase I: Immediate Assessment (T+0 to T+15m)

• Initialize incident channel in Slack.
• Create a blank IAP document from OPS-IAP-001-Template.
• Populate Document Control metadata (Incident ID, Timestamp).

Phase II: Objectives & Strategy (T+15m to T+60m)

• Define the primary operational objective (e.g., "Restore 99.9% availability of Service A").
• List high-level strategy (e.g., "Roll back deployment v1.2, verify latency").
• Assign sub-tasks to relevant engineering squads.

Phase III: Execution & Progress Tracking

• Document current service metrics (Baseline vs. Current).
• Log active mitigations attempted.
• Maintain a chronological "Event Log" for compliance.

Phase IV: Closure & Handover

• Finalize "Resolution Narrative" section.
• Transition from "Active Incident" to "Post-Mortem Review" status.
• Export IAP to PDF and archive in the Incident Registry.

---

6. Quality Assurance & Pro-Tips

• Pro-Tip 1: Keep the IAP document open in a browser-based word processor for real-time collaboration. Avoid local file-locking.
• Pro-Tip 2: Use the "Scribe" role to update the IAP while the IC focuses on technical resolution.
• Common Pitfall: Over-documenting minor steps. Focus on decisions and outcomes rather than every CLI command executed.
• Metric Thresholds: Any IAP remaining open > 4 hours requires escalation to the CTO.

---

7. Frequently Asked Questions

Q: Should I document every failed attempt in the IAP? A: No. Focus on the decisions that led to changes in the environment. Failed diagnostic attempts should be summarized briefly to prevent "analysis paralysis."

Q: What if the incident involves multiple services? A: The IAP must be scoped to the primary affected service; create sub-task dependencies if necessary, but keep the core document focused on the central bottleneck.

Q: Is the IAP a replacement for the Post-Mortem? A: Absolutely not. The IAP is a tactical, real-time document. The Post-Mortem is the retrospective, qualitative analysis of root causes and long-term remediation.

---

End of Procedure - Julian Vance, Chief Architect