Key Takeaways
- Severity alone misranks work. A critical alert on a disposable asset is lower priority than a medium alert on a revenue-critical system. Business impact is the missing dimension.
- Business impact is a function of the asset: what it does, what data it holds, what depends on it, and what breaks if it is compromised. It is largely independent of the specific alert.
- Effective priority = alert severity combined with asset business impact, producing a single rank that decides escalate, queue or defer.
- SLA clocks bind priority to time. P1 cases get an acknowledgement and containment deadline; lower priorities get proportionally longer windows. TheHive metrics and custom fields track them.
- Escalation rules define who is paged, when, and what happens if an SLA is breached, removing the guesswork from a live incident.
Why Severity Is Not Priority
Detection tools emit a severity: low, medium, high, critical. Severity describes the alert in isolation, how dangerous the detected behaviour is in general. It does not know anything about your environment. A critical malware detection looks identical whether it fired on a throwaway lab VM or on the domain controller that authenticates your entire workforce.
Priority is different. Priority is the order in which a finite team should work a finite queue. It has to account for where the alert fired, because the same technical event has wildly different consequences depending on the asset. Treating severity as priority means analysts spend equal urgency on a compromised test box and a compromised payment gateway, which is exactly backwards.
The fix is to introduce business impact as a first-class input and to compute an effective priority from severity and impact together. This is the core idea behind triage that actually reflects risk, and TheHive gives you the fields and metrics to implement it.
Defining Business Impact
Business impact is a property of the asset, not the alert, so it can be assigned in advance. Build an asset register that tags each system with an impact tier. A practical scheme is four tiers: tier 1 (revenue-critical or holding regulated data, such as payment systems, customer databases, identity providers), tier 2 (important internal systems whose loss disrupts operations), tier 3 (standard endpoints and supporting services), tier 4 (disposable or isolated, such as lab and test environments).
Impact tiers should reflect concrete consequences: financial loss per hour of downtime, regulatory exposure if data leaks, number of users affected, and dependency fan-out (how many other systems break if this one is compromised). A directory server is high impact not because of what it holds but because everything depends on it. Writing down the rationale keeps the tiers defensible when someone disputes a ranking.
Feed this register into the SOC. The cleanest pattern is to enrich every TheHive observable that represents an asset with its impact tier during the SOAR enrichment stage, by looking the host up in the asset database. The case then carries the tier as a custom field, ready to drive scoring.
Need a SOC Stack Built or Tuned?
Codesecure designs, deploys and tunes open source SOC stacks (Wazuh, TheHive, Cortex, MISP, n8n) with documented detection rules, runbooks and analyst handover. ISO/IEC 27001:2022 certified delivery, named OSCP and CISSP consultants, fixed-price proposals.
See SOC Services →Computing Effective Priority
Effective priority combines alert severity with asset business impact into a single rank. A simple, explainable approach is a matrix: severity on one axis, impact tier on the other, with the cell value giving the priority P1 to P4. A high-severity alert on a tier-1 asset is P1. A high-severity alert on a tier-4 asset might be P3. A medium-severity alert on a tier-1 asset could still be P2.
TheHive supports this through case severity, custom fields and the description. The SOAR layer (or a Cortex responder) computes the priority from the enriched data and sets the case severity accordingly when the alert is promoted, so the analyst inherits a queue already ranked by business risk rather than by raw alert severity.
Keep the model transparent and reviewable. Analysts should be able to look at any case and understand why it ranks where it does: this severity, on this asset, in this tier, gives this priority. Opaque scoring erodes trust and gets overridden. Review the matrix quarterly against what actually turned out to matter, and adjust the cells that consistently misrank.
SLA and Time Targets
Priority without time targets is just a label. An SLA binds each priority to deadlines: time to acknowledge, time to begin containment, time to resolve. A typical scheme gives P1 a short acknowledgement window measured in minutes and a containment target measured in a small number of hours, while P3 and P4 get windows measured in business days.
In TheHive, capture the SLA clocks with custom date fields and metrics. Record when the case was created, when it was acknowledged, when containment started and when it closed. The difference between these timestamps is your SLA performance, and because the data lives in structured fields you can report on it rather than guessing.
SLA tracking does two things. Operationally, it makes breaches visible so an aging P1 cannot quietly sit unworked. Strategically, the aggregate data tells you whether the team is staffed and tooled to meet its own commitments. If P1 acknowledgement is routinely late, that is evidence for automation, on-call changes or headcount, expressed in numbers leadership understands.
Escalation Rules
Escalation removes improvisation from the worst moments. Define, before any incident, who is notified for each priority, through what channel, and what happens if a clock is breached. P1 might page the on-call analyst immediately and notify the SOC lead, with automatic escalation to a manager if not acknowledged within the SLA window. P3 simply enters the queue.
These rules are best enforced by automation rather than memory. The SOAR layer watching TheHive can check case priority and timestamps and fire notifications: an initial page on P1 case creation, a reminder if unacknowledged, an escalation to the next tier if the containment clock is breached. The analyst on a bad night does not have to remember the runbook because the runbook is executing itself.
Document the escalation matrix where everyone can see it and rehearse it in tabletop exercises. The first time a team runs its escalation path should not be during a real P1. Rehearsal surfaces the gaps, the wrong phone numbers, the manager who was never told they were in the chain, while the stakes are still zero.
Alert Fatigue Eating Your Analysts?
Whether you need triage automation, case management design, observable enrichment or a managed detection retainer, our SOC lead is available for a 30-minute free scoping call to map the fastest path to a working programme.
Talk to a SOC Lead →Tuning the Triage System
A triage system is never finished. Review it on a regular cadence using the data TheHive captures. Look for cases that were escalated but turned out trivial (the matrix over-ranked them) and cases that were deferred but turned out serious (the matrix under-ranked them). Each is a signal to adjust an impact tier or a matrix cell.
Watch asset tiers especially, because environments drift. A test system gets promoted to production, a database starts holding regulated data, a service becomes a single point of failure as others come to depend on it. If the asset register is stale, the whole scoring model silently degrades, so reconcile it against reality periodically rather than treating it as a one-time exercise.
The goal of all this is a queue that an analyst can trust. When the top of the queue is reliably the thing that most deserves attention, analysts stop second-guessing the ranking and start working it, and that trust is what converts a scoring model from a spreadsheet exercise into an operational advantage.
Resist the temptation to over-engineer the model. A clear four-by-four severity-by-impact matrix that everyone understands beats an opaque weighted formula that nobody can explain, even if the formula is theoretically more precise. Triage scoring lives or dies on analyst trust, and trust comes from transparency. Start simple, prove the matrix matches reality across a quarter of real cases, and add inputs only when you can point to specific cases the simpler model ranked wrong. Complexity you cannot justify with evidence is complexity that will eventually be overridden by an analyst who knows better, at which point the model is no longer the model.
Frequently Asked Questions
Why is alert severity not enough for prioritisation?
Severity describes the alert in isolation and knows nothing about your environment. The same critical detection is far more urgent on a payment system than on a disposable test box. Business impact, a property of the asset, is the missing dimension. Effective priority combines severity with asset impact.
How do I assign business impact to assets?
Build an asset register that tags each system with an impact tier based on concrete consequences: revenue loss per hour of downtime, regulatory exposure, users affected and dependency fan-out. A four-tier scheme works well, from tier 1 revenue-critical or regulated systems down to tier 4 disposable or isolated assets.
How does TheHive support business impact scoring?
TheHive provides case severity, custom fields and metrics. The SOAR layer enriches each case with the asset's impact tier from the asset database, computes an effective priority from severity and impact, and sets the case severity accordingly, so analysts inherit a queue ranked by business risk.
What SLA targets should a small SOC set?
Bind each priority to acknowledgement, containment and resolution deadlines proportional to risk. P1 typically gets an acknowledgement window in minutes and containment in a few hours; lower priorities get windows measured in business days. Track the clocks in TheHive custom fields and report on breaches.
How should escalation be handled in TheHive?
Define, in advance, who is notified for each priority, through what channel, and what happens on an SLA breach. Enforce it with automation rather than memory: the SOAR layer watches case priority and timestamps and fires pages, reminders and escalations automatically. Rehearse the path in tabletop exercises.
Can Codesecure help design our triage and scoring model?
Yes. Codesecure designs business-impact triage models, asset registers, SLA schemes and escalation matrices as part of SOC builds and tuning engagements, implemented in TheHive with the SOAR layer. ISO/IEC 27001:2022 certified delivery with named OSCP and CISSP consultants.
Build a Triage Queue Your Analysts Actually Trust
Codesecure designs business-impact triage, SLA tracking and escalation in TheHive so the top of the queue is always the thing that matters most. ISO/IEC 27001:2022 certified delivery, named consultants, documented runbooks.
