An MSSP security operations center is one shared team and tooling stack that a managed security service provider runs around the clock to detect and respond to threats across many client organizations.
People researching security operations centers for MSSPs are usually deciding whether to hand that work to a provider or build their own SOC. The shared model also carries obligations an in-house SOC never faces, including keeping each client's data separate and staying profitable as the client list grows.
An MSSP SOC is the operational core of a managed security service provider, where one group of analysts and one stack of tools monitor many client environments in parallel. The same service is often marketed as a managed SOC. IBM's overview of managed security service providers describes an MSSP as a third party that monitors and manages security on an organization's behalf, and the SOC is where that monitoring and response happens. Each client keeps its own environment, and the provider supplies the staff and tooling to monitor it.
IBM's security operations center explainer frames a SOC as the function that continuously monitors infrastructure and detects, investigates, and responds to threats. An MSSP SOC delivers that same work for every client it serves.
In practice, that work usually includes the following services:
Underneath those services, the MSSP runs one tooling stack across every client. A security information and event management (SIEM) platform collects and correlates logs, and endpoint or extended detection and response (EDR/XDR) covers devices and workloads. Security orchestration, automation, and response (SOAR) runs the response playbooks.
For a buyer, the choice is whether to rent capacity in this shared operation or to staff and tool a SOC internally.
An in-house SOC protects one organization's infrastructure, while an MSSP SOC is a service delivery model that serves many clients from a single set of infrastructure, staff, and tools. The in-house team answers to one leadership group and can tune every detection to one environment. The MSSP team serves all its clients and spreads the cost of analysts and tooling across them, overnight shifts included.
The ISC2 2025 Cybersecurity Workforce Study found that 33% of organizations lack the budget to staff their security teams adequately and 59% of respondents report critical or significant skills needs, up from 44% in 2024. It also found that 88% have experienced at least one significant security consequence caused by a skills deficiency. Those gaps explain much of the pull toward outsourcing, because a 24/7 SOC has to staff every overnight and weekend shift, and an MSSP absorbs that rota for the client.
In a co-managed SOC, sometimes called a hybrid SOC, the client's security team and the MSSP split the work. In the co-managed model Rapid7 describes, the internal team keeps security strategy, detection priorities, and final authority over incident response decisions. The provider handles continuous alert monitoring, detection rule tuning, and investigation support.
Organizations that need tight control over sensitive telemetry may still build in-house. Organizations that need continuous coverage without building a team often find the shared model easier to fund.
Serving many clients from one SOC adds three requirements a single-tenant SOC never faces.
Client data isolation comes first. Each tenant's telemetry, detections, cases, and reports must stay technically and logically separate, so an analyst working on one client's alert never sees another client's data. A query or detection rule scoped to one tenant must never return another tenant's events. In a single-tenant SOC, every log belongs to the same owner, so this problem never arises.
Per-client reporting is the second requirement. Every customer expects evidence of what the provider monitored and what it did when a detection fired. An in-house SOC reports upward to its own leadership, whereas an MSSP produces a separate report for each client, often on a recurring schedule, and that effort grows with every tenant added.
Margin-protecting economics is the third. When an in-house SOC makes a cost mistake, the damage stays inside one budget. When an MSSP's cost structure grows faster than its revenue, the problem affects every client and compounds as the roster grows. That makes licensing the requirement most likely to decide whether a multi-tenant SOC scales profitably.
Traditional SIEM and SOAR licensing charges by data volume or by seat, so an MSSP's cost floor rises with each client it signs and with each device or log source its clients add. An enterprise's bill grows with one business, while an MSSP's bill grows with the combined growth of all its tenants. Volume-based and device-based pricing also stack on top of each other across that combined growth.
Microsoft's Sentinel billing documentation shows how per-GB billing works for its analytics tier. Pay-as-you-go pricing is based on data volume, measured in gigabytes. Commitment tiers start at 100 GB per day, and usage above a tier is billed at the tier rate. A tier can be lowered only once every 31 days. Microsoft also offers a lower-cost data lake tier for high-volume logs, with queries against it billed per GB scanned. For a single organization planning its own ingestion, these terms are clear and predictable.
When an MSSP carries the license itself, the same mechanics tie its bill to the log growth of every tenant it serves. Onboarding a new client adds its full log volume. An existing client that moves workloads to the cloud or acquires another company raises volume without anyone at the MSSP making a decision. Because a commitment tier comes down only on that 31-day cycle, the license holder cannot step down quickly when a tenant shrinks or leaves. Many Sentinel-based providers instead manage a separate workspace inside each client's tenant. That moves the ingestion bill to the client, but the pressure to limit what gets ingested stays the same. Tiering helps, though someone still decides at ingestion which sources earn analytics-tier rates.
Per-device and per-user pricing ties cost to the size of each client's estate, so cost rises with device sprawl. Every new laptop, server, firewall, or cloud workload a client adds increases the number of protected units the MSSP must cover, and each new user adds more logins and endpoints. When tooling is licensed per endpoint for EDR or XDR and per user for identity monitoring, and the managed SOC service is priced on top, that growth shows up in several line items together.
Mixed device types push the effective rate higher still. Servers, endpoints, network gear, cloud workloads, and operational technology (OT) are often priced or sized differently. Each type can also produce different log volumes and require its own parsing and detection content. A client with a varied estate therefore costs more per protected unit than a client with the same number of uniform laptops, even before log volume is counted.
Across a client base, the effect multiplies because each client carries a different device profile. A manufacturer running OT on the plant floor and a software company that runs almost entirely on cloud workloads raise the provider's cost along different curves.
When volume and device growth push costs up faster than revenue, MSSPs come under pressure to limit what they ingest. In Strike48's view, many respond by capping per-tenant log ingestion to protect margins. High-volume sources such as firewall traffic and DNS queries feel that pressure first, because they cost the most to ingest under volume billing. Providers often present that margin decision as a technical limit, and clients paying for full coverage rarely see which sources were left out.
In Strike48's May 2026 survey of 100 security leaders, 84% said their current tools cannot access all their log data for investigations. The survey also found that 65% have had at least one investigation stall because data was trapped in a system their tools couldn't reach. Cost weighs on the same group, with 80% citing the cost of keeping data live and searchable as painful or a major budget concern. An MSSP that caps each tenant's ingestion builds that same gap into every client environment it serves.
A buyer evaluating providers can ask which of its log sources the provider will not ingest and what adding them back would cost. The answer shows whether the client's risk or the provider's licensing sets coverage.
To change the math, an MSSP has to break two links. One ties log volume to cost, and the other ties client count to analyst headcount. Federated search architecture addresses the first by querying data in its existing stores. Narrowly scoped AI agents address the second by handling the repetitive triage that would otherwise scale with headcount. Together, the two give agents context from every tenant's data and give the MSSP control over what those agents can act on.
Search-in-place connectors let an MSSP query each client's logs in their current stores, such as Amazon S3, Splunk, Elastic, or a data lake, without migrating or duplicating them. Parsing waits until a query runs, so nobody has to decide at ingestion which fields to extract or which sources are worth the processing cost. This is the model behind federated search for SIEM augmentation: it keeps a client's existing SIEM in place and adds a query layer across the surrounding stores.
Strike48's Flexible Data Foundation is built on this architecture. Its search-in-place connectors read existing log stores directly, and parse-at-query processing lets a team keep everything and parse only what an investigation needs. Auto-generated parsers cover new log sources as they appear, and Strike48's explainer on parse-at-query architecture explains why structure applied on demand keeps raw retention cheap.
Because the MSSP never copies a log into a second volume-billed store, its ingestion cost stops tracking any single tenant's volume growth. Logs a client already sends to Splunk or Elastic still carry that platform's license, and search-in-place adds no second bill on top of it. The larger gain comes from sources a cap would have excluded. High-volume firewall and cloud audit logs can land in Amazon S3 or a data lake at object-storage rates, and the MSSP queries them there when an investigation needs them. Coverage widens without the cost floor rising to match.
This also limits the log side of device sprawl. When a client adds servers or cloud workloads, their logs can flow to object storage without pushing the MSSP into a higher SIEM ingestion tier. Per-endpoint licensing for EDR and similar tools still scales with device count, and no data architecture changes that. Device growth no longer forces a second, volume-based increase on top of it.
Strike48 describes the traditional MSSP model as linear, with "more customers, more analysts", and the ISC2 figures above show how hard those analysts are to hire. Breaking that line safely depends on how narrowly you scope each agent.
A micro agent has one bounded job and reaches only the knowledge and tools that job requires. Model Context Protocol (MCP) connectors control which tools and data an agent can access during an investigation. Agents can still reach wrong conclusions, and narrow scope confines an error to one bounded task until a human reviews it.
Strike48's Pre-Built Agent Packages apply that design to the SOC. The SOC Level 1 and SOC Level 2 agents run alert triage and root cause analysis with the same investigation method on every alert in every tenant. Coordinator agents route work between specialist agents the way a SOC team hands off cases. Hybrid workflows keep consistency-critical steps rule-based and auditable, and reserve agent reasoning for steps that require judgment.
Agents work the raw alerts, and analysts review the verdicts they produce. Humans approve consequential actions such as endpoint isolation and remediation. Every agent action is recorded in a verifiable audit trail, so an MSSP keeps a traceable record of what was investigated in each tenant and why. With agents handling triage in every tenant, the same team can take on more customers without adding analysts one-for-one.
The design principles behind this model are covered in “What Is an Agentic SOC? Architecture, Agents, and Maturity Tiers.”
Maidar Secure, a South African provider of managed security and SOC services, announced its partnership with Strike48 on April 7, 2026. According to the announcement, client requests that once required multiple specialists and hours are now resolved in minutes. Maidar runs automated reporting for its clients and uses a phishing investigation agent built on a knowledge base of past cases.
Beyond this single partner, AWS's published case study on Strike48 reports remediation times that are more than 90% faster than traditional security systems. It also reports that customers save about $3 for every $1 they spend. Those figures describe Strike48 customers in general and are not specific to Maidar. Strike48 describes its data foundation as operating at petabyte scale and trusted by Fortune 500 companies, and the MSSP security automation platform overview shows how its pieces fit a multi-tenant operation.
An MSSP SOC works when each client's risk sets its coverage and the provider's margin holds as the roster grows. Querying logs in place keeps a tenant's log growth from raising the ingestion bill, even as its device count climbs. Scoped agents with human approval gates let a provider add customers without adding analysts one-for-one. Strike48's Flexible Data Foundation and Pre-Built Agent Packages deliver both changes in one platform.
The demo is built for evaluation. It includes a live agent demonstration and an honest question-and-answer session, so bring your toughest questions about what "agentic" means in practice.
A security operations center is the team and tooling that monitor an environment around the clock and respond to threats. An MSSP runs one for many clients at once.
MSSP SOC pricing varies based on how many users or devices it covers, how much log data it monitors, the mix of device types, and which services it includes, such as incident response or compliance reporting. Ask each provider which pricing unit it uses and which of your log sources fall outside the quoted coverage, since a low quote can reflect a capped ingestion scope.
A managed service provider (MSP) runs general IT operations such as networks, devices, user support, and backups. A managed security service provider (MSSP) specializes in security and runs a SOC that investigates alerts and responds to incidents. MSPs typically work from a network operations center (NOC), which tracks uptime and performance, while MSSPs work from a SOC, which tracks threats. Some providers offer both, but the security work needs its own staff and round-the-clock coverage.
Most run their own. ChannelPro's coverage of the MSSP Alert Top 250 found that 78% of Top 250 MSSPs ran their SOCs entirely in-house in 2025, up from 72% the year before. Only 4% fully outsourced the SOC. Smaller providers more often buy SOC-as-a-service, a subscription that delivers monitoring and response from a third party's SOC. Neither model requires a central physical facility, since analysts can work distributed on cloud-hosted tooling. Whichever model a provider uses, ask whether it delivers 24/7 monitoring and how it keeps each tenant's data and reporting separate.
Juan Del Rio is the Distribution & Enablement Coordinator at Strike48