Alert Prioritisation Gaps

A technology services vendor's SIEM contained correlation rules that had been assigned static severity levels , High, Medium, and Low , when the rules were written. The severity assignments were based on the technique's risk profile at the time of rule development. The alert review SLAs were: High alerts reviewed within thirty minutes, Medium within four hours, and Low within twenty-four hours. When threat intelligence from the vendor's sector ISAC indicated that a specific threat actor group was actively targeting technology services vendors in the region and had been observed using a specific lateral movement technique involving WMI execution from a remote host, the intelligence briefing was distributed to the security team. The briefing was acknowledged. No one updated the severity assignment for the SIEM rule that detected WMI remote execution , a rule that had been written two years earlier when WMI remote execution was classified as Medium because it was relatively common as a legitimate administrative technique and required specific additional context to confirm malicious intent. Three days after the intelligence briefing, the rule fired on an authentication event followed by WMI remote execution , the specific sequence the intelligence had described. The alert entered the Medium queue. The four-hour review SLA meant the alert was reviewed at hour three and forty minutes , after the attacker had established a scheduled task persistence mechanism and begun staging data. The alert was correctly classified for a world where WMI remote execution was a medium-risk indicator. In a world where that specific technique was the primary TTP of an active threat actor group targeting the vendor's sector, it should have been reviewed in thirty minutes.

What are Alert Prioritisation Gaps, Really?

Alert prioritisation gaps are the misalignments between static alert severity assignments and the dynamic risk context that makes specific techniques more or less dangerous depending on the current threat landscape. Alert severity levels are assigned when rules are written based on the technique's general risk profile at that time. As the threat landscape evolves , new threat actor groups emerge, existing groups change their TTPs, sector-specific campaigns begin , the relative danger of specific techniques changes. Static severity assignments that do not account for current threat context systematically misalign SOC response urgency with actual risk.

The static assignment problem is the operational mechanism. Detection rules are written by detection engineers who assign severity based on the technique's general risk profile , how often it is seen in malicious vs legitimate contexts, how much additional context is needed to confirm malicious intent, and how severe the potential impact is if the technique is used maliciously. These assessments are accurate at the time of assignment. They are not automatically updated when threat intelligence changes the risk profile of specific techniques. The four-hour review SLA for a technique that becomes the primary TTP of an active threat actor group targeting the vendor's sector is a four-hour window that was designed for a different threat context.

The threat intelligence-to-prioritisation gap is the specific failure mechanism. Threat intelligence teams receive and distribute intelligence about current threat actor TTPs. Detection engineering teams write and maintain rules for those TTPs. Prioritisation teams assign and update severity levels for alert categories. In siloed organisations, the intelligence that changes the risk profile of a technique does not automatically reach the prioritisation decision , and the analyst who reads the ISAC briefing may not have authority to update the severity assignment for the relevant SIEM rule.

• Static severity assignments not updated when threat intelligence changes risk context
• TTP intelligence not reaching prioritisation decisions , ISAC briefing not triggering severity update
• Four-hour medium review SLA for primary TTP of active threat actor
• No contextual prioritisation , current threat actor targeting not adjusting alert severity
• Intelligence-to-prioritisation gap , separate teams without integration

Why this matters

Alert prioritisation gaps matter for TPRM because the SOC's response speed to a specific alert is determined by its severity level , and a severity level that does not reflect current threat context produces response speeds that are calibrated for a threat landscape that no longer exists. A vendor's thirty-minute, four-hour, and twenty-four-hour SLAs are meaningful only if the severity assignments that route alerts into those queues are aligned with the current threat landscape.

Where most teams get this wrong

The most consistent failure is assessing alert SLA compliance without assessing whether severity assignments are current. SLA compliance measures whether alerts are reviewed within their assigned SLA. Severity alignment measures whether the assignments route alerts to the appropriate SLA for their current risk context.

• SLA compliance assessed without severity alignment
• No threat intelligence-to-prioritisation pipeline , intelligence not triggering severity reviews
• Severity assignments not reviewed following threat intelligence
• Static vs dynamic prioritisation not distinguished in assessment
• Active threat actor TTP prioritisation not specifically assessed

What good looks like

Mature alert prioritisation programmes integrate threat intelligence into the severity assignment process , specifically reviewing and updating severity levels for detection rules that match techniques identified in current threat actor intelligence , and implement contextual prioritisation that temporarily elevates severity for specific techniques when active targeting intelligence is received.

• Threat intelligence-to-prioritisation integration , ISAC briefings triggering severity reviews
• Temporary severity elevation for techniques matching active threat actor TTPs
• Regular severity review cadence , quarterly review of all rule severity assignments
• Contextual prioritisation capability , same rule producing different priority based on current context
• Priority update authority , analyst ability to temporarily elevate priority based on intelligence

Tooling

SIEM with Dynamic Prioritisation , Microsoft Sentinel with threat intelligence integration, Splunk with risk-based alerting

SIEM platforms with threat intelligence integration can dynamically adjust alert severity based on current IOC and TTP context , elevating the priority of alerts that match active threat actor techniques. For TPRM practitioners, asking whether the vendor's SIEM implements risk-based alerting or dynamic prioritisation based on threat intelligence provides a specific contextual prioritisation question.

Governance challenges

The governance challenge with dynamic prioritisation is the escalating alert volume risk. Elevating the severity of specific techniques during active campaigns increases the volume of high-priority alerts , which reduces the per-alert analysis time available for genuinely high-severity events. The governance resolution is time-bounded elevation: temporarily elevated priority for techniques matching active threat actor intelligence, with automatic reset after a defined period unless intelligence is renewed.

• Establish threat intelligence-to-prioritisation pipeline , briefings triggering severity review
• Implement temporary severity elevation for active threat actor TTP techniques
• Review all severity assignments quarterly , independent of intelligence triggers
• Ask for severity update process , how intelligence changes alert prioritisation
• Test contextual prioritisation , when was a severity last updated based on threat intelligence

If you are a small team

Ask your highest-risk vendor one question: in the last twelve months, has any alert severity assignment been updated based on threat intelligence , specifically has the priority of any SIEM rule been elevated because a threat intelligence source identified that technique as the primary TTP of a threat actor actively targeting your sector? If the answer is no, the prioritisation system is static , and the SOC's response speed to active threat actor techniques is calibrated for a threat context that may no longer be current.

• Ask whether any severity assignments have been updated based on threat intelligence in last twelve months
• Ask about threat intelligence-to-prioritisation pipeline
• Ask whether active threat actor TTP intelligence triggers priority elevation
• Ask for last severity review date across all rules

What to require

Ask directly:

"When your sector ISAC publishes intelligence identifying a specific TTP as the primary technique of an active threat actor targeting your sector , does that intelligence trigger a review and potential elevation of the alert severity for the SIEM rule that covers that technique?"

Expect as evidence

• Threat intelligence to prioritisation pipeline confirmation
• Recent severity update triggered by threat intelligence
• Contextual prioritisation capability
• Severity review cadence

A vendor who confirms defined alert SLAs should be asked whether the severity assignments routing alerts into those SLAs are updated based on current threat intelligence. The SLAs measure compliance. The severity assignments determine whether compliance is calibrated to the current threat.

How to evidence it

• Threat intelligence to prioritisation pipeline records
• Severity update history triggered by intelligence
• Contextual prioritisation capability documentation
• Quarterly severity review records

Key Takeaway

Medium alert. Four-hour review. Primary TTP of active threat actor. Attacker established persistence during the four hours. The SLA was met. The prioritisation was stale. Static severity assignments calibrated two years ago for a different threat landscape produced four-hour response to a thirty-minute risk. The ISAC briefing was read. The severity assignment was not updated. The intelligence-to-prioritisation pipeline that would have connected the briefing to the severity update did not exist. Dynamic prioritisation , threat intelligence triggering severity review , closes the gap between the current threat and the static assignment that was accurate for yesterday's.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations