Incident response
Incident response process
The severity model, containment workflow, customer communication expectations, and post-incident review path.
Last reviewed: 2026-05-17. Final contractual commitments must be reviewed before signature.
Triage and severity
Incidents should be classified by customer impact, data exposure risk, workflow blockage, financial impact, and integration impact.
- Severity 1: confirmed data exposure, prolonged outage, or critical finance/inventory corruption.
- Severity 2: degraded core workflow or integration backlog affecting production users.
- Severity 3: isolated non-critical bug, cosmetic issue, or workaround-available fault.
Containment and communication
Containment should preserve evidence, reduce blast radius, and communicate impact honestly without speculating.
- Assign incident owner, technical owner, and customer communication owner.
- Preserve logs, request IDs, deployment IDs, and affected tenant evidence.
- Provide updates with impact, workaround, next checkpoint, and remediation status.
Post-incident review
Every serious incident should produce a root-cause review, corrective action, and regression evidence.
- Capture timeline, root cause, customer impact, and permanent fix.
- Add tests, alerts, runbook updates, or release gates where needed.
- Review whether backup, rollback, or monitoring evidence needs improvement.
Buyer checks
Questions this document should help answer.
Who receives incident notifications?
How quickly are critical incidents acknowledged?
How are customer-impacting bugs tracked to closure?
Do post-incident actions become tests or operational controls?