Routing depends on data nobody owns
Severity is computed from asset context, and asset context lives in a system somebody stopped maintaining after the project ended.
Severity decides where an alert goes. Severity is usually calculated from asset context: whether this is a domain controller, whether it is production, whether it holds regulated data, who owns it.
That context lives in a system somebody stopped maintaining.
The pattern is familiar. An inventory gets populated properly during a project, then decays. Servers are rebuilt and lose their tags. Cloud instances come up from templates nobody updated. Ownership fields point at people who left. None of it breaks anything visible, because the alert still fires and still lands in a queue. It simply lands in the wrong one, or arrives carrying a severity that does not match what the machine actually is.
The result is a detection programme that is accurate about behaviour and wrong about consequence. Analysts learn to distrust the priority field, which is worse than not having one, because now the routing does nothing and still costs you the maintenance.
You do not need a perfect inventory. You need to know how stale yours is. Take twenty alerts from last week, look up what the routing logic believed about each asset, and compare that against what the asset actually is.
If you cannot run that lookup easily, that is the finding.
CHECK YOURSELF
Alerts from a rebuilt production database server have arrived at low severity for months. The rule logic is correct. Where is the fault most likely to be?
SHOW THE ANSWER
In the asset context the routing logic reads, which lost its tags during the rebuild
Why. Severity is generally computed from what the pipeline believes about the asset, and a rebuild is precisely the event that drops tags without breaking anything visible. Hardcoding severity in the rule moves the problem rather than fixing it, and has to be repeated in every rule that touches those hosts. Relying on analysts to recognise hostnames works until the person who knows them is on leave. The fix belongs where the context is maintained, and the first step is finding out how stale that context is.