Security Signal to Noise: The SOC Metric That Matters

Security signal to noise is not a vanity percentage. It is a test of whether a SOC turns detection work into useful action without burying attacks.

Most teams measure what the ticket system can count: alerts opened, tickets closed, and average handling time. Those numbers are easy to produce and easy to game. Close weak alerts faster and the dashboard improves while the detection program stays weak.

A useful scorecard asks two harder questions. How often did reviewed work change a security decision? How many analyst minutes did each useful action cost? Then it adds a nonnegotiable constraint: did tested detection coverage survive the changes that improved the ratio?

What does security signal to noise mean in a SOC?

Security signal to noise compares work that produces a defensible security action with work that consumes attention but changes nothing. Signal is not every true alert. A valid observation about approved software may be factually correct and still belong in a report, not an investigation queue.

Count an item as useful signal when it confirms an incident, changes containment, expands scope, corrects a detection, drives a control change, or supports a documented risk decision. Treat a false alert, duplicate, known benign match, low value observation, and unresolved case as separate outcomes. Combining them into “closed” destroys the feedback the rule owner needs.

This is narrower than the complete problem of alert fatigue in cybersecurity. Alert fatigue includes capacity, interruptions, ownership, and trust. The signal ratio gives that program one local instrument for judging which rules earn attention and which ones buy the same answer repeatedly.

Why do common SOC metrics hide bad signal?

Ticket count rewards motion. Closure speed rewards short investigations. Rule count rewards alert creation. Log volume rewards collection even when parsers are broken or no detection uses the data. None proves that the SOC found an attack or changed risk.

The UK National Cyber Security Centre made this point bluntly in its April 27, 2026 guidance on harmful SOC metrics. The author reported observing ticket focused SOCs where as many as 99 percent of tickets were marked as false positives. That is an observation from specific environments, not an industry rate. Its value is the incentive lesson: measure people on closures and they will find reasons to close.

That guidance recommends testing whether the SOC detects and responds to attacks in time, using red or purple team exercises when real incidents are too rare for a useful average. That April publication is a recent development many older signal articles miss. It moves the discussion from a tidy ratio to the behavior a metric creates inside the team.

What does current research say about SOC noise?

Splunk's State of Security 2025 research found that 59 percent of respondents said they had too many alerts, 55 percent dealt with too many false positives, and 57 percent lost investigation time because of gaps in data management. Forty six percent said they spent more time maintaining tools than defending the organization. A queue problem and a data problem are often the same problem viewed from different seats.

The June 11, 2026 SANS SOC Survey release adds a current view. It drew on 444 security operations practitioners and 69 CISOs or senior executives. Twenty four percent of leaders named lack of visibility across the enterprise as the largest barrier to SOC effectiveness. The release also found a 27 percentage point gap between leaders who said management paid close attention to hiring and retention and practitioners who agreed.

Those numbers do not create a universal target. They show why local denominators matter. A SOC cannot borrow a healthy ratio from a survey. It must label its own decisions, include unfinished work, and show the time consumed by each rule.

Which alert outcomes should the scorecard separate?

Start with a verdict dictionary that analysts and detection owners share. Keep it small enough to use and sharp enough to drive a different fix.

• Useful action: the review changed containment, scope, a control, a rule, or an accepted risk decision.
• Benign true activity: the rule matched what it claimed, but the activity was approved and needs no security action.
• False alert: the rule claim was wrong because logic, data, identity, or context failed.
• Duplicate: another alert had already created the same decision for the same case.
• Low value observation: the event belongs in searchable evidence or reporting, not an analyst queue.
• Unresolved: the team lacked time, data, authority, or a clear owner. Never erase this outcome from the denominator.

“Benign” alone is not enough. It hides whether a detector was wrong, whether the behavior was approved, or whether the analyst ran out of evidence. Each outcome should point to an owner. Detection logic goes to the rule owner. Missing identity data goes to the pipeline owner. Repeated decisions go to correlation engineering. Work with no action goes to queue governance.

How should you calculate security signal to noise?

Use action yield as the first ratio: useful actions divided by reviewed alerts. Use action cost beside it: analyst minutes divided by useful actions. Neither is a standard mandated formula. They are an operating model that forces teams to show value and cost without pretending every true event is equally useful.

Suppose a rule produces 2,400 alerts a week. Analysts spend nine active minutes on each one, and 42 reviews produce a useful action. The weekly cost is 2,400 times nine, or 21,600 minutes. That is 360 hours. Action yield is 42 divided by 2,400, or 1.75 percent. Each useful action costs about 514 analyst minutes.

After a tested change, the rule produces 600 alerts and still yields 42 useful actions. Review cost falls to 90 hours. The team recovers 270 hours in this example, action yield rises to 7 percent, and cost per action falls to about 129 minutes. The result counts only if attack replay still passes, telemetry is healthy, and sampling shows the filter did not hide relevant cases.

Do not average the entire SOC first. A strong identity rule can hide a useless malware rule in one blended number. Calculate by rule, data source, business service, alert lane, and week. Show both the distribution and the total. The noisiest rule often owns most of the recoverable time.

How do you stop a better ratio from creating blind spots?

Pair every ratio with coverage evidence. Maintain a replay set of confirmed attacks, approved administration, edge cases, and past misses. Test the rule before and after any threshold, exception, grouping, or data change. Track required data sources and parser health separately.

Our guide to alert tuning without losing coverage gives the change process. The central rule is simple: a lower queue count is not a win until the intended behavior still triggers. If the team cannot replay the behavior, it cannot prove the change was safe.

Monitor sampled suppressed events as well. A deduplication key may merge activity that only looks similar. An allowlist may stay after the approved project ends. A data source may silently change a field. Ratios drift because the environment changes, not because the arithmetic failed.

What should leaders see on the signal scorecard?

A weekly operator view should show action yield, cost per useful action, unresolved work, duplicate share, false alert share, queue age, test pass rate, data health, and the five rules consuming the most time. Add the owner and next change date for each expensive rule.

The board does not need a leaderboard of alert closures. Show whether tested attacks were detected in time, whether investigation demand fit capacity, which coverage gaps remain, and what decision leadership must make. The NCSC guidance is right to warn that internal health measures can become harmful performance targets when exported without context.

Be precise about denominators. Google Security Operations, for example, defines the false positive rate in its security sensor reporting documentation as the percentage of nonmalicious cases among closed cases. Closed cases exclude unresolved work. If leadership reads that number as a rate across all admitted alerts, the report overstates certainty.

How do you improve the ratio without chasing the number?

1. Label two normal weeks. Record verdict, useful action, active minutes, rule, data source, and owner.
2. Rank rules by wasted minutes. Raw count is secondary because grouped alerts may cost little.
3. Name the failure layer. Separate bad logic, missing context, duplicates, low value routing, and capacity shortages.
4. Change one control. Test a query, threshold, exception, grouping key, or route without mixing several edits.
5. Replay coverage. Run known attack and benign cases, then sample live suppressed events.
6. Publish the owner and review date. Improvement without ownership decays into the next noisy baseline.

Artemes AI uses deep endpoint context with AI driven analysis to help separate an apparent finding from the system state that makes it real. That can reduce evidence gathering. The scorecard still needs human owned labels, clear error costs, and tested coverage. Fast analysis does not excuse a vague numerator.

Use alert prioritization after you improve signal creation. Priority decides which valid case gets the next investigation slot. Signal measurement decides whether a rule should create that work at all. Mixing the two lets a bad detector survive because its output sits low in the queue.

Frequently asked questions

What is a good security signal to noise ratio?

There is no credible universal target. Set baselines by rule, measure useful action and analyst cost, then improve them while attack replay and data health remain strong. Rare, severe behavior may justify a lower yield.

Is a true positive always useful signal?

No. A rule can correctly identify activity that requires no investigation. Keep the event as evidence, but route it outside the active queue unless it contributes to a larger behavior chain.

Should unresolved alerts count as noise?

Keep them as their own category and include them in the admitted work denominator. Calling them noise assumes a verdict the team did not reach. A high unresolved share is usually a capacity or evidence problem.

How often should the ratio be reviewed?

Review high cost rules weekly and the full portfolio monthly. Trigger review after a missed incident, data source change, major application release, new exception, or sharp shift in volume.

Executive takeaway

Stop reporting closure count as proof of security. Label two weeks of alerts, calculate useful actions and analyst minutes by rule, and put the five most expensive rules under an owner. Change one failure layer at a time. Keep attack replay, data health, and sampled suppressions beside the ratio. If the number improves but coverage cannot be proven, the SOC did not find better signal. It found a quieter dashboard.