If a data error returns at every refresh, correcting the report is not enough. An analyst may remove a duplicate from a meeting spreadsheet only for the import process to create it again the next day. The missing capability is an explicit path from a defined defect and its impact to a verified fix at the source, with accountable ownership at each handoff.

Data quality needs a working cycle connecting a report, a decision, an action and an outcome. This article proposes a practical record of the defect, cause, fix and verification, adaptable to a data office and its business and application teams. The example is hypothetical, not an RMG client case or claimed project result. The model is operational guidance, not a mandatory regulatory template.

Define the defect in relation to data use

“The data is inaccurate” is too broad to assign. An actionable report identifies the data asset, expected rule, observed exception, discovery time and affected use. For example: “The same supplier appears under multiple identifiers in the active supplier list, preventing a consistent supplier count.”

First check what the difference means. Apparent duplication may be legitimate if a record represents a branch while a report assumes it represents an entire entity. A blank field may be acceptable early in a transaction. Define the unit of observation and the conditions of the rule before initiating automated deletion or completion.

The UK Data Quality Issues Framework [5] links quality to an asset’s purpose, rules and the impact of non-conformance. That reasoning provides a useful reference; its classifications are not presented here as Saudi obligations.

Make the issue reproducible

Assign an identifier and link the issue to its dataset, rule version and measurement window. Record both affected records and records tested: “twenty errors” does not establish scale without the population examined. Retain the method used to extract results so later comparisons do not silently change with the query.

Avoid copying sensitive records into widely distributed messages or issue descriptions. Use controlled evidence references and anonymized or synthetic examples. Separate observation from hypothesis: “Duplicates appeared after import” is an observation; “Import caused the duplicates” needs testing.

A controlled spreadsheet can provide an initial register. Software can route tasks and reminders, but cannot resolve ambiguous rules or ownership. The practical test is whether an authorized colleague other than the discoverer can reproduce the result and understand its consequence.

Assign ownership and prioritize by impact

The data owner resolves questions of meaning and accepts the quality needed for the intended use. A steward coordinates investigation and follow-up. Application, integration or process teams implement changes within their responsibilities. The data office helps standardize the register, escalate decisions and expose dependencies. Roles can be combined in a small organization, but decision ownership must remain explicit.

Consider the affected service or decision, the reach of the problem, the next use deadline and the likelihood of recurrence. Record count alone is insufficient: one faulty record may stop an important transaction, while many cosmetic differences may leave an analysis unchanged. Agree response expectations based on impact and available capacity rather than importing another organization’s timescales.

When immediate containment is needed, record it separately from permanent remediation. A team might pause a report refresh, show a quality limitation or restrict use of an affected dataset. Give containment an owner and review point so that a temporary arrangement does not become indefinite.

Temporary containment and permanent repair are related workstreams, each with ownership, limits and follow-up evidence.

Find the first divergence in the data journey

Trace a record through creation, import, transformation, storage and reporting. Compare the same identifier at transfer points, checking field definitions, transformation versions and recent changes. Investigate where the result first diverged from the rule, rather than blaming the team where the issue was finally visible.

Write a testable explanation: “The import route creates a supplier without checking the reference identifier, allowing the same supplier to be created again.” Test it with safe data and a counterexample. Does the duplicate still appear when the identifier is correctly supplied? If the proposed change does not affect the failure, the hypothesis is not a confirmed cause.

Official data quality action plan guidance [6] connects root-cause work to assigned actions. Locally, distinguish correcting existing records from changing the route that creates new ones. One can succeed while the other remains unresolved.

Separate record correction from root-cause closure

A cleaned file can coexist with an input route that keeps generating the same error. Record two separate outcomes: the status of historical records and the prevention of defects in new records. Containment may make a report suitable for a limited use while permanent remediation remains open. The data owner should explain that distinction instead of labelling every outcome “closed”.

For personal-data corrections, Article 17 requires the controller to notify other recipients of the amendment and make it available to them. [8] Where this applies, include recipient copies in the correction plan; changing the source does not establish that every downstream system has been updated.

Design a test that proves the fix without hiding the issue

Keep a small case set containing a previously failing record, a valid record that should remain acceptable, and an edge case requiring an owner’s decision. Run the same rule before and after the change, explaining any change in definition or scope. If the rule changes, rebuild the baseline rather than attributing all apparent improvement to remediation.

Test the downstream use as well. Did the correction reach the report or consuming system? Were links to historical transactions preserved? Record what was not tested and who will accept or complete it. If the issue reopens, connect it to the earlier cause and evidence so the team can distinguish recurrence from a different cause.

Connect the defect, cause, fix and verification

“Change completed” is not sufficient closure evidence. The proposed card connects the business decision with technical implementation; add fields when the data’s characteristics require them.

Card element	What to record	Review question
Defect	Asset, rule, scope, time and impact	Was the result reproduced?
Owner	Data owner, coordinator and implementer	Who resolves meaning and closes?
Cause	Hypothesis, test, evidence and rejected alternatives	Was the origin established?
Interim action	Temporary action, limits and review point	Do users understand restrictions?
Fix	Historical correction, prevention and rollback	Are both workstreams covered?
Validation	Before/after test, independent sample and monitoring	Is the intended use restored?
Closure	Owner’s decision, evidence, residuals and follow-up	Are remaining risks recorded?

 

A hypothetical example: duplicate suppliers after import

Suppose a test examines 1,000 records and flags 40 as potential duplicates. These numbers are illustrative; they do not establish that every flagged record is wrong. A steward and procurement representative discover that some records represent legitimate branches, while others result from repeated supplier imports. They first refine the matching rule to distinguish the two and establish a new baseline under the agreed definition.

Testing confirms that the import route does not check the reference identifier before creation. The team changes it to identify a conflict and route it for review, then prepares a correction for historical records subject to the owner’s decision. Similar-looking records are not automatically deleted because linked transactions may depend on them.

Verification submits a synthetic file that has already been loaded and another containing a legitimate new supplier. The new supplier should be accepted, while the repeated record should raise the intended conflict without creating an unintended additional supplier. After historical correction, the team checks affected reports and integrations. Success in one table does not prove that every consuming system is correct.

Closure connects the previous defect, the fix result and recurrence testing. This conceptual illustration does not represent measured results.

Close with evidence and watch for recurrence

Define closure conditions before implementation: required tests, the verifier and a monitoring period suited to the refresh cycle. Compare results using the same method and disclose changes in scope. An improved percentage created by excluding difficult records is not necessarily an improvement in the asset.

The Government Data Quality Framework guidance [7] highlights repeated measurement and communicating limitations. Tell report owners what changed, what remains uncertain and whether previous outputs need reissuing. Record either closure or a deliberate risk decision, rather than leaving the issue indefinitely unexplained.

Monitor recurrence, reopened issues, case age by severity and the time between discovery and containment. When causes repeat, combine preventive actions into a process improvement rather than treating every record as an isolated incident.

RMG’s material on data quality and decision support connects governance with ownership and monitoring. This cycle makes that connection a daily operating practice, traceable from an issue report to closure evidence. [2]

RMG’s data management office service [4] includes data quality, analysis, validation and monitoring. A useful starting point is a small set of actual issues: identify whether the missing element is a rule, owner, remediation route or closure evidence. That makes quality improvement an operating practice teams can follow and assess.