# Major Incident Notification Process

Owner: Incident commander
Approvers: Legal, compliance, security, operations, executive owner

## Major Incident Thresholds

Assess major-incident status when any of these occur:

- customer funds, balances, cards or payment execution are materially wrong or unavailable
- confirmed or suspected data breach involving PII, financial data, card data or secrets
- critical provider outage blocks regulated services beyond contractual or regulatory thresholds
- ledger imbalance, settlement break or reconciliation failure affects customer-visible money
- authentication attack causes confirmed account takeover
- DORA-style ICT incident criteria may apply in the EU

## Notification Matrix

| Audience | Owner | Target timing | Evidence |
| --- | --- | --- | --- |
| Regulators | Compliance/legal | As required by jurisdiction and DORA/NCA rules | impact, root cause, timeline, mitigation |
| Providers | Operations owner | Immediately for provider-dependent incidents | provider references, trace IDs, timestamps |
| Customers | Support/product/legal | After impact and messaging are approved | affected service, action needed, resolution ETA |
| Executives | Incident commander | SEV1 immediate, SEV2 within 30 minutes | status, risk, decision needs |

## Process

1. Appoint incident commander, technical lead, communications lead and compliance/legal owner.
2. Classify severity and regulatory/customer notification threshold.
3. Maintain a timeline with UTC timestamps, request IDs, trace IDs and decision owners.
4. Prepare initial notification with confirmed facts only.
5. Track follow-up notifications, final report and remediation actions.

## Required Closure Evidence

- incident timeline
- impact assessment and affected customer/provider references
- notification decisions and approvals
- customer/regulator/provider messages or documented reason not sent
- root cause, remediation and preventive controls
- post-incident review owner and due date