Managed Security Service Provider Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope get written around dashboards instead of the case?

The brief usually opens with a multi tenant dashboard. Alert counts, a severity breakdown, a map. It is the thing that demonstrates well to a prospect, so it is the thing that gets specified, and it is the reason so many managed security builds arrive as a reporting layer with a ticket queue bolted on.

What the operation actually runs on is the case, and a case in a managed detection business is not a ticket. It carries the alert group, a timeline that survives a dispute, evidence with hashes and collection times, the analyst's reasoning at each step, the technique mapping, containment actions with the authority that permitted them, every client communication, and a disposition with a quality review. Model that as a ticket with a status field and you have built a helpdesk that happens to display security alerts.

This matters more here than in most verticals because the case record is the product. Your client is not buying alerts, which their tools already generate. They are buying the judgement applied to them and the evidence that it was applied. That evidence has legal weight: public companies in the United States face materiality disclosure timelines, and healthcare and payment sector clients carry their own notification obligations. Ask your counsel what applies to your specific client base, then check the record can support it.

The fix is to specify the case object before anything visual. Write down every field an analyst must capture, make the whole thing append only so nothing is editable after the fact, and only then design screens over it. Dashboards built on a well modelled case are cheap. Cases retrofitted under a dashboard are a rebuild.

What goes wrong normalising alerts from client stacks you do not control?

One analyst covers nine clients. Client A runs Microsoft Defender and Sentinel, client B bought CrowdStrike and keeps logs in Elastic, client C has SentinelOne plus a firewall vendor that sends alerts by email. Until a hostname, a user and a timestamp mean the same thing regardless of origin, correlation is impossible and every investigation is manual translation between consoles.

The specific trap is treating normalisation as a one time mapping exercise. It is not. Two clients running the same product with different configurations still send you different fields, and vendors change their outputs without asking. A connector that worked in testing quietly starts dropping a field, and nobody notices until an investigation goes sideways because the user attribution was blank for three weeks.

The fix is to adopt an open model such as the Open Cybersecurity Schema Framework rather than inventing your own, because analysts move between employers and detection content travels better when field names are not proprietary. Then instrument the connectors themselves: alert on a source that stops sending, on a field that starts arriving empty, and on a volume that changes shape. Budget connector maintenance as a standing cost, because it is the part of this build that never finishes.

Why do the client stack connectors break after launch?

Connector count is the largest cost driver in this category and the least visible one at quoting time. Every new client who bought something different adds one, and each one has its own authentication model, its own rate limits and its own idea of how far back you can query.

The breakages follow a pattern. Credentials expire, usually on a rotation the client's own IT team performs without telling you. Tenant permissions get tightened during an unrelated audit and your read access quietly narrows. A vendor deprecates an interface version with a notice that went to an inbox nobody monitors. And onboarding a new client under time pressure produces a connector configured to get data flowing, with the field mapping left approximate and never revisited.

The fix is to treat every connector as a monitored asset with a heartbeat, an expected volume envelope and an owner. Build a coverage view per tenant showing which sources are live, when each last delivered, and which detection content depends on each source, so a silent source immediately reveals which detections are now blind. Set credential expiry as a tracked date rather than a surprise, and make client offboarding and re onboarding a defined process instead of an afternoon of improvisation.

What happens when per client containment authority is not covered?

Every client has different rules. Which endpoints can be isolated without asking. Whether a user account can be disabled at 3am. Who to call, in what order, and what happens when the first three numbers go unanswered. Which server must never be touched because it runs a production line. Which notification template applies.

In most providers this lives in a document in SharePoint that was last updated when the client's IT manager still worked there. So at 02:40 the analyst does the reasonable thing, calls the daytime contact, gets voicemail, and the response clock keeps running while nothing happens. The gap is not analyst capability. It is that the answer to what am I permitted to do right now requires a document search under time pressure.

The fix is to make runbooks structured data attached to the tenant rather than prose: approved actions with the authority level each requires, escalation contacts with hours, channels and an ordered fallback, communication templates, and asset exceptions carrying a reason and a review date. Express authority per action per asset class, not as a single toggle, because isolating a workstation is a different risk from disabling an account. Automate only what carries standing approval, log every action with its authorisation and its reversal path, and leave the rest human. The goal is not full automation. It is that permission is a field an analyst can see in the interface where they are already working.

Should you build custom or configure what you already own?

Several providers reading this should not build. Under roughly ten clients on a single standardised stack, your best return comes from tuning detections and hiring well, and a platform build consumes the capital that should go into analysts. Stellar Cyber is a genuine head start if you are willing to standardise clients onto its detection content and correlation, and if your portfolio genuinely fits that shape you should take it. D3 Security brings mature case management and playbook automation with multi tenancy, and if orchestration is your specific gap it deserves a serious evaluation before you write any code. Reselling an established managed detection service such as Blackpoint is a sound business too, provided you are honest that it makes you a distribution channel rather than a security operations business, and you price and value the company accordingly.

The friction with platforms that supply detection content is predictable rather than mysterious: they want to be the stack, your clients already own stacks you cannot displace, and you end up running both while analysts pivot between consoles anyway. With orchestration platforms the friction is that your service tiers, evidence standard and client specific containment authority become configuration inside someone else's object model. For a business whose margin depends on how an analyst spends a night shift, that layer is an uncomfortable place to be a tenant.

Build when two or more apply. You have passed roughly 25 clients or three distinct stacks. Your response commitments are contractual and you cannot prove compliance from data. Containment authority lives in documents. Regulated clients or insurers are asking for evidence standards your tooling cannot produce. Or your detection content is your differentiator and it has no version control, which means your main asset is undocumented.

How do hidden costs get into the quote?

The first hidden cost is the connector tail. A quote priced against your four largest sources looks reasonable until you count the long tail of firewall vendors, identity providers and email security products across the client base. Ask for a per connector rate and a maintenance rate, and price the portfolio you actually have rather than the one you wish you had.

The second is telemetry. Per tenant retention with fast search over months of data is an infrastructure decision with a real monthly bill, and it should be settled before a line of application code is written. Providers who default to centralising everything become a data platform business by accident and pay for it forever. For clients who already run their own log platform, leaving telemetry where it sits and building the case, runbook and service level layer above it is dramatically cheaper.

The third is tenant isolation done properly. A cross tenant leak is a business ending event in this industry, and the enforcement boundary is a day one architectural decision rather than a later hardening pass. If a quote treats isolation as row level filtering added during development, the price is wrong and so is the design.

What separates a build that works from one that fails here?

The service level clock decides it. Most providers commit to response times by severity and then measure compliance afterwards by reading tickets, which is a postmortem rather than a control. Worse, severity often arrives from the source tool, so a client with a noisy endpoint product generates critical alerts that are nothing while a real intrusion arrives as a medium.

A build that works gives each tenant its own severity mapping and its own commitments, runs a live clock with explicitly defined pause conditions such as awaiting client approval, and shows analysts time remaining rather than time elapsed. That single change alters queue behaviour immediately. Breaches get recorded as facts with a cause, and the monthly client report draws from the same data the analysts lived through, so the two never disagree.

The rest is discipline. Give detection content a lifecycle, authored centrally, versioned, tested against historical data, deployed per tenant with a recorded enablement decision, and tuned with every exception carrying a reason and a review date. Track false positive rate per rule per tenant so a rule generating most of a client's noise gets fixed rather than suppressed again. And settle code ownership in writing before kickoff: the repository, the cloud accounts and the right to hire anyone else. Detection content and case history are the assets an acquirer pays for, and they should never sit somewhere you cannot leave.