Impact Assessment

This dimension measures how an incident affects end-users and downstream consumers of the data. It is the primary driver for severity classification and response priority.

• Key Metrics: Number of affected users, degradation in user experience (e.g., failed transactions, incorrect recommendations), and breach of Service Level Agreements (SLAs).
• Example: A data freshness failure causing a real-time dashboard to display stale pricing information for 10,000 active users would constitute a high-severity customer impact.

This dimension quantifies the direct and indirect monetary costs associated with a data incident. It is critical for business continuity planning and cost-benefit analysis of remediation efforts.

• Direct Costs: Revenue loss from transaction failures, contractual penalties for SLA breaches, and costs of engineering hours for remediation.
• Indirect Costs: Operational inefficiencies, wasted compute resources on corrupted data, and potential regulatory fines. A severe incident can escalate from thousands to millions in financial exposure.

This dimension assesses the damage to an organization's brand and trustworthiness due to a data incident. It is often a lagging indicator with long-term consequences.

• Factors: Public disclosure of data quality issues, loss of confidence from partners relying on data products, and negative media or analyst coverage.
• Mitigation: Transparent communication and demonstrable improvements in data observability posture are key to managing reputational risk. A pattern of unresolved incidents can erode stakeholder trust permanently.

This dimension evaluates the disruption to internal business processes, analytics, and machine learning systems that depend on the affected data.

• Scope: Halts in decision-making pipelines, corrupted training datasets causing model drift, and blocked internal reporting.
• Cascading Effects: A single pipeline breakage can stall dozens of dependent ETL jobs and analytical models, paralyzing data-driven operations. This is closely tied to data lineage and dependency mapping.

This dimension determines if an incident violates legal statutes, industry regulations, or internal governance policies. It often triggers mandatory reporting and audit processes.

• Triggers: Incidents involving Personally Identifiable Information (PII), breaches of data residency rules, or failures in auditable financial data pipelines.
• Consequences: Legal liability, mandatory disclosure to regulators (e.g., under GDPR), and suspension of operating licenses. This dimension is paramount in Enterprise AI Governance.

This dimension focuses on the integrity and recoverability of the data itself. It answers questions about data loss, corruption, and the feasibility of restoration.

• Key Concepts: Recovery Point Objective (RPO) defines acceptable data loss, while Recovery Time Objective (RTO) defines acceptable downtime.
• Assessment: Evaluates the scope of corrupted records, the availability of clean backups, and the time required for data reconciliation. Incidents landing in a Dead Letter Queue (DLQ) are isolated here for analysis.

A predefined framework that classifies incidents based on objective criteria to determine response priority. It translates impact assessment findings into actionable severity levels (e.g., P0-P4).

• Key Criteria: Customer impact scope, financial cost, data loss volume, regulatory exposure, and reputational damage.
• Function: Ensures consistent, objective triage by mapping assessed impacts to standardized response protocols and resource allocation.

A target level of reliability or performance for a data service, such as freshness, completeness, or accuracy. Impact is often measured as a violation of an SLO, consuming the team's error budget.

• Example SLOs: "99.9% of dashboard queries return data less than 1 hour old" or "Data pipeline completeness > 99.5%."
• Link to Impact: Breaching an SLO represents a quantifiable degradation of service quality that directly impacts downstream consumers and business operations.

The systematic process for identifying the underlying, fundamental reason for an incident. Impact assessment informs the RCA's scope and urgency, while the RCA's findings refine future impact predictions.

• Process: Moves beyond symptoms (e.g., "dashboard is wrong") to root causes (e.g., "source API schema changed without notification").
• Goal: To implement preventative controls that mitigate the probability and potential impact of similar future incidents.

Two key metrics derived from business impact analysis that define disaster recovery requirements.

• Recovery Point Objective (RPO): The maximum acceptable amount of data loss measured in time (e.g., "we can tolerate losing up to 15 minutes of transaction data").
• Recovery Time Objective (RTO): The maximum acceptable duration of downtime (e.g., "the customer billing pipeline must be restored within 2 hours"). These objectives are set based on the assessed financial, operational, and reputational impact of data unavailability.

A structured review conducted after an incident is resolved, focusing on systemic and process failures rather than individual fault. Impact assessment provides the factual basis for the postmortem's narrative.

• Key Elements: Timeline reconstruction, impact quantification, root cause analysis, and actionable follow-up items.
• Outcome: Documents the incident's business impact and produces recommendations to improve system design, monitoring, and response playbooks to reduce future impact severity.

A specific type of disruption caused by a violation of predefined data quality dimensions. Impact assessment for these incidents focuses on how corrupted data propagates and affects downstream decisions.

• Common Dimensions: Freshness, completeness, validity, uniqueness, accuracy, and consistency.
• Downstream Impact Examples: Erroneous financial reporting, degraded machine learning model performance, faulty operational dashboards, and incorrect customer-facing analytics.