What Happens When a Rights Request Reveals a Data Quality Problem
A single correction request is sometimes just that - a single error. Other times it is the first visible symptom of a data quality problem affecting many other records too.
Reading a correction request as a signal, not just a ticket
Most Section 12 correction requests are exactly what they look like - a single field that is wrong for a single individual, fixed and closed. But some requests point to something bigger: a batch import that mis-mapped a field, a third-party data source that has been feeding incorrect information for months, or a system integration that silently duplicates or corrupts records.
The way to tell the difference is to ask, before closing the ticket, whether the error could plausibly be affecting other records too. A misspelled name is usually isolated. A systematically wrong date format, or a field that consistently pulls from the wrong source system, is a pattern worth investigating further.
Escalating from an individual fix to a root-cause investigation
When a correction request looks like a symptom of something wider, loop in whoever owns the data pipeline or system in question, not just the person handling the individual rights request. The fix for the one Data Principal in front of you should still happen on the normal timeline, but the underlying cause needs its own investigation track, since leaving it unaddressed means more of the same complaint will keep arriving.
This is also where your personal data inventory becomes useful in a different way than usual - if you know which systems and processing activities touch the affected data category, you can scope how far the quality problem might extend without having to rediscover that map from scratch under time pressure.
Deciding whether proactive outreach is warranted
If the root-cause investigation confirms the error affected other individuals who have not yet noticed or complained, it is worth considering whether proactive correction, rather than waiting for each affected person to submit their own request, is the more responsible path. That decision usually needs legal and privacy input together, weighing the scale of the issue against the effort of a broader fix.
Whatever you decide, document the investigation and its outcome, since a data quality issue that surfaces through one rights request and is then found to be systemic is exactly the kind of pattern that would matter if the Board or an internal audit later asked how the organization responds to correction requests.
Where to go next
The Personal Data Inventory and Data Flow Mapper on this site are the right starting points for scoping how far a data quality issue extends once a rights request has flagged it, so the investigation is grounded in an actual map of your systems rather than guesswork.