SOC SLOs and continuous tuning

Without numbers, the SOC only tells stories. With clear SLOs (triage time, containment time, precision and recall) every adjustment becomes a decision backed by evidence.

BigQueryGrafanaLooker StudioPagerDuty

What it is

A security SLO () is a numeric target for what the team promises to deliver: for example, triaging critical alerts within a few minutes or containing attacks before a given percentage of attempts get through. It turns a vague wish ("respond fast") into something measurable and debatable.

The four metrics that support the rest

MTTT (): from the alert until someone classifies it as real or false.
MTTC (): from confirmation until the attack is contained.
Precision: of the alerts or blocks the detection issued, how many were really an attack.
Recall: of the attacks that existed, how many the detection caught.

Precision and recall pull in opposite directions

Raising sensitivity increases recall and lowers precision, with more false positives; tightening the rule does the opposite. The right point depends on cost: on a bank's login a wrong block costs an annoyed customer, but an attack that gets through costs far more; on a public catalog, the balance is different. That is why the threshold is a business decision backed by data, not a solitary technical tweak.

precision per rule (BigQuery)sql

-- 'confirmed' comes from the weekly review of events the rule acted on
SELECT rule_id,
       COUNTIF(confirmed_attack) AS true_pos,
       COUNTIF(NOT confirmed_attack) AS false_pos,
       SAFE_DIVIDE(COUNTIF(confirmed_attack), COUNT(*)) AS precision
FROM sec.rule_actions_reviewed
WHERE week = DATE_TRUNC(CURRENT_DATE(), WEEK)
GROUP BY rule_id
ORDER BY precision;

Weekly tuning

A short, fixed ritual keeps quality up: review the rules with the worst precision, look at the reported false positives, check what got through (recall) in the week's incidents and decide adjustments. The stated goal is to reduce false positives without losing coverage, and the proof is the precision metric rising while recall holds.

Indicators for leadership

What the board needs is not alerts but trends: attacks contained, response time, impact avoided, rules in shadow ready to become enforcement. A few stable numbers, presented in the same format every month, build trust in the program and sustain investment.

SLOservice level objectiveThe target for an SLI over a window. It defines how reliable is reliable enough.see in glossary →Credential stuffingAttack that tests leaked username/password pairs from other services at scale. Signature: many login failures spread across many IPs, with few attempts per account.see in glossary →MTTTmean time to triageAverage time between the alert and its classification as real or false.see in glossary →MTTCmean time to containAverage time between confirming an attack and containing it.see in glossary →

connections on the map

SOC SLOs and continuous tuningmeasures precisionWAF - observation, shadow and enforcement
SOC SLOs and continuous tuningguides tuningDetection engineering

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Security metrics and reporting to leadershipgrcfrom the operational SLO to the board report
Reliability: SLOs, error budgets and incidentsdevopsSLOs and error budgets, applied to detection
Observability of the security platform itselfsecengSOC SLOs and the platform's own SLOs

Study before

Detection engineering

test what you learned

Loading questions…