Model Drift and Retraining

A model trained on last year's environment is scoring this year's behaviour. Nothing errors. The output continues to look plausible. Detection quality degrades continuously and invisibly.

The kinds of drift

Data drift. The distribution of inputs changes. A new tool is deployed, a source changes format, a population migrates to different systems. The model is now scoring data unlike its training data.

Concept drift. The relationship between behaviour and risk changes. Remote work is the canonical example: behaviour that was anomalous in 2019 became universal, and models built before it flagged the entire workforce.

Population drift. The entity population changes. Growth, acquisition, outsourcing, a contractor programme. Peer groups no longer represent what they did.

Label drift. Analyst judgement changes as the team turns over. What was dismissed last year is escalated this year, and any model trained on adjudications inherits the inconsistency.

Detecting it

Score distribution over time. The most useful single indicator. Plot the distribution weekly. A shift without a corresponding environmental change means the model, not the behaviour, changed.

Alert volume per detector. Sudden changes indicate a data problem; slow changes indicate drift.

Feature distribution monitoring. For each feature, its distribution across the population over time. A feature whose distribution moves is either reflecting real change or breaking.

Precision over time. From adjudication. A falling rate is the clearest evidence that something is wrong, and it requires the label capture that most deployments skip.

Baseline age distribution. What fraction of entities have baselines older than the intended window.

Entity resolution rate. A falling rate means the identity landscape moved.

When to retrain

On a schedule. Simple, predictable, and it retrains when nothing changed and misses changes between cycles.

On trigger. When drift indicators cross thresholds. More responsive and it requires the instrumentation above.

On known events. Reorganisation, migration, acquisition, major policy change. These are knowable in advance and they are the largest single source of drift.

Per entity, on role change. Not a full retrain — a reset of one baseline. This should be automatic from an HR feed and rarely is.

The practical answer for most deployments is scheduled retraining with event-driven exceptions, plus per-entity resets on role change.

The retraining trap

Retraining on recent data means retraining on data that may contain an attacker.

Every retrain is an opportunity to normalise ongoing malicious behaviour. Rolling baselines have this property continuously, which is why a slow adversary can move the baseline underneath the detection.

Mitigations:

Keep a long-term reference baseline alongside the rolling one, and treat divergence between them as a signal in itself. This is one of the few defences against baseline poisoning that does not depend on catching the intrusion.

Exclude periods under investigation from training data.

Compare each entity's new baseline against its previous one; a large shift with no known cause is worth examining before it is adopted.

Retain the ability to retrain from a chosen historical window.

Versioning

Models change and findings must remain explicable.

Version every model and record which version produced each score. When a finding from six months ago is questioned, you need to know what was scoring at the time.

Retain the baseline snapshot used for a finding, not just the score. Without it, "the model found this unusual" cannot be substantiated.

Log retraining events with date, data window and reason. A score that changed because the model was retrained is a different thing from a score that changed because behaviour did, and without the log nobody can tell.

A drift dashboard

Six charts, reviewed monthly, that between them make drift visible.

Score distribution by week. The single most informative view. Shape changes without environmental cause mean the model moved.

Alert volume per detector by week. Sudden steps are data; gradual slopes are drift.

Feature distributions across the population. One panel per key feature, showing the median and spread over time.

Entity resolution rate.

Baseline age distribution.

Precision from adjudication, rolling over a quarter.

Annotate the charts with known events — migrations, reorganisations, retraining, source changes. A shift with an annotation is explained; a shift without one is the thing to investigate.

Common false positives

Drift and behaviour are easily confused, and the distinguishing feature is usually scope:

Population-wide shifts are almost always environmental or technical, not behavioural.

Retraining artefacts, where the same activity scores differently after a model update.

Source format changes altering feature values without any change in what people did.

Seasonal effects mistaken for drift when the baseline window does not span the cycle.

Coverage changes — new hosts onboarded, old ones decommissioned — shifting aggregate distributions.

Growth, where a larger population naturally produces more extreme values at the tail.

Checking whether a change affects one entity or many resolves most of these immediately.

Blind spots and assumptions

That the vendor manages drift. Managed services retrain on their schedule, frequently without notifying you, which means your score distribution can shift for reasons you did not cause and cannot see.

That drift is gradual. It is frequently abrupt — a migration completes on a Tuesday.

That retraining fixes it. Retraining on drifted data adopts the drift as normal, which is correct if the change was legitimate and precisely wrong if it was not.

That stability means health. A completely stable score distribution can also mean a dead data source.