Managed Security Service Provider Operations Software: What Happens When One Analyst Watches Nine Different Client Stacks?

Why an MSSP outgrows the consoles it monitors

It is 02:40. One analyst is covering nine clients. Client A runs Microsoft Defender and Sentinel. Client B bought CrowdStrike and keeps their logs in Elastic. Client C has SentinelOne and a firewall vendor whose alerts arrive by email. Three alerts fire within four minutes and two of them are probably the same actor moving laterally, but the analyst cannot see that because the evidence sits in two consoles with different field names and different timestamps in different time zones.

Meanwhile a contract says critical alerts get an initial response within fifteen minutes. Nobody is measuring that in a way that would survive a client asking. And the runbook that says which containment actions are pre approved for client B out of hours, and which named person to wake at what number, is a Word document in SharePoint that was last updated when their IT manager still worked there. The analyst does the reasonable thing and calls the daytime contact, who does not answer, and the clock keeps running.

That is the operational reality this software category exists to fix. The detection tools are not the problem. The problem is that your service, meaning your tiers, your response commitments, your escalation logic and your evidence standard, has no system of record.

What Stellar Cyber, Blackpoint and D3 actually leave you doing

All three are real options and each solves part of it. Stellar Cyber gives an MSSP a multi tenant platform with its own detection content and correlation, which is a genuine head start if you are willing to standardise on it. Blackpoint Cyber is effectively a managed detection service you resell, which is an excellent commercial answer for some providers and a strategic decision rather than a tooling one, because your service becomes theirs. D3 Security brings mature case management and playbook automation with multi tenancy, and if orchestration is your gap it deserves a look.

Where each leaves you working depends on which you pick, but the pattern is consistent. Platforms that supply detection content want to be the stack, and your clients already bought other stacks that you cannot rip out, so you end up running the platform plus the client consoles anyway and the pivoting problem returns. Reselling another provider's managed detection means the thing you sell, your detection quality and your response, is not yours to improve or to differentiate on. And orchestration platforms model a case the way they model a case, priced per user or per action, so your service tiers, your evidence standard and your client specific containment authority get expressed as configuration inside someone else's object rather than as the product you are actually selling. For a provider whose margin depends on analyst efficiency, the layer that decides how an analyst spends a night shift is not a good place to be a tenant.

Problem 1: nine stacks, nine schemas, one analyst

Normalisation is unglamorous and it is the foundation. Until an alert from Defender and an alert from CrowdStrike carry the same field for a hostname, the same representation of a user, and timestamps in a single timezone with source precision preserved, no correlation is possible and every investigation is manual translation.

A build maps every source into one schema. Adopt an open model such as the Open Cybersecurity Schema Framework rather than inventing your own, because analysts move between employers and detection content is easier to share and to hire for when the field names are not proprietary. The work is per source connector, and it is genuinely per source: two clients running the same product with different configurations will still send you different fields. Budget for connector maintenance as an ongoing cost, not a one time build, because vendors change their outputs without asking you.

The payoff is that an alert stops being a console notification and becomes a record with an identity, an asset, a user, a technique mapping and a client. Only then can nine alerts across three clients collapse into one case with a shared indicator, which is where a night shift stops being nine parallel jobs.

Problem 2: your case object is your product

A case in an MSSP is not a ticket. It carries the alert group, a timeline that survives a client dispute, the evidence collected with hashes and collection times, the analyst's reasoning at each step, the technique mapping, the containment actions taken and who authorised them, the client communications sent, and the final disposition with a quality review.

What a build does: model that explicitly and make it append only. Every state change, every note, every artefact keeps its timestamp and its author, and nothing is editable after the fact. This matters when a client challenges a response, when an insurer asks, and when an incident becomes a regulated disclosure, since public companies in the United States now face materiality disclosure timelines and healthcare and payment sectors have their own notification obligations. Your case record is the evidence that the service was delivered. Ask your legal counsel what your specific obligations are, then make sure the record can support them rather than assuming it will.

Problem 3: the SLA clock is a contract term nobody instruments

Most providers commit to a response time by severity, and most measure it after the fact by reading tickets. That is not a control, it is a postmortem. Worse, severity is often assigned by the source tool, so a client whose EDR is noisy generates critical alerts that are nothing while a genuine intrusion arrives as a medium.

A build gives each tenant its own severity mapping, its own service commitments per severity, and a live clock with defined pause conditions, typically awaiting client action or awaiting an approval you are contractually required to obtain. Analysts see time remaining rather than time elapsed, which changes queue behaviour immediately. Breaches are recorded as facts with a cause, and the monthly client report draws from the same data, so what you tell a client matches what your analysts lived through. Providers who instrument this usually discover the problem is not analyst speed, it is that a third of the clock burns waiting for a client contact who cannot approve anything at 3am, which is a contract conversation rather than a staffing one.

Problem 4: runbooks are documents and documents do not act

Every client has different rules: which endpoints can be isolated without asking, whether a user can be disabled at 3am, who to call and in what order, whether a specific server must never be touched because it runs production manufacturing, which notification template applies, and what the out of hours contact chain really is once the first three numbers go unanswered.

A build turns this into structured data attached to the tenant: approved actions with the authority level required, escalation contacts with hours and channels and an ordered fallback, communication templates, and asset exceptions with reasons and review dates. The analyst opening a case sees what they are allowed to do for this client, right now, in the interface where they are working. Automate the safe actions where the client has granted standing approval and log them fully. The unsafe ones stay human. The point is not full automation, it is that the answer to what am I permitted to do is a field rather than a document search at 3am.

Problem 5: detection content has no lifecycle

Your detections are your intellectual property and in most providers they live scattered across client SIEM instances, tuned individually, with no version history and no record of why a rule was suppressed for client D eighteen months ago. When a new analyst asks why an obvious detection is disabled, nobody knows.

A build gives content a lifecycle: authored centrally, versioned, tested against historical data before release, deployed per tenant with an enablement decision, and tuned with every exception recorded alongside a reason and a review date. False positive rates are tracked per rule per tenant, so you can see that a rule producing 40 percent of a client's noise needs work rather than another suppression. This is also the asset that makes you sellable, since a provider with versioned, measured detection content is worth considerably more than one whose value sits in three analysts' heads.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release with tenant isolation, normalisation for your top three or four sources, the case model with evidence chain, and SLA instrumentation runs $80,000 to $170,000 and ships in 14 to 20 weeks. Adding per client runbooks with automated containment, detection content management, the client portal, automated monthly reporting and billing by asset or ingest volume brings the total to $240,000 to $550,000 across 9 to 15 months.

What drives cost up: the number of distinct source products you must normalise, which is the single biggest driver and grows with every client who bought something different. Data volume and retention, since per tenant retention with fast search over months of telemetry is an infrastructure decision with real running cost, and you should design where telemetry lives before you write a line of application code. Automated containment, because acting on a client environment demands careful credential handling and reversibility. And compliance obligations, if you serve regulated sectors that require specific evidence retention.

What keeps cost down: leaving telemetry where it already sits for clients who have their own SIEM, and building the case, runbook and SLA layer on top rather than becoming a data lake business you did not intend to be in.

Build versus buy, and when buying is right

Buy if you are under roughly ten clients on a single standardised stack. Your leverage is in tuning detections and hiring well, and a platform build would consume the capital that should go into analysts. Reselling an established managed detection service is also a perfectly sound business, provided you are honest that you are a distribution channel rather than a security operations business, and you price accordingly.

Build when two or more apply. You have passed 25 clients or three distinct stacks and analysts are pivoting between consoles. Your response commitments are contractual and you cannot currently prove compliance from data. Client specific containment authority lives in documents. You are being asked for evidence standards by insurers or regulated clients that your current tooling cannot produce. Or your detection content is genuinely your differentiator and it has no version control, which means your main asset is undocumented.

How to choose a developer

Ask them how they would isolate tenant data, and expect a specific answer about the enforcement boundary rather than a promise about row level filters. In this domain a cross tenant leak is a business ending event and the design decision is made on day one.

Ask how they would model an SLA clock with pause conditions. If they have not thought about pausing for client action, they have not run an operation where the client is the bottleneck.

Ask what they know about security telemetry volumes and where they would put the data, then listen for retention tiering and search performance rather than a generic database answer. Ask for their experience with the specific tools your clients run, by name.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. For a provider whose enterprise value is measured on recurring revenue and defensible service delivery, owning the platform that delivers it is the difference between owning a business and reselling one.