Assign owners to recurring data quality problems: Name failing rule, dataset, field, first period, record count and affected reports.; Data owner is single accountable owner; use a RACI and log the exception in a workflow.; Separate containment (reporting treatment) from repair (source/system or mapping fix).
Image: Business Insight Stack

Data Governance

Part of Data quality checks

Assigning owners to recurring data quality problems

A data quality alert can identify a fault and still achieve little if no one owns the next step.

Desk Governance · · 4 min read

A recurring data quality issue needs a named accountable owner and separately assigned work for containment, repair and reporting treatment. Put the data owner on the decision, the steward on day-to-day quality work, the custodian or source-system team on system repair, and the reporting owner on the affected report.

Name the problem precisely

Describe the failing rule, dataset and field, first observed period, number of records and affected reports. Attach a reproducible query or sample record IDs, with access controls appropriate to the data. A product classification that conflicts with other records in its category is more actionable than a general statement that data is bad.

Classify the impact on business use: whether a published KPI changes, a noncritical attribute is affected, or access is at issue. Name a data owner from the business area with authority to decide the data’s meaning and acceptable quality, and a data steward for day-to-day quality work.

Assign a data custodian or source-system team to maintain the system and repair its input, and identify a reporting owner for affected reports. Make the data owner the single accountable owner for the issue; record each role and responsibility in the governance framework, and log the exception in a structured workflow. Use a RACI to clarify cross-team actions.

Assigning owners to a recurring data quality problem

  1. Name the problem preciselySpecify the failing rule, dataset and field, first observed period, number of records and affected reports.
  2. Attach reproducible evidenceInclude a reproducible query or sample record IDs with access controls appropriate to the data.
  3. Classify business impactState whether a published KPI changes, a non-critical attribute is affected, or access is at issue.
  4. Name the accountable data ownerChoose a business-area owner with authority to decide the data's meaning and acceptable quality.
  5. Assign day-to-day quality workName a data steward for routine quality work and issue review.
  6. Assign system repairAssign a data custodian or source-system team to maintain the system and repair its input.
  7. Assign reporting treatmentIdentify a reporting owner for affected reports and the agreed treatment.
  8. Log the exception and RACIRecord each role and responsibility in the governance framework and a structured workflow.

Separate containment from repair

Containment is the immediate reporting decision. The reporting owner can pause publication, add a caveat, use a verified unaffected segment or proceed within the data owner’s approved tolerance. Record who authorised the treatment.

Assign repair to the custodian or source-system team when the cause is in the source or system, or to the integration owner when it is a mapping or transformation. Keep the repair assignment separate from the reporting decision; do not quietly replace missing values with defaults or drop rows simply to clear an alert.

If the problem returns, the steward should review whether the previous fix addressed the cause. A backfill may correct last week’s data while the next load still fails. Track recurrence by rule and origin, not just by ticket count; the data owner approves a changed expectation when a data definition legitimately changes.

Containment versus repair for a recurring data quality issue

  • ContainmentImmediate reporting decision by the reporting owner: pause publication, add a caveat, use a verified unaffected segment or proceed within the data owner's approved tolerance. Record who authorised the treatment.
  • RepairFix the cause via the custodian or source-system team when it is in the source or system, or the integration owner when it is a mapping or transformation. Keep repair separate from the reporting decision; do not quietly replace missing values with defaults or drop rows to clear an alert.
  • Recurrence reviewIf the problem returns, the steward reviews whether the previous fix addressed the cause. Track recurrence by rule and origin, not just ticket count. A backfill may correct last week's data while the next load still fails.
  • Changed expectationThe data owner approves a changed expectation when a data definition legitimately changes.

Close with evidence

Close an issue when the affected period is corrected or explicitly accepted, the check passes on a relevant new batch, and the decision record and test result are retained. If old reports remain affected, state their period and status rather than marking the issue complete for every consumer.

A recurring data problem may reflect an unresolved decision about what a metric should mean. The data owner resolves the definition, while the reporting owner applies the agreed treatment to affected reports.

Closing a recurring data quality issue with evidence

  • Affected period is corrected or explicitly accepted
  • The check passes on a relevant new batch
  • The decision record and test result are retained
  • Old reports are stated with their period and status rather than marked complete for every consumer
  • The data owner resolves any unresolved definition question
  • The reporting owner applies the agreed treatment to affected reports

More from Data Governance