Security operations
How to Know If Your GSOC Is Performing: Measure Decisions, Not Alerts
Without the right security operations maturity model in place, a center could be failing the people it’s supposed to protect, even if it closes hundreds of cases a month.
According to ASIS International's 2026 survey of security leaders, 93% felt confident their team could detect a coordinated threat, but only 19% were consistently meeting their own service level targets.
Most security, risk and safety teams are still evaluated on activity like alerts received, cases closed and how busy a shift was. But this data doesn't show how quickly a team understood what was happening and acted on it.
A more useful model measures how quickly a global security operations center (GSOC) moves through six stages: first awareness, verified understanding, exposure, assessment, decision and coordinated action.
This article discusses that model, using samdesk's own published numbers as a worked example.
Key takeaways:
|
Why Alert Volume and Cases Closed Don't Prove a GSOC Is Working
Alert volume and case closure rates measure how busy a security operations center is, not whether it's providing the right level of protection.
According to ASIS Foundation research into how security leaders report to their executives, the five most common categories are security incidents, criminal incidents and investigations, cost against budget, training completion and guarding performance. These are all activity counts, not measures of how quickly a threat was understood or acted on.
The same research found only 39% of security programs benchmarked their data against anything outside their own four walls, leading the ASIS Foundation to describe most existing security metrics as "often vague" and not "meaningful or risk-based”.
A companion study of security management practices found the problem often starts even earlier, with 32% of security programs using no performance metrics at all.
Measuring volume alone isn’t helpful. ASIS International's 2026 survey found the average security operations center handles 342 alarms a day, roughly a third of them false. And at organizations with 1,000 or more employees, that figure rises to at least 420 alarms a day, with a false alarm rate near 44%.
A team could process all those alarms and still not be able to prove their protective measures were adequate, because volume doesn't show how quickly the team progressed from a first signal to a decision it could defend.
As we cover in our article on alert fatigue, more alerts usually mean that more unverified signals reached an operator's queue before anyone determined whether they were important.
What a Real Security Operations Maturity Model Measures
A security operations maturity model measures how quickly a team moves a signal through a series of stages rather than how many signals it handles.
Rather than looking at how many signals a team handles, a security operations maturity model measures how quickly a team moves a signal through six stages: first awareness, verified understanding, exposure, assessment, decision and coordinated action.
These stages also map onto AWARE (the Anticipate, Watch, Analyze, Resolve, Enable capability model some security programs already report against), so a team using that framework can plot the same six stages onto it without re-measuring anything.
Stage | What good looks like | What to measure | AWARE phase |
|---|---|---|---|
First awareness | The signal reaches the team before it becomes public news | Time from event onset to first internal notice | Watch |
Verified understanding | The team knows what's confirmed versus unconfirmed | Time to verification | Watch |
Exposure | The team knows exactly who or what is affected | Time to map affected people, sites or routes | Analyze |
Assessment | Severity is judged against the organization's own risk tolerance | Time to a documented risk call | Analyze |
Decision | A proportionate action is chosen while options are still open | Time from verified understanding to decision | Resolve |
Coordinated action | The decision reaches the right people and is confirmed complete | Time to full notification and confirmed response | Resolve |
Two AWARE phases sit outside this table, because they aren't single, timed steps inside one incident's lifecycle. Anticipate is the planning work a team carries out before any signal arrives (deciding where to audit next, comparing how locations perform across a region and preparing for an executive offsite). Enable represents ongoing measurement and feedback, wrapping around every stage rather than sitting inside a single one.
The broader shift away from activity counts toward outcome-oriented security metrics is already visible across the industry. Ambient.ai grouping physical security KPIs into four similar categories: detection quality, response speed, operator efficiency and program accountability. This represents the same shift away from raw counts and toward stage-based measurement.
Ontic's research into physical security analytics describes it in the same way: a maturity curve that runs from ad hoc, activity-based reporting toward structured, insight-driven programs, not a single before-and-after snapshot.
A Worked Example: Reading Samdesk's Numbers Against the Model
The clearest way to see this model in practice is against real numbers. Samdesk publishes its own performance figures and analyzes more than 10 billion signals a day across 1,000-plus real-time data streams. It also detects and verifies emerging incidents in under 60 seconds at 98.5% accuracy, with every AI-driven read continuously validated by human analysts.
Mapped against the model, those numbers cover the stages that are the hardest to speed up without losing accuracy. First awareness and verified understanding compress into the sub-60-second window, and the 98.5% accuracy figure determines how much of what's left an operator can trust without re-checking it themselves.
On the decision stage, samdesk's benchmark is a 30-to-90-minute earlier detection than the closest alternative. The value of earlier detection isn’t the timestamp itself. It is the decision time it creates. Thirty additional minutes may be the difference between rerouting a traveler, securing a facility or changing a route, and managing the consequences after exposure has already occurred.
Model stage | Samdesk's published figure | What it demonstrates |
|---|---|---|
First awareness | 10B+ daily signals, at 98.5% accuracy | Speed and precision cuts down on alert noise and accelerates understanding |
Verified understanding | AI + HITL validation on urgent & developing alerts in under 60 seconds | Increases confidence before operators act |
Exposure | Organizational people/assets/routes context | Shows what the event intersects |
Assessment | Evolving incident + contextual updates | Preserves context as conditions change |
Decision | 30–90 minutes earlier detection than the closest alternative | Creates more time while options are still open |
Coordinated action | Integrations with comms or downstream systems, escalations to stakeholders, situation reports | Helps operationalize the decision |
Where Programs Stall: From Verified Signal to Coordinated Decision
Most security operations centers stall in the middle of the model rather than at the beginning. In ASIS International's 2026 survey, 56% of security leaders rated their own program at Level 2 or 3 — developing or defined — while only 35% considered themselves Level 4 or 5, optimized or leading.
Detection alone is not the end of the bottleneck. The harder stages are exposure, assessment and coordinated action, where a verified signal still has to be turned into who it affects, how bad it is for the organization and what happens next.
Staffing challenges compound the gap. When experienced operators leave, institutional knowledge around exposure, escalation and response can leave with them, making shared context and repeatable workflows even more important. Our article on why awareness isn't enough during disruption covers the same gap from the operator's side, showing that information alone doesn't produce a decision.
Structure matters as much as tooling. The same survey found centralized security operations centers met their SLAs roughly twice as often as regional ones (74% always or often, versus 48%). Centralized operations may benefit from fewer handoffs and a more consistent operating picture, although organizational structure alone doesn’t explain the performance difference. Centralized operations may benefit from fewer handoffs and a more consistent operating picture, although organizational structure alone doesn't explain the performance difference.
Why One Evolving Incident Moves the Whole Model Faster
The stages usually stall because most tools provide a stream of separate alerts instead of one incident that keeps developing as new information arrives.
Every time a related signal creates a new alert instead of updating an existing one, someone has to re-establish context that already existed.
With samdesk, every signal that clears verification becomes part of one evolving incident rather than a new, disconnected alert. The incident carries its exposure mapping, verification status and confidence level forward through every stage, so an operator assessing severity or coordinating a response isn't starting from scratch each time.
It's the same principle behind our approach to physical asset security, which involves pairing AI-powered detection with human verification so a team spends its time on the difficult stages, instead of re-confirming what's already established.
Nutrien Ag Solutions built its own security operations around exactly this setup, consolidating around one verified, shared picture of an incident instead of parallel alert streams per team.
A Simple Scorecard for Where Your GSOC Sits
A useful maturity model doesn't need five vendor-defined levels. Three tiers are usually enough to start a conversation with leadership.
Tier | What it looks like | Signature metric |
|---|---|---|
Reactive | Operators triage alerts as they arrive and severity and exposure are judged case by case, in the moment | Time to decision is rarely tracked at all |
Developing | Verification and exposure mapping happen, but often after the fact and inconsistently across shifts | Time to verified understanding is known but time to coordinated action isn't |
Decision-ready | Signals are rapidly verified, exposure is understood in organizational context, and teams can move consistently from awareness to coordinated action while response options are still open. | Time from first awareness to coordinated action, tracked end to end |
The majority of ASIS International's respondents still describe their own program as developing, with a smaller number saying they’re further along. This matches how Ontic describes physical security analytics maturity: a curve from ad hoc reporting toward structured, insight-driven programs, not a fixed destination.
Frequently Asked Questions
What is a security operations maturity model?
A security operations maturity model measures how consistently and quickly a team moves a signal from first awareness through to a coordinated, defensible decision, rather than how many alerts or cases it processed.
It typically covers detection, verification, exposure mapping, assessment, decision-making and coordinated action as separate, measurable stages.
Is GSOC maturity measured the same way as cybersecurity SOC maturity?
No. A cybersecurity SOC measures maturity against digital assets like logins, endpoints and network traffic. A global security operations center measures maturity against physical and operational risk to people, facilities, travelers and supply chains, so its metrics track real-world verification and exposure rather than log analysis or patch timelines.
What metrics should a GSOC track instead of alert volume or cases closed?
Track time at each stage: first awareness, verified understanding, exposure mapping, decision and confirmed coordinated action. Together, these show how much of the decision window a team is actually using, which alert counts and case totals can’t reveal.
How long does it typically take to move from a reactive GSOC to a decision-ready one?
There's no fixed timeline. It depends on staffing, tooling and how much of the verification and exposure-mapping work is still manual. Programs that tend to see the fastest gains start by timing a single stage, usually verified understanding, and expand from there.
What's a reasonable SLA attainment benchmark for a GSOC to aim for?
Industry research is more useful for understanding the maturity gap than for setting an SLA. Organizations should first define SLAs around the operational outcomes that matter to them, such as time to verification, exposure assessment or coordinated response, and establish a consistent internal baseline.
A reasonable near-term goal is consistently meeting the SLA that a program has already set for itself, before comparing against any external number.
Measure the Decision, Not the Queue
If a GSOC can’t show how quickly it moves from first awareness to a coordinated decision, it’s not really able to prove it's working, no matter how many alerts it has closed this month.
The strongest case security leaders can make to their own executives is taking a real number for each stage of the journey and measuring it against the developing-to-decision-ready curve that the rest of the industry is already using.
At samdesk, we built our own platform around this idea. It’s about verifying a signal in under 60 seconds, carrying it forward as one evolving incident and creating additional decision time while teams still have options to reduce exposure, protect people and keep operations moving.
If your own team is still measuring what it processes rather than how quickly it decides how to act, book a demo to see what a decision-ready GSOC looks like against your own numbers.
