SOC · 7 MIN READ · JAKE GODGART · MAR 19, 2025 · TAGS: Guidance / leadership & management / Resource
How to use data to build a business case for more SOC resources and increased budget using analyst workload metrics and efficiency KPIs
TL;DR
- Quantifying SOC staffing needs with the right metrics is critical for leadership buy-in on expanding your budget
- Combining the right quantitative metrics with qualitative knowledge on strategy and goals is key for telling the right story and defining need in the right places
- If you need help with these calculations, check out our new free self-serve SOC Efficiency Metrics & KPIs template
We all get it. Running a security operations center (SOC) is like being a firefighter in a world that’s increasingly flammable. The alerts are constant, the threats are evolving, and the pressure to keep everything secure is relentless.
One of the biggest headaches? Staffing.
It’s a constant barrage of questions you ask yourself: Are we too lean? Are we stretched too thin? Are we okay if someone leaves? How long will it take to backfill?
Overstaffing leads to unnecessary costs, while understaffing can result in missed threats, analyst burnout, and decreased security posture. Getting the headcount right feels less like science and more like…well, guessing.
But it doesn’t have to be guesswork. We’re in security, and we deal in data. Buried within our SOC metrics dashboards is the very information we need to make smart, defensible decisions about staffing levels.
More importantly, it’s the evidence we need to walk into the C-suite and make a business case for the resources we need, not just a technical plea.
Measure the right things
To truly understand your security posture, optimize your operations, and—let’s be honest—justify that crucial budget ask, you need the right things. Because data without direction is just noise.
So, what are those “right things,” especially when we’re talking about making the case for more headcount?
One key aspect is to understand your current analyst workload. When it comes to metrics, we’ll start with how SOC Capacity Hours, Target Utilization Rate, and Analyst Gross Utilization Rate can paint a clear picture for both ourselves and the business leaders.
If you need a place to start, check out the free self-service SOC Metrics & Efficiency KPIs Dashboard template we built using some of the best practices we use internally at Expel to ensure our SOC is properly staffed.
SOC Capacity
SOC Capacity Hours is straightforward—it’s the total available hours your team has to work each month. This is influenced by factors like team size, working hours, and time off. Think of it as the fuel tank of your SOC engine.
Calculation |
---|
Analyst count x labor hours each month |
Target Utilization Rate
Capacity measures if all of our analysts worked 100% of their time. But we don’t expect that, nor do we want that. Overworked analysts miss things. Setting a target utilization rate helps us monitor workload levels and prevent analyst burnout. This is like the RMP max point we want to set for our engine before we’re over-revving our analysts.
Choosing a target
The specific target for a SOC may vary based on operational experience, team size, threat exposure, and performance analysis. Industry benchmarks often suggest a target utilization rate in the range of 60–75% to balance productivity and analyst stress levels. This leaves room for essential non-alert work like training, process improvement, and threat research.
That said, choosing your target doesn’t matter as much as sticking to it and evaluating if your SOC can sustain that target utilization level. That’s why it’s a critical input to measuring your Analyst Gross Utilization Rate, which is the real-time gauge of how hard that SOC capacity engine is working.
Analyst Gross Utilization Rate
The analyst gross utilization rate measures what percentage of your analysts’ time is actually spent on what we hired them to do: triaging alerts, investigating incidents, and responding to threats. It’s a snapshot of how efficiently analyst time is used, similar to measuring how efficient that SOC engine is at using the SOC Capacity (fuel).
A higher utilization rate suggests analysts are spending more time on productive security work, while a lower rate might indicate inefficiencies, understaffing, or time spent on non-alert-related tasks.
It’s crucial to note that this is a gross utilization rate, meaning it doesn’t account for non-alert-related—but necessary—SOC analyst activities like training, tool maintenance, threat research, or process improvement.
Calculation |
---|
Total monthly hours spent by all analysts / total SOC capacity at your target utilization rate |
For instance, let’s say you have a team of ten analysts. With a typical 40 hour work week, your total SOC capacity is 400 hours per week. Add in a 70% target utilization rate, and your overall team capacity target is really 280 hours per week. If the team collectively spends about 240 hours on detection and response work each week, it means your team’s gross utilization rate is around 86%.
Here’s the critical point: a high utilization rate isn’t always a good thing. Yes, we want efficiency and not to overstaff the SOC relative to the work. But pushing analysts to 80%, 90%+ utilization? That’s not efficiency, that’s setting them up for burnout and failure.
How to understand your headcount needs
So, what do you do when your dashboard shows your Analyst Gross Utilization Rate consistently hovering above the 70% target?
That’s your data-backed moment of truth. You can now walk into the next budget meeting armed with facts, not just feelings. That said, asking to double or triple your team probably isn’t going to end well. It’s better to identify the exact number of analysts you need to stay below 70% utilization based on real SOC data.
To calculate that, you need to analyze the average time it takes analysts to handle a security alert, from initial triage to final resolution. This average handling time should be based on historical data and regularly reviewed for accuracy as processes and alert types evolve.
Next, you’ll need to understand the total security alert volume expected within a given period (weekly or monthly, for example). This can be based on historical trends, projected growth in monitored assets, or changes in the threat landscape.
With these two data points, you can estimate the number of analysts required to maintain a 70% utilization rate target given your current and projected alert volume and handling times.
Calculation |
---|
(Total monthly hours spent by all analysts / monthly capacity for a single analyst) – current number of analysts |
For example, if a SOC anticipates 500 security alerts per week and the average handling time per alert (triage, investigation, response, etc.) is 45 minutes, the total analyst hours needed to handle all alerts would be 375 hours (500 alertsx45 minutes/alert).
To achieve a 70% utilization rate, we then divide the total analyst hours needed by the target utilization percentage (375 hours/0.70 = approximately 536 total analyst hours needed).
Finally, to determine the headcount, divide the total analyst hours needed by the standard working hours per analyst per week (40 hours). In this example, 536 hours/40 hours per analyst = approximately 13.4 analysts.
Let’s say that the current operation has ten analysts. To achieve under a 70% utilization rate, they’d need to hire an additional four analysts!
Caution: Data supports the story, but it isn’t the story
It’s important to remember that these metrics aren’t standalone indicators, but rather data points to inform your story and decision-making. Factors such as analyst skill levels, alert complexities, automation capabilities, and the overall SOC strategy must also be considered.
For example, if the SOC is investing heavily in automation, the average alert handling time might decrease, reducing the headcount needed, even at a consistent alert volume.
Conversely, if the SOC is tasked with handling more complex investigations or expanding its monitoring scope, the average handling time and alert volume might increase, necessitating additional headcount even if the current utilization rate seems acceptable.
Therefore, a holistic approach that combines these metrics with qualitative assessments of SOC operations and strategic objectives is crucial for accurate and effective headcount planning. Regularly reviewing and refining these metrics monthly ensures the SOC remains appropriately staffed and equipped to effectively defend against evolving cyber threats.
Building a strong business case
Now that you have the data, it’s time to share it with your leadership team. The power here is in translation. We’ll lose the point of the discussion if we focus on tech metrics when talking to business leaders. So instead, we’re using analyst workload data to articulate business risk, operational efficiency, and the tangible need for more resources.
Start using your data to show the C-suite exactly what’s needed to keep the organization secure and your analysts effective and engaged. Data is your best advocate; start using it to build a stronger, more resilient SOC.
To secure additional resources and budget, you’ll need to build a strong business case. Here are some tips:
- Quantify the impact: Use metrics to demonstrate the financial impact of security incidents and the potential cost savings of investing in additional resources.
- Highlight the risks: Paint a picture of the potential consequences of underinvestment in security, such as data breaches, system/business downtime, and reputational damage.
- Demonstrate the value: Show how additional resources will improve security posture, reduce risk, and drive business growth.
- Align with business objectives: Connect your security initiatives to broader business goals.
- Tell a story: Use storytelling techniques to engage your audience and make your presentation more memorable.
Here’s an example of the way you may be able to frame this for leadership:
“Our current Analyst Gross Utilization Rate is 86%, exceeding our target of 70%. This high workload isn’t sustainable and introduces significant operational risk. Over-utilized analysts are more likely to make mistakes, experience slower response times, and suffer burnout. This directly impacts our ability to effectively safeguard the company and increases our exposure to potential security incidents.
Based on our current alert volume and our commitment to maintaining a healthy utilization rate for our analysts, our data indicates we require four additional analysts or hire a third-party vendor to augment our team.
This isn’t about asking for more bodies; it’s about proactively ensuring we have the necessary capacity to manage the growing threat landscape and uphold a robust security posture around the clock. Investing in these additional positions is a direct investment in mitigating risk and ensuring business continuity.”
Emphasis on the impact of inadequately staffed SOC teams can be made if you’re also able to show how the Gross Utilization Rate increased over time or how MTTX metrics are declining due to an overworked team.
Data is the key to translate your ask for business leaders
By focusing on analyst workload metrics—particularly Analyst Gross Utilization Rate and Additional Analyst Headcounts needed—and presenting them with a business-centric lens, you move from making ad hoc requests to presenting a clear, data-supported case for the resources your SOC truly requires.
Linking these metrics into a narrative about why this decline is happening and how you’re concerned about SOC analyst retention—and thus an increased business risk—is a good way to ground the conversation. By leveraging data-driven insights and effective communication, you can craft a compelling case for the resources your SOC needs to protect your organization.
Alternatively, you may want to look at augmenting your SOC’s detection and response capabilities by partnering with a third-party MDR provider (like Expel) to offload that SOC work at a fraction of the cost of building a team.
Whatever you choose, you should be measuring your SOC’s workload. Your analysts will thank you for it.