# TwentyCore Incident Response Process

Last reviewed: 2026-05-17

This process describes how incidents should be triaged, contained, communicated, and reviewed.

## Severity Model

- Severity 1: confirmed data exposure, prolonged outage, critical finance/inventory corruption, or severe security event.
- Severity 2: degraded core workflow or integration backlog affecting production users.
- Severity 3: isolated issue with workaround, cosmetic defect, or non-critical support request.

## Response Flow

1. Assign incident owner, technical owner, and customer communication owner.
2. Preserve request IDs, logs, deployment IDs, screenshots, and affected tenant evidence.
3. Classify affected tenants, workflows, data exposure risk, and financial/operational impact.
4. Contain the issue and reduce blast radius.
5. Communicate impact, workaround, next update time, and remediation status.
6. Complete root-cause review and corrective action.

## Tabletop Scenarios

- Database outage or failed migration.
- Suspected tenant data exposure.
- LHDN outage or credential failure.
- Stripe webhook backlog.
- Object storage failure.
- AI provider outage or unsafe output.

## Buyer Evidence To Request

- Incident owner and escalation path.
- Support contact mechanism.
- Post-incident review example.
- Monitoring and alerting coverage.