The first audit always finds more than clients expect. The second one, twelve months later, finds different things.
That second set of findings is what drift looks like. A system that was reviewed and partially fixed twelve months ago has already accumulated new gaps, because the hiring process has moved on and the ATS configuration hasn't followed it.
In the months after any review, the process moves on and the configuration doesn't always follow. New interview stages get added informally, without anyone updating the stage definitions in the system. Integrations break after platform updates and get added to the to-do list.
When a senior recruiter or TA ops person leaves, the informal knowledge of why certain automation rules exist often leaves with them. Within 18 months of a review, most ATS configurations have accumulated enough drift that a second look would find new gaps the first one couldn't have caught.
The HRIS runs the same pattern. A pay structure change gets processed without updating the payroll integration. An absence policy gets rewritten without touching the tracking configuration. Each change is small. Each one moves the system slightly further from how the team is actually operating.
A source-of-hire tracking gap that's misdirecting £5,000 a year in recruitment marketing spend costs £15,000 over three years if nobody looks at it. The configuration fix is the same whether you address it in year one or year three. The difference is what you've lost in the meantime.
That's the compounding argument in its simplest form. The cost accumulates while the gap stays the same configuration problem it was in year one. The misdirected budget and the manual workaround hours keep running until someone measures them.
Data quality compounds in a particular way. Two years of unreliable source-of-hire data is two years of recruitment marketing decisions made without proper attribution. By the time someone investigates, the bad data is baked into the reporting history. Fixing the configuration going forward is straightforward. Recovering what the bad data obscured is harder.
The first audit establishes the baseline: what's underused, what's misconfigured, and what those gaps are costing. The second audit measures something different: how much the system has drifted since the baseline was set, and what new gaps have opened in the time since.
A first audit surfaces the accumulated technical debt from implementation and the months that followed it. A second audit surfaces what change in a business does to a system that wasn't designed to absorb it: new teams, new role types, new hiring volumes, new integrations added without reviewing the existing configuration.
The teams that get the most from a second audit are usually the ones that acted on the first one. They fixed the priority items, improved the data quality, and then kept running. Twelve months later, their system looks different because their business looks different. The second audit catches the gap between the two.
Financial audits exist because anyone who runs a business knows that financial systems drift. Entries get made incorrectly, reconciliations get missed. The annual audit is the mechanism that catches the drift before it compounds into something harder to unwind.
ATS and HRIS configurations drift in exactly that way. Hiring processes change and people leave, taking their institutional knowledge of why things were set up as they were. The annual review is the mechanism that keeps the configuration honest.
Most TA and HR teams run a system review when something forces it: a new platform, or a problem that became impossible to ignore. Annual audits are how you get ahead of the forcing function. We're working to make this a standard practice, because the teams that treat it as one have systems that stay closer to their operating reality and costs that stay lower over time.
If it's been more than twelve months since anyone looked at your ATS configuration properly, the drift has probably started. That's what an annual review is for.