Turning audit findings into a data quality program

September 13, 2026  ·  4 min read

An audit finding is a symptom. Someone ran a check, the data failed it, and now there is a line item that needs a response. The usual response is to fix that one record, write a note, and move on. Six months later the same finding comes back with a different date.

I have closed a lot of these, most recently across four SQL systems for an insurer. The findings that stay closed are the ones where I stop treating the finding as the problem and start treating it as a signal about a gap in the data quality program. Here is the sequence I use.

Start with the data that matters, not all of it

You cannot watch every column, and you should not try. The first job is to name your critical data elements: the fields that carry real risk if they are wrong. In insurance that might be policy number, coverage effective date, or premium. Most teams list too many. A good test is simple: if this field is wrong, does someone make a bad decision, miss a payment, or fail a regulation? If the answer is no, it is not critical.

Turn each finding into a rule

Every finding is telling you a rule that was missing. If the auditor caught null effective dates, the rule is that effective date is required and must be a valid date on or before the policy start. Write it down in plain language, then in code. The point is to move the check upstream, so the data fails your rule before it ever reaches the auditor's.

A finding you fix by hand is a story. A finding you turn into a rule is a control.

Set thresholds you can defend

Not every rule needs to be perfect. Some fields are allowed a small error rate; others are not. Decide the threshold with the business, not on your own, and write down why. When the number is agreed and visible, the conversation shifts from "is this good enough" to "we are inside the threshold we set." That is a much calmer place to be during an audit.

Give every rule an owner

A rule with no owner is a rule no one will fix when it breaks. For each critical data element, name the person or team responsible for the data and the person responsible for the rule. They are often not the same. Put both in the register. This is the step teams skip, and it is the one that decides whether the program survives past the first quarter.

Make it run on its own

The last step is to take the rules off your desk. Schedule them, route the failures to the owners, and show the current state on a dashboard anyone can open. When the program runs without you, the findings stop being surprises. The auditor sees a system that already knows where it stands, which is a very different meeting than the one where you are explaining a spreadsheet.

None of this is exotic. It is critical data elements, rules, thresholds, owners, and monitoring, in that order. The reason it works is not the tooling. It is that you stopped answering findings one at a time and built the thing that answers them for you.