Incident Severity Matrix

This is the primary axis for classification, measuring the effect on core operations and end-users. It directly ties incident severity to business value and contractual obligations.

• High Severity: A complete outage of a critical customer-facing data product or service, or a violation of a Service Level Agreement (SLA).
• Medium Severity: Degraded performance or partial unavailability affecting a significant user segment or internal business process.
• Low Severity: Minor issues affecting a small subset of non-critical functionality or internal tools with readily available workarounds.

This criterion assesses the scope and irreversibility of corrupted, lost, or inaccurate data. It is critical for compliance, analytics, and machine learning model health.

• Critical: Widespread data corruption or loss with no viable backup, impacting financial reporting or regulatory compliance. Exceeds the Recovery Point Objective (RPO).
• Major: Isolated but significant data quality incidents (e.g., incorrect aggregations, schema drift) that require manual correction and have propagated to downstream consumers.
• Minor: Small-scale data inaccuracies in non-production environments or that are contained and easily correctable.

A quantitative measure of direct monetary loss or risk. This provides an unambiguous, business-centric metric for prioritization.

• P1/Severity 1: Incident causing direct revenue loss (e.g., broken transaction pipeline), potential for regulatory fines, or significant contractual penalties.
• P2/Severity 2: Incident with measurable operational cost increase (e.g., wasted cloud compute) or indirect impact on revenue-generating activities.
• P3/Severity 3: Incident with negligible or no direct financial impact, often related to internal efficiency tools.

Evaluates the breadth of the incident across systems, teams, and data products. It helps distinguish between isolated failures and systemic risks.

• Widespread: Incident originates from a Single Point of Failure (SPOF) or causes cascading failures, affecting multiple pipelines, services, or business units.
• Contained: Incident is limited to a single pipeline, dataset, or microservice, with clear boundaries preventing further propagation.
• Isolated: Incident affects only a development, staging, or testing environment with no production impact.

Measures how quickly data must be restored to meet business requirements. This is closely related to Data Freshness SLOs and Recovery Time Objectives (RTO).

• Urgent: Data required for real-time decisioning (e.g., fraud detection) or hourly business reporting is stale or unavailable.
• Standard: Data for daily or weekly reporting batches is delayed, but business processes can accommodate a short delay.
• Low Priority: Data for archival, historical analysis, or monthly reporting is affected, with no immediate operational consequence.

Assesses violations of legal, security, or industry standards. These incidents often mandate specific response protocols and reporting timelines.

• Severe: Incident involving exposure of Personally Identifiable Information (PII) or data governed by GDPR, HIPAA, or SOC 2, requiring mandatory breach disclosure.
• Elevated: Incident that creates a near-miss scenario for compliance, such as a failure in an audit logging pipeline or a data retention policy violation.
• Minimal: Incident with no material impact on compliance posture or data governance controls.

The initial assessment phase where an incoming alert is validated, its severity is classified using the matrix, and ownership is assigned to initiate the appropriate response workflow. This gatekeeping function prevents alert fatigue by filtering noise and ensuring only genuine issues enter the formal incident management process.

• Key Input: Raw alerts from monitoring systems.
• Key Output: A classified incident with a severity level and assigned responder.
• Example: A triage engineer receives an alert for late data. They check the matrix: Is a critical dashboard affected? If yes, it's a P1; if only an internal report is delayed, it's a P3.

The process of evaluating the business consequences of a data incident, which directly feeds into the severity matrix. This involves quantifying customer, financial, reputational, and regulatory impacts to objectively determine response priority.

• Quantitative Measures: Number of users affected, revenue impact, volume of corrupted records.
• Qualitative Measures: Breach of regulatory compliance (e.g., GDPR), damage to brand trust.
• Process: Performed during triage and continuously updated as the incident unfolds. A high-impact assessment triggers a high-severity classification.

A target level of reliability or performance for a data service, such as 99.9% freshness or 99.99% availability. SLOs are the benchmarks against which incidents are measured. A violation of an SLO is a primary criterion in a severity matrix for classifying high-severity incidents.

• Direct Link to Matrix: An incident that breaches an SLO is automatically classified as high severity (e.g., P1 or P2).
• Example SLO: "Data pipelines will deliver data within 15 minutes of source event 99.5% of the time." A failure exceeding the 0.5% error budget is a severe incident.

The maximum acceptable duration of downtime for a data service or pipeline. The RTO is a critical parameter defined by business stakeholders and dictates the urgency of response codified in the severity matrix. A shorter RTO demands a higher severity classification for any incident threatening that timeline.

• Matrix Integration: An incident impacting a service with a 5-minute RTO would be a P1 (Critical), while one affecting a service with a 4-hour RTO might be a P3 (Low).
• Drives Response: The severity level, informed by RTO, determines the escalation policy and resource mobilization.

A predefined set of step-by-step procedures and checklists for responding to specific types of data incidents. The severity matrix determines which playbook is activated. A P1 incident might trigger a full-scale war room playbook, while a P3 triggers a standard diagnostic checklist.

• Severity-Driven Activation: The matrix acts as a router to the correct procedural guide.
• Content Includes: Immediate containment steps, communication templates, key stakeholders to notify, and diagnostic commands.
• Example Playbooks: "Schema Drift on Customer Table," "Source API Outage," "Data Corruption in ML Training Set."

A structured meeting held after an incident is resolved to analyze what happened, identify root causes, and document follow-up items. The severity matrix dictates the rigor and scope of this review. A blameless postmortem is the gold-standard format, focusing on systemic fixes.

• Severity-Based Mandate: P1 incidents always require a formal, documented review with executive readout. P3 incidents may be reviewed asynchronously.
• Output: Actionable items to improve systems and processes, often leading to updates in the severity matrix itself (e.g., "We underestimated the impact of X; update criteria for Y").