Data Quality Incident Classification & Response Matrix

Purpose

This tool helps teams rapidly classify data quality incidents and take consistent, measurable action. Use it to decide who owns triage, what immediate steps to take, how and when to notify stakeholders, and which SLA to apply—so decisions remain trustworthy and mean-time-to-resolution falls.

How to use

1. Describe the incident briefly (title, detection source, affected systems).
2. Choose Impact and Urgency that best describe business effect and required response speed.
3. Apply the prescribed triage steps for that matrix cell, pick an owner, and follow the notification template and SLA target.
4. Record actions taken, link observability checks and lineage, and close the loop with a corrective action and owner.

Definitions (quick)

• Impact: What business processes, decisions, customers, or regulatory obligations are affected if the defect persists?
• Urgency: How quickly must the issue be acknowledged or mitigated to avoid unacceptable harm?
• Classification cell: The combination of Impact × Urgency that defines prescribed triage steps, owner type, notification scope, and SLA.

Quick reference matrix (cells and recommended response)

Standard triage checklist (apply for every incident)

1. Record: title, detection time, detection source, brief impact statement, systems/tables affected.
2. Classify: pick Impact and Urgency and identify matrix cell.
3. Acknowledge: meet SLA for acknowledgement and log the owner.
4. Contain: apply mitigation (stop job, rollback, switch to fallback) if safe and available.
5. Investigate: gather observability checks, lineage, recent deploys/changes, and input samples.
6. Communicate: send the notification template to the defined scope and update at agreed cadence.
7. Remediate: fix root cause and apply data correction where required.
8. Close the loop: run a post‑incident review, assign corrective actions, and add monitoring or data contracts to prevent recurrence.

Notification templates

Use these as a starting point and edit for context. Replace placeholders like {system}, {impact}, {detectedAt}, {owner}, and {nextSteps}.

Short alert (for critical/immediate)
Subject: [URGENT] Data quality incident — {system} — {impact}
Body: We detected a data incident in {system} at {detectedAt}. Impact: {impact}. Owner: {owner}. Immediate action: {nextSteps}. We will provide updates every {cadence} until resolved.

Informational (for medium/low)
Subject: Data quality issue logged — {system}
Body: A data issue affecting {system} was detected (impact: {impact}). Owner: {owner}. Expected resolution timeframe: {sla}. Details and links: {links}.

Example incidents & run-through scenarios

• ETL job fails before business close: Impact = Critical, Urgency = Immediate. Action: Page on‑call, stop downstream jobs, enable fallback dataset, notify finance and ops, create incident ticket.
• Backfilled data with wrong timezone offset: Impact = High, Urgency = Medium. Action: Acknowledge same day, schedule correction, notify dashboard owners, add validation check on ingestion.
• Minor schema mismatch in a rarely used table: Impact = Low, Urgency = Low. Action: Log for data steward, fix in next sprint, add schema contract test.

Links and observability checks to collect during triage

• Recent pipeline job logs and run history
• Column-level quality checks (null rates, distribution drift, row counts)
• Data lineage to identify downstream consumers
• Recent deploy/change logs and PRs affecting schemas or jobs
• Relevant dashboards and report samples

Ownership and roles

• Reporter: Person who discovered or first reported the issue.
• Owner: Team or person accountable for triage and resolution (data engineering, analytics lead, or data steward depending on cell).
• Incident lead: For Critical incidents, a cross‑functional lead who coordinates updates and stakeholder communication.
• Business owner: The product or domain owner who confirms business impact and acceptance of fixes.

Closing the loop

After resolution, capture:

• Root cause and timeline
• Corrective actions and owners (who will change code, adjust process, update SLA, or add monitoring)
• New or updated observability checks and data contracts
• Lessons learned and any regulatory reporting required

Implementation tips

• Start with a small set of practical checks and SLAs tied to real decisions—avoid over‑engineering theoretical failure modes.
• Embed a short form (or use this tool interactively) in your incident intake so classification, owner, and initial actions are recorded consistently.
• Keep notification templates short and provide clear next steps—stakeholders most need to know impact, owner, and cadence.
• Make the matrix repeatable: review SLAs quarterly and adjust to arrival patterns and business needs.

Links: Link this tool to your runbooks, ticketing system, and data observability dashboards so classification and ownership flow into operational workflows.