SOC Deployment Costs and Steps: Realistic Ways for Mid-Market Enterprises to Build 24/7 Monitoring

"We need a SOC up and running by next term." Triggered by security questionnaires from business partners, audit findings, and news of ransomware damage at competitors, IT departments are increasingly receiving these instructions. However, the reality for those receiving the orders is harsh. Operating with a handful of people on a dual-role basis is the best they can do to keep up with daytime operations, and no one is watching alerts at night or on weekends. Even if they install a SIEM, they cannot forecast costs based on log volume, and they do not know how many monitoring staff to hire. The first barrier is that no one inside the company can answer "how much will a SOC build cost?" or "where do we start?"

The background to this is that threats no longer choose the size of the company. In the organizational ranking of the "Top 10 Information Security Threats 2026" published by IPA in January 2026, "Damage from ransomware attacks" was selected for the 11th consecutive year, ranking 1st in the 2026 edition, and "Attacks targeting supply chains and contractors" ranked 2nd (IPA, 2026). According to a report by the National Police Agency, there were 226 reported cases of ransomware damage in 2025, with mid-to-small enterprises accounting for about 60% of the damaged organizations, and over 50% of the organizations requiring a total of 10 million yen or more for recovery (National Police Agency, 2026). Mid-market companies themselves are targets, and the price of not having the capability to quickly detect and stop damage is high.

This article outlines the cost components for mid-market companies building a SOC (Security Operations Center: the organization or function responsible for security monitoring, analysis, and response), the logic for calculating the number of people needed for a 24/7/365 operation, and the six steps to build it. For pricing, we will only show the billing models and formulas verifiable in public documents, and will not present specific amounts that vary greatly depending on the environment. For the basics of SOC roles and Tier structures, please refer to our pillar article "What is a SOC? Basics and Limits of Roles, Tier Structures, and 24/7/365 Operations."

Three Models of SOC Construction: In-house, Outsourced, Hybrid, and AI Utilization

There are three main ways to build a SOC. In-house, where you source staff and tools yourself; outsourcing, where you delegate monitoring to an MSS (Managed Security Service) or MDR (Managed Detection and Response: a service that includes post-detection investigation and response support); and hybrid, where primary monitoring is outsourced, while judgment, response, and environmental knowledge maintenance remain in-house. While most mid-market companies realistically choose the hybrid model, all three share the common point that the process of "who investigates, decides, and acts after receiving an alert" remains with the company. A detailed comparison of costs, talent, quality, and speed among the three is covered in "Thorough Comparison: In-house vs. Outsourced (MSS/MDR) SOC," so this article focuses on cost structure and implementation steps.

In recent years, in addition to these three, "AI utilization"—where AI agents handle the investigation and decision-making processes—has emerged as a fourth cross-cutting element. Because it affects the cost structure regardless of the model, we will address it at the end of this article.

SOC Construction Cost Components: Labor, Tools, and Operations

SOC costs are easier to forecast when broken down into three categories: "labor costs," "tool costs," and "operational costs." While tool costs are the most visible on quotes, labor costs make up the bulk of the total cost when maintaining a 24/7/365 operation with human staff.

Labor Costs: Calculation Logic for 24/7/365 Shift Staffing

"How many SOC staff do we need?" is the most common question we receive, and the answer depends on four variables: (1) how many people watch alerts at the same time (seats), (2) how many hours are covered (weekday daytime only, or 24/7/365), (3) is it primary monitoring only, or do we keep advanced analysts (Tier 2/Tier 3) in-house for deep investigation and detection rule maintenance, and (4) is it dedicated or dual-role?

The general calculation logic for a 24/7/365, single-seat operation is as follows. A week has 168 hours, so filling one seat continuously requires 168 hours of shift work per week. If the scheduled working hours for one analyst are 40 hours per week, then 168 / 40 = 4.2 people is the required number "if they work continuously without any time off." In reality, however, there are paid leaves, sick leaves, training, and handovers, making the actual seat time less than the scheduled working hours. Setting the actual availability rate (utilization rate) at 80% yields 4.2 / 0.8 = 5.25, which rounds up to 6 people as a guideline for one seat. If you implement a mutual-verification system during night shifts so as not to leave decisions to a single person, the number of seats becomes two, doubling the headcount. On top of that, Tier 2+ investigators, engineers who maintain SIEM detection rules, and a manager who oversees the entire operation are required separately outside of this calculation.

The unit rate applied to this headcount will be underestimated if calculated by salary alone. A practical guideline is to use the "full cost" annually, which adds statutory benefits, night/shift allowances, recruitment costs, and training costs to the base salary. In particular, training and retention costs are often overlooked. According to an ISC2 study, the global cybersecurity workforce gap reached approximately 4.76 million, up 19.1% from the previous year, with 26% of respondents finding it difficult to retain talent with high-demand skills, and over half citing a lack of time to learn new skills (ISC2 Cybersecurity Workforce Study, 2024). Even if you can hire them, you must factor in training time and the cost of handovers assuming turnover.

Tool Costs: SIEM Log Volume Billing, EDR Licensing, and SOAR

The core of tool costs consists of SIEM (Security Information and Event Management: a platform that aggregates and correlates logs), EDR (Endpoint Detection and Response: products that monitor, detect, and isolate endpoint behavior), and SOAR (Security Orchestration, Automation, and Response) for automation. Among these, SIEM is the most difficult to project, as many cloud-based SIEMs charge based on the volume of ingested logs.

As an example of a billing model verifiable in public documents, we look at Microsoft Sentinel. According to the Microsoft Learn billing page, Sentinel bills for the volume of data ingested in GB, stating "pricing is based on the level at which data is ingested." Payment options include a pay-as-you-go model based on actual data volume, and commitment tiers "starting at 100 GB per day," which offer a discount compared to pay-as-you-go, though downgrading tiers is only allowed every 31 days. Ingested data is kept free of charge for the first 90 days, with retention beyond 90 days billed separately. Free data sources are also defined, such as Azure Activity Logs, Office 365 audit logs, and security alerts from Microsoft Defender products (Microsoft Learn, accessed 2026). In short, SIEM costs are basically calculated as "daily log volume (GB) x unit price x 365 days," adjusted by retention extensions and archiving to lower-cost tiers (data lakes) for long-term storage.

EDR is generally licensed based on the number of endpoints protected, making it easy to estimate once the device count is known. SOAR requires ongoing man-hours to design, implement, and maintain playbooks (automated response workflows) in addition to product licenses. Tool costs must be compared not just on license prices, but also on the human effort required to keep them running.

Operational Costs: Playbook Maintenance, Training, and Audits

The third component, operational costs, is the expense of keeping the system running. This includes building and updating playbooks that define investigation, decision, and response steps for each alert type, analyst training and exercises, and responding to audits and partner security questionnaires. The IPA "Practice Collection for Implementing Cyber Security Management Guidelines Ver3.0" lists "incident response exercises that can be practiced without strain" and "sharing and accumulating incident and threat information to avoid reliance on specific individuals in CSIRT operations" as practical examples (IPA, 2023). The effort put into continuous exercises and knowledge accumulation determines the effectiveness of the operation. In audit responses, retention periods for logs and records of "who decided what and when" are frequently requested, which should be expected to impact SIEM retention costs.

How to Estimate: Calculating by "Headcount x Unit Price" and "Log Volume x Unit Price"

Based on the above, a rough estimate of SOC construction costs can be structured as the sum of the following four formulas. Since costs vary widely depending on the environment, only the formulas and variables are shown here.

• Labor Costs = Seats x Required people per seat (5 to 6 people factoring in utilization rate for 24/7/365) x Annual labor unit price (full cost) + Labor costs for Tier 2+ analysts, engineers, and managers

• SIEM Costs = Daily log volume (GB) x GB unit price x 365 days + Retention extension + Long-term storage tier costs

• EDR Costs = Device count x Annual license fee per device

• Operational Costs = Man-hours for playbook creation and updates + Training/Exercises + Audit response + Outsourcing fees (if outsourcing)

The first variable to pin down in this formula is "log volume." The Microsoft Learn deployment guide also recommends that during the planning phase, you "determine the required data sources and data size requirements to help accurately predict deployment budgets and timelines," ensuring that both data ingestion and playbook costs are covered in the budget. Sentinel offers a trial tier that allows you to ingest the first 10 GB/day free for 31 days, along with cost estimation tools (Microsoft Learn, accessed 2026). "Running actual logs for a month to measure volume" is a much more reliable starting point than theoretical estimates.

Additionally, compare costs over a 3- to 5-year total, rather than a single year. Labor costs are fixed costs that continue as long as the operation is maintained, and log volumes tend to grow as the monitoring scope expands. Even if the first year looks cheap, there are many cases where costs spike a few years down the road due to a combination of staff turnover and increased log volume.

The 6 Steps of SOC Construction

Here, we break down the deployment process into six steps. The sequence is critical; skipping the initial steps to jump straight into tool selection leads to rework in all subsequent phases.

Step 1: Current State Assessment and Defining What to Protect

First, decide what to protect. Identify and prioritize assets where disruption or leakage directly impacts business continuity, such as core systems, customer data, connections with business partners, and privileged accounts. At the same time, inventory what logs are currently being captured, where the gaps lie, and who is currently watching existing EDR or firewall alerts. Narrowing down the monitoring scope at this stage determines all subsequent log volumes, staffing, and costs. Focusing on critical assets first and expanding in phases is more realistic than trying to cover the entire company at once.

Step 2: Preparing the Log Ingestion Infrastructure

Once the targets to protect are determined, set up the infrastructure to collect relevant logs—namely, the SIEM. The key design point is deciding which logs to route for real-time analysis and which to route for long-term storage only. The Microsoft Learn deployment guide outlines a flow where, during the "Planning and Preparation" phase led by a SOC architect, you design the workspace, prioritize data connectors, define roles and permissions, and plan costs, before moving to "Deployment" led by SOC analysts and "Fine-tuning and Review" led by SOC engineers (Microsoft Learn, accessed 2026). This is where you execute the aforementioned "ingest first to measure volume" to solidify the assumptions of your cost estimate.

Step 3: Defining Detection Rules and Use Cases

Even if logs are collected, alerts will not trigger unless you define what constitutes an "anomaly." Map your targets and anticipated attack scenarios (use cases) to detection rules, such as "privileged account login late at night" or "massive file access following an initial connection via VPN." Mapping detection rules to MITRE ATT&CK, which systemizes adversary tactics and techniques, allows you to visualize which attack phases are visible and where blind spots exist. Indeed, the Sentinel post-deployment checklist includes "verify analytics rules against the MITRE framework" (Microsoft Learn, accessed 2026). Rather than aiming for comprehensive coverage from the start, it is more practical to begin with a small number of use cases directly linked to critical assets and refine them as you monitor false positives.

Step 4: Designing the Structure and Shift Schedules

Once the detection mechanisms are ready, decide who will monitor the alerts. Check the staffing requirements using the calculation logic mentioned earlier to identify time slots you cannot cover internally. For many mid-market companies, the split is internal during weekday business hours, and external services or AI for nights and weekends. The crucial point is that you must have a "decision-maker to act on notifications" assigned on the shift schedule. An operation where notifications arrive at night but no decision-maker can be reached is practically no different from not monitoring at all. The structural failure of night and weekend operations relying heavily on human availability is explained in detail in "Why Night and Weekend Security Shifts Fail."

Step 5: Maintaining Playbooks

Playbooks ensure that whoever is on shift can execute the same quality of initial response, even alone in the middle of the night. For each use case, document the logs to check, decision criteria, escalation paths, and the scope of authority for actions like device isolation or account deactivation. NIST's incident response guidelines, SP 800-61 Rev.3, outline the approach of integrating incident response into overall cybersecurity risk management, with the goal of preparing organizations for incident response, reducing the volume and impact of incidents, and improving the efficiency and effectiveness of detection, response, and recovery (NIST SP 800-61 Rev.3, 2025). Playbooks must be continuously updated to match new detection rules and environment changes, so ensure maintenance effort is budgeted under operational costs.

Step 6: KPIs and Review Framework

Finally, establish metrics to measure whether the operation is functioning and define the review cycle. Typical KPIs include Mean Time to Detect (MTTD), Mean Time to Recover (MTTR), the percentage of alerts actually investigated, and the false positive rate. Just as the Sentinel post-deployment checklist lists validating analytics rules and playbooks, tracking ingestion costs, and reviewing commitment tiers as continuous verification items (Microsoft Learn, accessed 2026), you need a framework to regularly review both detection quality and costs. The practice of designing and improving KPIs is discussed in "What are MTTR and MTTD? SOC KPI Design and Practical Improvement."

Four Common Pitfalls for Mid-Market Companies

Even when following these steps, mid-market SOC builds often stall at specific points. Knowing these in advance allows you to address them during the planning phase.

1. Inability to Hire

Filling a 24/7/365 schedule requires around six people per seat, but as the ISC2 study shows, the global talent shortage is growing, and the primary causes of shortages and skill gaps are budget constraints (ISC2, 2024). It is not easy for a mid-market company to hire and retain multiple dedicated analysts; planning based on the assumption that you can hire them is a risk in itself. Estimating the hiring capacity first and designing a model that supplements uncovered hours and processes with external resources or AI leads to a more resilient plan. The structure of analyst shortages and "alert fatigue" is analyzed in "SOC Analyst Shortage and 'Alert Fatigue'."

2. Operational Gaps at Night

While daytime operations might be established, night and weekend coverage often relies on IT department on-call standby. However, if the on-call responder lacks the authority or knowledge needed for investigation, and decisions are pushed to the next morning, 24-hour monitoring exists only on paper. Against fast-moving ransomware, you need an entity that can "complete the investigation and initial response at night," rather than just a notification recipient.

3. Ballooning Log Costs

Because SIEM costs are structured so that "the more you ingest, the more you pay," budgets are often blown the moment monitoring is expanded. The solution is decided during the design phase. The Microsoft Learn cost reduction guide recommends separating non-security operational data into a different workspace to keep it out of Sentinel billing, routing secondary security data not needed for real-time threat detection to a data lake, filtering ingested events with data collection rules, and choosing commitment tiers that match ingestion volumes (Microsoft Learn, accessed 2026). Instead of "collecting everything," separating logs used for detection, logs stored for compliance, and logs not to ingest is the realistic way to control costs.

4. Outsourcing Only Up to