Sorting the signal from the noise when every alert demands attention
An Australian SOC analyst at 2am AEST in Sydney logs into the queue and sees 4,200 open alerts. Eight different sensors are firing - EDR, network detection, identity protection, cloud workload scanning, email gateway, firewall, vulnerability scanner, and a third-party threat intel feed. By the time she has triaged the first 200, another 600 have arrived. The volume is not because her environment is uniquely under siege. It is the universal condition of modern enterprise defence: every vendor promises comprehensive coverage, and the result is comprehensive fatigue.
Getting the order wrong has real consequences in this country. A genuine intrusion can sit for hours behind a mountain of noisy phishing clicks while analysts chase the loudest sensor. Under the Notifiable Data Breaches scheme administered by the Office of the Australian Information Commissioner, organisations covered by the Privacy Act 1988 have 72 hours to assess and notify eligible breaches. An alert buried at position 1,400 of a queue is, for practical purposes, an alert that does not exist. Prioritisation is therefore not a productivity feature; it is a regulatory and operational necessity.
Why every sensor feels urgent at once
A decade ago, a typical enterprise ran one SIEM, one antivirus product, and a perimeter firewall. Today the same enterprise layers EDR on every endpoint, cloud workload protection in AWS and Azure, identity threat detection on Entra ID, SaaS security posture management, email security gateways, network detection and response sensors, vulnerability scanners feeding daily, and often two or three threat intelligence platforms. Each tool is sold as must-have, and each arrives with its own default alert configuration tuned by the vendor rather than by the buyer.
Australia magnifies the problem in two ways. The local cyber security talent pool is genuinely constrained: a recent industry survey reported a national shortfall of roughly 30,000 professionals, which forces many organisations to lean harder on automation and offshore analysts. At the same time, the geographic distance from most vendor engineering teams means tuning help often arrives the next business day. By then the queue has grown again. A clear prioritisation framework is the only way to keep the queue honest when headcount and reach-back support are both limited.
Build a scoring model that reflects your actual risk
Raw vendor severity is the wrong place to start. A critical alert from a network sensor on a workstation used by a marketing intern is not the same event as a high alert on the domain controller of an ASX-listed financial services firm subject to APRA CPS 234. Prioritisation has to multiply severity by asset criticality, by data sensitivity, and by the credibility of the underlying threat.
Three ingredients tend to produce reliable scores. First, an asset inventory that records business function, data class, internet exposure, and recovery difficulty. Second, threat intelligence that maps current adversary behaviour to the technologies you actually run. Third, an exploit prediction score such as EPSS so that a vulnerability being actively weaponised ranks above one that is merely theoretical. Below is a quick comparison of the common scoring approaches Australian teams mix and match.
| Approach | Strength | Weakness | Best used for |
|---|---|---|---|
| Vendor CVSS alone | Familiar, fast to apply | Ignores business context | Initial triage only |
| CVSS plus EPSS | Adds real-world exploit likelihood | Still asset-agnostic | Vulnerability prioritisation |
| Internal risk-based scoring | Reflects your data and crown jewels | Requires maintained asset data | Alert prioritisation |
| MITRE ATT&CK-mapped scoring | Links alerts to adversary behaviour | Heavy to implement | Threat hunting and IR |
Once a model exists, the queue stops being a wall of identical red tiles and becomes a ranked list with explanation. Analysts in a Melbourne SOC told me last year that the difference was not really about closing more alerts - it was about closing the right ones first and being able to defend that decision to a non-technical executive.
Use the business context you already have
Asset criticality is not a static field buried in a CMDB. In Australian organisations it shifts with the calendar. A retailer in Sydney cares most about point-of-sale and warehouse systems in the lead-up to Boxing Day. A university in Brisbane cares most about enrolment systems in late January and result publication in mid-year. A mining company in Perth cares most about OT segmentation during planned maintenance windows. A scoring model that ignores operational tempo will mis-rank alerts at exactly the worst moments.
Regulatory context matters too. APRA-regulated entities must demonstrate they can identify and respond to incidents affecting information assets that support critical operations. Entities handling health records have parallel obligations under the My Health Records Act. Embedding these obligations into the prioritisation rule itself, so that an alert touching a regulated data set automatically escalates, turns compliance from a separate audit exercise into a live operational driver. The same logic applies to clients in defence supply chains and to organisations preparing for SOCI Act critical infrastructure requirements.
Map alerts to the controls you can actually operate
Detection without response is noise. A critical alert that triggers a workflow nobody owns, or that requires a skill the team does not have on shift, generates the worst possible outcome: a high-confidence event with a low-confidence response. Mature teams in this country maintain a deliberate map between alert categories and named response capabilities, including managed detection and response partners who can take containment actions on the customer's behalf outside business hours.
This is where a platform approach helps. CARM Security integrates remediation tooling from multiple vendors so that when a confirmed intrusion appears, the response path is already wired in. The prioritisation decision is only valuable if it feeds a control that can actually do something - isolate a host, revoke a token, block a domain, snapshot a workload. If your top-priority alert leads to a Slack message and a wait, you have not prioritised, you have just redecorated the backlog.
Disciplined rollout thinking helps here too. The same logic that appears in a practical adoption checklist for rolling out new technology in schools applies to rolling out a new triage model: define success, train people, measure before and after, and iterate. Skipping any of those steps produces a beautiful scoring model that nobody uses.
Automate the bottom of the pile before humans see it
Roughly 70 to 80 per cent of alerts in a typical enterprise queue are closeable by deterministic logic. Known-bad hashes, repeat offenders, signature-matched phishing, vulnerability findings on decommissioned assets - none of these needs a human investigator. Auto-closure, auto-enrichment, and auto-containment for low-risk, high-confidence events frees analysts to spend their finite attention on the genuinely ambiguous cases that appear at the top of the prioritised queue.
Australian organisations with thin in-house teams often achieve this by partnering with a managed security service provider that runs around the clock from local or near-shore SOCs. The economic argument is straightforward: a single 24/7 local shift rotation for an in-house team in Sydney or Melbourne costs several times the annual fee of a co-managed SOC. The operational argument is that the partner brings pre-built playbooks, so the auto-handled alerts are not just dropped, they are handled consistently. The trick is making sure the partner's analysts see the same enriched, context-tagged alerts your in-house team sees, so handoffs do not lose context.
Re-tune quarterly, not after the next breach
Prioritisation models decay. New business applications ship, old servers are decommissioned, threat actors shift technique, and detection rules accumulate false positives. A model that scored accurately six months ago will drift, and the drift is rarely visible from inside the SOC because the analysts are too busy working the queue to step back and audit it.
Build the re-tune into the calendar. Once a quarter, sample a hundred closed alerts at random and check whether they were closed correctly, scored correctly, and routed to the right team. Once a quarter, review the top twenty false-positive generators and ask whether a detection rule needs adjusting or whether an asset tag is wrong. Once a quarter, run a purple-team exercise that deliberately generates the kind of alert you most fear missing, and verify that the model actually surfaces it. The cost is small; the cost of discovering the model is broken during a real incident is not.
Insurance arrangements also reward this discipline. Underwriters writing cybercrime insurance for Australian businesses increasingly ask for evidence of detection coverage, response readiness, and quarterly tuning reviews. A documented prioritisation model that has been recently re-tested is the kind of evidence that survives a claims call. A model that exists only in a slide deck does not.
What to take from all of this. Every sensor firing at once is not a temporary crisis, it is the steady state. Build a scoring model that mixes severity, asset value, and adversary behaviour. Weight it with the business and regulatory realities of operating in Australia, including the Notifiable Data Breaches clock and any sector-specific obligations. Tie every high-priority alert to a control that can actually act. Automate the bottom of the pile. And re-tune on a schedule, not after the lesson is delivered by an attacker. The goal is not a quiet queue. The goal is a queue whose top tells the truth about where the next breach is most likely to start.