Data quality issue management process flowchart
Data quality issue management template for reporting one defect, assessing impact, containing use, confirming cause, remediating data and closing with evidence.
What the data quality issue management process is
A quality issue becomes harder to control when the report, affected records and business impact live in separate messages. This template creates one record, checks for a reproducible duplicate, classifies severity and identifies affected consumers before technical work begins. Critical or spreading issues trigger notification and containment, while routine issues still receive a steward and technical resolver. Diagnosis must confirm both the cause and the affected set so remediation can correct the source control, reprocess downstream outputs and avoid leaving inconsistent copies behind.
This chart follows one issue; it does not define the wider quality program. Rules, thresholds, scheduled monitoring and long-term trend improvement belong in /templates/data-quality-management-process, which may trigger this process whenever a monitored threshold is breached. A disputed owner, shared definition or remediation trade-off can be escalated through /templates/data-governance-process without turning every issue into a council case. Here, closure depends on validated records, acceptance by the owner and consumer, authorized removal of any containment, and linked evidence. Preventive work can continue after closure under a named action and due date without keeping the incident itself permanently open.
What this flowchart covers
In this template
- Issue reporting with affected data, consumer impact, examples, reproducibility and duplicate linking
- Severity triage and a meaningful decision on critical impact or uncontrolled downstream spread
- Containment, ownership, technical reproduction, origin tracing and escalation when the cause or affected set remains unclear
- Approved correction of source data and controls, followed by reprocessing and reconciliation of dependent outputs
- Steward validation, owner and consumer acceptance, containment removal, closure evidence and preventive follow-up
When to use this template
- Data defects are reported through chat or email and duplicate investigations start before affected consumers are identified
- Teams fix visible records but do not confirm the source failure or reconcile copies already sent downstream
- High-impact issues lack a consistent containment and escalation path while routine issues wait for the same level of meeting
- Issue tickets close when code is deployed rather than when corrected data and dependent outputs have been accepted
How it works
Define a usable issue record
Require the asset or field, observed result, expected result, examples, time range, affected use and reporter contact. Add a duplicate search before triage so related reports strengthen one investigation instead of fragmenting it.
Set severity and containment triggers
Base severity on consumer impact, spread, time sensitivity and recoverability. For each level, state who must be notified, whether use is paused or labeled, and who may authorize removal of containment.
Confirm cause and affected set together
Trace the issue to its source and identify every record, period and downstream output that may be affected. Escalate when access, ownership or technical evidence prevents either conclusion rather than guessing from the first example.
Plan end-to-end remediation
Separate correction of existing records from the source or control change that prevents recurrence. Include reprocessing, mapping, cache, extract and consumer reconciliation steps that apply to your data path.
Define acceptance and closure
Write tests for the corrected records and dependent outputs, identify the accepting owner and consumer, and retain the results. Create a linked preventive action when broader work remains, with its own owner and due date.
Frequently asked questions
What are the steps in data quality issue management?
Record and deduplicate the report, classify severity and impact, contain use when needed, assign stewardship and technical ownership, reproduce and trace the issue, confirm cause and affected records, approve and execute remediation, reconcile outputs, validate with owners and consumers, remove containment, document evidence and assign preventive follow-up.
When should a data quality issue be escalated?
Escalate when impact or spread exceeds the team's authority, urgent containment is needed, ownership is disputed, the source or affected set cannot be confirmed, or remediation creates a cross-domain trade-off. Define these triggers before an incident so escalation does not depend on who notices it.
What is the difference between correction and preventive action?
Correction repairs the affected records and outputs for this issue. Preventive action changes the source process, design, monitoring or control to reduce recurrence. Both may be needed, but they should have separate evidence and ownership so restoring current data is not mistaken for eliminating the pattern.
When can a data quality issue be closed?
Close after the affected set is addressed, source and downstream corrections are reconciled, agreed tests pass, owners and consumers accept the result, containment is removed by the authorized role, and the record links its evidence and any remaining preventive action.
Where this process fits
In most operations this process follows Data quality management process flowchart and hands off to Data governance process flowchart (issue to closure).
Comes before
- Data quality management process flowchart — Data quality management process template for prioritizing critical data, defining measurable rules, monitoring results and sustaining preventive improvements over time.
Comes after
- Data governance process flowchart (issue to closure) — Data governance process template for scoping issues, assigning ownership, assessing cross-domain impact, recording decisions, implementing actions and closing with evidence.