Alert Enrichment: The Context That Makes Triage Possible

"User transferred 340 files to removable media" tells a reviewer almost nothing. They now spend twenty minutes gathering context that a system could have attached automatically.

Enrichment is the difference between a queue that can be reviewed and one that cannot.

What to attach

Who the person is. Role, department, manager, tenure, location. A developer moving code and a receptionist moving code are different events.

Employment context. Notice period, recent role change, active performance process, recent access changes. This is the highest-value enrichment available and the hardest to get, because it requires an HR feed and the governance to justify it.

Handle it carefully: knowing someone is under a performance process changes how an analyst reads their behaviour, and that is exactly the bias you want to avoid. The argument for including it is that it is genuinely predictive; the argument against is that it invites confirmation. If you include it, restrict who sees it.

Their baseline. What is normal for this person and for their peers. "340 files, versus a personal average of 12" is interpretable in a way that the raw number is not.

What the data was. Which category from the inventory, and where it came from. A file from the design repository matters differently from one from the shared marketing folder.

Destination context. Is the domain known, is it a customer, a supplier, a consumer service, newly registered.

Prior events. Has this person triggered before, what was concluded, by whom. Without this, an alert dismissed three times by three people is a pattern nobody sees.

Whether an exclusion nearly applied. If the activity resembles an approved workflow but missed a condition, say so. It is frequently the explanation.

Where enrichment comes from

Identity systems for role, department, manager.

HR systems for employment events. Requires a data-sharing arrangement and usually a conversation about proportionality.

Your own inventory for data category.

Historical alert data for prior events.

Threat intelligence for destination reputation, which is useful for compromised-account cases and largely irrelevant for negligence.

What good looks like

A reviewer opening an alert sees the action, the person, their normal pattern, the data category, the destination, and whether this has happened before — on one screen, without querying anything.

Most triage decisions become obvious at that point. The ones that do not are the ones worth spending time on, which is the whole objective.

The mistake to avoid

Enriching with things that bias rather than inform.

Performance ratings. Salary. Grievance history. Protected characteristics. None of these predicts data theft and all of them shape how an analyst reads an ambiguous event.

If a field would change your interpretation of identical behaviour in a way you could not defend, it should not be on the screen.

Enrichment is also a privacy decision

Every field attached to an alert is personal data about an employee, held in a security system, disclosable to that employee on request.

Attach what is necessary for the decision and no more. A reviewer needs role and baseline. They rarely need date of birth, home address or family status, and products will attach all of it if you let them.

The order of work

Enrichment before more detection rules. Always.

A programme with three well-enriched detections outperforms one with thirty raw ones, because the first can be reviewed and the second cannot.