You’re Sure Your SOC Can Detect Coordinated Threats. Can You Prove It?

Security operations centers might be just a little overconfident in their program’s ability to detect and respond to threats. A new report released today from HiveWatch found that 93 percent of physical security leaders said they are confident they could detect a coordinated threat amid the current alarm volume, but only 19 percent always meet their own service level agreements (SLAs) for response time, alarm processing, and time to resolution—a notable gap between confidence and results.

The benchmarking study, The State of Physical Security Operations in 2026, surveyed 300 security professionals responsible for physical security operations at U.S. organizations with at least 500 employees and $5 million in revenue, all of whom operate or have concrete plans to build a security operations center (SOC). The study found a significant gap in how secure organizations feel and how secure they actually are.

Organizations with SOCs were more confident in their ability to detect and respond to a coordinated threat, with 98 percent of survey respondents with a centralized or consolidated SOC feeling particularly confident, compared to 65 percent among those planning to build a SOC.

But among all respondents, only 19 percent always hit their SLAs. Even among security leaders who rated their SOC programs at the top two maturity levels (optimized or leading), consistently hitting those SLAs is not the norm.

It’s not all terrible—40 percent said they hit their SLAs often, and occasional misses are explicable—due to staffing gaps, surge events, or system outages. But 13 percent only hit their SLAs intermittently, with most incidents falling outside of target metrics or not measured.

The gap between confidence and consistent performance is a risk, says Ryan Schonfeld, CEO of HiveWatch.

“The gap between the two is where real incidents become real failures,” he tells Security Management. “Organizations that feel secure stop asking hard questions. They don’t pressure-test their playbooks, they don’t run tabletops or assess changing risk patterns, and they don’t audit their SLA attainment because they assume things are working. The overconfidence doesn’t just mask the problem for these programs, it can actively prevent security leaders from finding the problems and addressing them effectively.”

Those security maturity levels were especially telling. HiveWatch asked respondents to rate the overall maturity of their physical security program—including SOCs, if they have them—using a five-level framework:

• Level 1—Reactive: Largely incident-driven; limited process documentation; staffing and tools are inconsistent
• Level 2—Developing: Core processes exist but are not consistently followed; some technology in place; metrics are informal
• Level 3—Defined: Documented processes, defined roles, and established KPIs; technology is integrated but not optimized
• Level 4—Optimized: Proactive, data-driven operations; strong executive visibility; technology and staffing are aligned to risk
• Level 5—Leading: Continuous improvement culture; artificial intelligence (AI) and automation in use; program is a recognized strategic asset
  
  

The majority of respondents (56 percent) rated their program at level 2 or 3, and 35 percent said they were at level 4 or 5.

“The distribution of responses tells me something the industry doesn't like to hear: We’ve gotten pretty good at building SOCs and pretty bad at running them,” Schonfeld says.

“Looking at the 56 percent number, which is the number of programs that sit at level 2 or 3, there are processes that exist and technology that’s deployed, but they’re not working as they should. That tells us the problem isn’t with infrastructure (like so many assume), but with execution,” he adds. “The proof is in the numbers we see in the study: Even organizations that rated themselves at the top two maturity levels still aren’t consistently hitting their own SLAs, which is a big problem from an operational perspective. Right now, the biggest gains available to most programs is operationalizing the investments they’ve made to maximize efficiency.”

One first step most organizations can take is to reevaluate measurements. The report found that many programs don’t have mechanisms in place to accurately track SLAs, which can mask performance problems. Similarly, those SLA metrics alone don’t tell the full story. A typical SLA—time to resolution—tracks how quickly an operator identifies and acts on a high-priority event. But that measures speed rather than quality, Schonfeld says. Similarly, response time and alarm processing rates tell you how busy your operators are, but not how well they are reducing risk.

“The metrics that actually demonstrate value are detection accuracy, false alarm rate reduction, and threat-to-response conversion,” he says. “Until the industry standardizes around outcomes rather than throughput, we're measuring how fast we’re spinning the wheel, not where it’s taking us.”

Consider alarm volume. Survey respondents reported processing an average of 342 alarms each day, and roughly one in three is false. For organizations with 1,000 or more employees, the volume climbs to more than 420 daily alarms, plus a false alarm rate nearing 44 percent, the report said.

“A SOC processing 342 alarms a day at impressive speeds, while 32 percent (or more) of them are false, isn’t demonstrating value. It’s demonstrating activity,” Schonfeld says. “The metrics that would actually prove a SOC’s worth are the ones almost nobody is tracking: detection accuracy, false alarm rate reduction year over year, and whether the right person had the right information when a real incident occurred… or responded in the right manner.”

Larger scale organizations also have more connected devices to monitor. As organizations double in size, the number of devices they monitor quadruples. Operators with more sites to cover also use more applications, adding complexity to SOC workloads. But the report noted that larger organizations’ security teams tend to be more specialized, so a single SOC operator might not use all applications, instead focusing on just threat intelligence and risk analysis or day-to-day alarm operations. Operators at smaller organizations may have to do it all, and their tools are not keeping pace.

Centralized SOCs are a winning model for delivering results across even large footprints. More than a quarter of centralized SOCs always meet their SLAs compared to just 13 percent for regional SOCs. The gap widens further when looking at SOCs that “always or often” meet those SLAs: 74 percent for centralized operations versus 48 percent for regional ones.

“What might be behind it: regional models distribute accountability without distributing authority,” Schonfeld says. “Every region develops its own interpretation of the SLA, its own escalation habits, its own tolerance for what ‘close enough’ looks like. Nobody owns the number across the whole program, so nobody’s truly on the hook for it. Centralized operations typically collapse that ambiguity, with a single team, standards, and set of consequences when something gets missed, as well as a more cost-effective model of operations.”