In any SOC, the first thing an analyst does with an alert is look at the number next to it. Maybe it says 87. Maybe it’s a red dot, or the word HIGH in a colored box. Whatever form it takes, that number is the single most important thing the platform tells the analyst about the alert. It decides what gets worked first, what gets worked at all, and what quietly sinks to the bottom of the list and never gets touched.
And yet, if you stop the analyst and ask what the 87 actually means, you rarely get an answer. Not what it’s telling them to do, but how it was built. Why 87 and not 62, or 94. Most of the time the honest answer is that nobody knows. The number came out of the platform, it feels roughly right, and the whole operation runs on a figure nobody in the building can actually explain.
This is the strange thing about risk scores. They are the most trusted output in the SOC and the least understood. A score is supposed to be a summary of everything the platform knows about an alert, compressed into one number an analyst can act on in a second. But a summary is only as good as the things it’s summarizing, and most scores are summarizing far less than they appear to.
A useful risk score is really three separate judgments wearing one number. It’s worth pulling them apart, because most platforms only make one of the three and present it as if it were all of them.
The first question: is this even real?
The first thing a score should tell you is how confident the platform is that the alert is a true positive. Not how bad it would be if it were real, but how likely it is to be real at all.
These are different questions and they get confused constantly. A possible ransomware detection on a domain controller is catastrophic if it’s real. That’s impact. But if the same detection fires forty times a week and turns out to be a backup tool ninety-nine times out of a hundred, the confidence that any single firing is real is low. A score built on impact alone paints that alert bright red every time, and produces a queue full of red that everyone learns to distrust. Confidence is what separates the alert worth dropping everything for from the alert that looks scary and almost never is.
The catch is that confidence is hard to fake. You can assign an impact rating from a static table. You cannot assign a true-positive confidence without knowing how alerts like this one have actually behaved. Which brings us to the second question.
The second question: have we seen this before?
A score built only on the alert in front of it is a score with no memory. And memory is most of what makes a human analyst good.
Picture the same encoded-PowerShell alert firing on a backup server at two in the morning. On its own, the indicators look bad, and a memoryless platform scores it high every single time. A senior analyst scores it low in about three seconds, because she remembers this exact job has fired cleanly every Tuesday night for the better part of a year. The alert hasn’t changed. What she has, and the platform doesn’t, is the history.
A real risk score reaches into that history. Has this pattern fired before, on this asset, in this environment? How did it resolve last time, and the forty times before that? If the answer is that it has resolved benign every time for months, that should pull the score down, not to zero, because something might genuinely have changed, but enough that it isn’t sitting at the top of the queue with the same urgency as an alert nobody has ever seen.
This is the component that almost nobody ships, because it can’t be shipped. History has to be learned from your data, your incidents, your false positives, the specific way your environment behaves at odd hours. A vendor can build the machinery that reads history into the score. The vendor cannot supply the history itself. It belongs to your SOC, and a score that ignores it is throwing away the single most valuable signal you have.
It’s also why a brand-new deployment scores worse than one that’s been running for a year, and why that’s a feature rather than a bug. A score that learns starts humble and gets sharper. A score that looks just as confident on day one as it does on day three hundred isn’t using history at all.
The third question: what’s the reasoning?
The newest component, and the one most surrounded by noise, is the AI analysis. Done well, this is where the platform stops handing the analyst a number and starts handing them an argument.
Instead of just scoring an alert, the system reads it the way an analyst would. It pulls the parent process, checks the user’s recent behavior, looks at where the traffic went, weighs the pieces against each other, and produces a short, plain reading of what it thinks is going on and why. The score is the headline. The analysis is the paragraph underneath it that says how the platform got there.
This matters for a reason that has nothing to do with the AI being smart. It matters because a score you can read is a score you can argue with. When the platform shows its reasoning, the analyst can see the place where the logic is right but the conclusion is wrong, where the behavior looks alarming but the business context the model couldn’t see makes it harmless. That catch is only possible if the reasoning is on the screen.
A score without reasoning forces the analyst to either trust it blindly or redo the entire investigation from scratch to check it. Neither is good. The first is how real incidents get closed as false positives. The second is how the AI ends up saving nobody any time.
How the three actually become one number
So far these read like three separate things. The point is that they aren’t. A good score is what you get when all three act on the same alert in sequence, each one adjusting what the last one produced.
Start with the alert on its own. Confidence and impact set the opening number. How likely is this to be real, and how bad would it be if it were. Those two together give you a baseline. A possible ransomware hit on a domain controller opens high. A failed login on a test box opens low. Nothing surprising yet. This is roughly where most platforms stop.
Then history goes to work on that baseline. The platform checks how alerts like this one have actually resolved in your environment, and moves the number accordingly. The ransomware-looking alert that has fired every Tuesday night for a year and resolved benign every time gets pulled down from the baseline, because the evidence says this specific pattern, on this specific asset, has never once been real. An alert the SOC has genuinely never seen before doesn’t get that discount, so it stays high. Same opening number, two different final numbers, and the thing that moved them apart is memory.
AI analysis is the part that explains the result and catches the cases the first two get wrong. It reads the alert in context, weighs the pieces, and either supports the number history landed on or flags a reason to revisit it. The fifteen-gigabyte download opens high on impact, gets little relief from history because it’s unusual, and would sit near the top of the queue, until the analysis notes the file types, the user’s role, and the campaign launching the next morning, and surfaces that context next to the score so the analyst sees in seconds what would otherwise take an hour.
So the number isn’t a single measurement. It’s the end of a short chain. Confidence and impact propose a starting point, history adjusts it based on what really happened before, and AI analysis explains where it ended up and flags when the chain probably got it wrong. The 87 your analyst sees is the output of all three, which is exactly why a platform that only does the first step can produce the same 87 and have it mean far less.
Why one number can’t carry three meanings
Here’s the problem with the single score on its own. The same 87 can mean three completely different things, and the number can’t tell you which.
It might mean the platform is highly confident this is a real threat. It might mean the platform has no idea, has never seen anything like it, and is scoring it high out of caution. It might mean the impact would be severe even though the behavior is almost certainly benign. Three different situations, three different right responses from the analyst, all wearing the same 87.
An analyst who can’t tell these apart ends up treating them the same, which means treating the cautious guess with the same gravity as the confident verdict. Do that a few hundred times and you get the thing every SOC complains about. A queue full of high scores that nobody fully believes, worked top to bottom out of obligation rather than conviction.
The fix isn’t a better number. It’s a score that carries its parts with it. Confidence that this is real. History that says whether you’ve seen it before. Reasoning that shows how the platform got there. Pull any one of those out and the score goes back to being a figure nobody can explain. Keep all three and the analyst is no longer trusting a number. They’re reading a case.
What to ask
When a platform tells you it produces a risk score, the question that matters isn’t how accurate the score is. Vendors will all claim the same accuracy. The question is what the score is made of.
Does it separate how likely the alert is to be real from how bad it would be if it were? Does the score change based on how alerts like this have resolved in your environment before, or is every firing scored as if it were the first? Can the analyst see the reasoning behind the score, or only the number? When the analyst disagrees and overrides it, does the platform learn from that, or produce the identical score tomorrow? And can a junior analyst look at a score and understand not just how high it is, but why?
If the answers come back as some version of “our model produces a number,” you’re looking at a single judgment dressed up as a complete one. If the answers describe confidence, history, and reasoning as three things the platform does and shows, you’re looking at a score an analyst can actually trust, which is the only kind worth having.
That’s the way we’ve built scoring inside Securaa. Not as one number handed down from the model, but as the three judgments underneath it, shown to the analyst so they can see what the score is really saying.
The number next to the alert in your queue is going to decide what your SOC works today. The only question worth asking is whether anyone can explain it.