How to Build a Data Quality Issue Register That Leads to Action

Data quality problems rarely arrive as a neat list. They appear as a surprising chart, a failed join, an unexplained null, or a message saying that “the totals look wrong.” Without a shared way to record and assess those discoveries, analysts repeatedly investigate the same symptoms while important decisions remain buried in notebooks and chat threads. A data quality issue register turns that disorder into an actionable queue.

What a data quality issue register should accomplish

An issue register is more than a list of suspicious values. It is a structured record of observed problems, their analytical consequences, and the decisions made about them.

A useful register should help a team answer five questions:

1. What exactly was observed?
2. What evidence supports the observation?
3. Which datasets, columns, reports, or decisions could be affected?
4. Who is responsible for the next action?
5. How will the team verify that the issue is resolved?

This structure separates detection from correction. An analyst may be able to demonstrate that invoice dates precede account creation dates without knowing whether the source system, transformation logic, or business definition is responsible. Recording the evidence first prevents an uncertain diagnosis from being presented as a fact.

The register also creates continuity. If the same symptom reappears next month, the team can compare it with a previous case instead of beginning another investigation from memory.

Define fields that support decisions

A spreadsheet, database table, ticketing system, or version-controlled file can all hold an issue register. The tool matters less than the information captured.

Start with these fields:

• Issue ID: A stable identifier that can be referenced in code reviews, reports, and discussions.
• Date detected: When the problem was first observed.
• Dataset and field: The affected data asset and, where relevant, its column.
• Observation: A neutral description of what was found.
• Evidence: A query, profile result, sample of affected records, or reproducible test.
• Expected condition: The rule or assumption the data appears to violate.
• Potential impact: The reports, models, joins, or decisions that may be affected.
• Severity: A triage category based on impact and urgency.
• Owner: The person or team responsible for investigation or remediation.
• Status: For example, new, investigating, accepted, correcting, or verified.
• Decision: The chosen response and its rationale.
• Verification: The test that must pass before closure.

Keep observations factual. “Customer IDs are broken” is hard to assess. “The current extract contains blank values in customer_id, which is used as the left-side join key for the retention report” is specific and testable.

Avoid placing raw sensitive records in the register. Store only the minimum evidence needed, use masked examples where appropriate, and link to a controlled location for restricted details.

Separate severity from record count

A common triage mistake is to rank issues only by the number of affected rows. Frequency matters, but it does not determine impact by itself.

A single duplicated payment identifier could affect financial reconciliation. Thousands of harmless capitalization differences in an unused notes field might have little immediate effect. Severity should consider the role of the field, the downstream use, and the reversibility of a wrong decision.

A practical severity model can use four levels:

• Critical: The issue could cause a materially wrong decision, regulatory problem, corrupted output, or unsafe publication. Work should pause until it is understood.
• High: A key report, model, contractual field, or business process is likely to be wrong, but containment is possible.
• Medium: The issue affects analysis quality or creates recurring manual work without invalidating the primary output.
• Low: The issue is cosmetic, isolated, or currently outside an important workflow.

Add a separate confidence label if the diagnosis is uncertain. Severity describes potential impact; confidence describes how strongly the available evidence supports the explanation. Keeping them separate prevents an alarming but weak hypothesis from being treated as a confirmed root cause.

Record evidence that another analyst can reproduce

An issue is easier to resolve when another person can recreate it without reconstructing the original analyst’s notebook.

Suppose an analyst finds orders with a delivery date earlier than the order date. A weak entry says:

Some delivery dates look incorrect.

A stronger entry records:

• Dataset version or extraction date
• Fields compared: ordered_at and delivered_at
• Condition tested: delivered_at < ordered_at
• Number or sample of matching records, without exposing unnecessary sensitive data
• Relevant parsing assumptions, including time zone and date format
• The downstream metric that uses delivery duration

Evidence should distinguish raw values from interpreted values. A string such as 03/04/2026 may be valid but ambiguous. The issue might be inconsistent date conventions rather than an impossible date. Recording the raw representation and the parsing assumption makes that distinction visible.

Automated assessment can supply repeatable evidence, but it does not replace interpretation. A profiling or assessment workflow can identify patterns worth reviewing; an analyst must still connect those patterns to business use. EazyDataFix users can consult the assessment documentation for one approach to structuring this stage.

Assign an explicit response to every accepted issue

Not every issue should be “fixed” by changing values. Once an issue has been confirmed, choose a response deliberately:

• Correct at source: Appropriate when the authoritative system can be repaired and the data reissued.
• Correct downstream: Used when a defensible transformation is available and source correction is not immediate.
• Quarantine: Keep questionable records out of a particular output while preserving them for investigation.
• Annotate: Retain the values but attach a warning, quality flag, or limitation to the analysis.
• Accept temporarily: Document why the issue is tolerable, who approved that decision, and when it will be reviewed.
• Reject the input: Stop processing when a required condition is not met.

For example, unexplained negative quantities should not automatically be converted to positive values. They might represent returns. The register should capture that uncertainty and route it to someone who understands the transaction semantics.

Every decision needs a rationale. “Closed” is a status, not an explanation. A useful closure note states what changed, what remained unchanged, and why.

Close issues with verification, not reassurance

A message saying that a source file was corrected is not sufficient evidence of resolution. Define a verification test when the issue is opened, then run it against the corrected or replacement data.

For a uniqueness issue, verification might require the identifier to satisfy a uniqueness rule in the next delivery. For an invalid range, it might require every accepted value to fall within an approved boundary, with known exceptions documented separately. For inconsistent categories, it might compare observed labels with a controlled list.

Also check for side effects. Removing duplicate rows may reduce totals; parsing dates may introduce missing values when strings cannot be interpreted. Verification should confirm both that the original condition has changed and that the response did not create a new problem.

Where possible, preserve the assessment, cleaning changes, warnings, and final test result together. This creates a reviewable trail instead of an unexplained final file. The EazyDataFix examples provide additional workflow ideas for repeatable data checks.

Put the register into a regular operating rhythm

A register becomes stale when it is treated as documentation written after the real work. Make it part of the workflow:

1. Log a reproducible observation when it is discovered.
2. Triage impact, urgency, and confidence.
3. Assign an owner and target decision date.
4. Record the selected response before altering data.
5. Verify the result with an explicit test.
6. Review recurring issues for a reusable rule or upstream correction.

Begin with one dataset that regularly creates analytical rework. Create the core fields, add current open issues, and choose a short recurring review. The immediate goal is not a perfect governance system. It is a reliable path from “this looks wrong” to an evidence-based, owned and verified decision.