SOC Platform Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does trying to replace the SIEM sink so many SOC platform projects?

The scope conversation almost always opens with one pane of glass, and one pane of glass is a short phrase that quietly contains an ingestion pipeline, a search engine, a correlation engine and a detection content library. Six weeks later the team is benchmarking storage tiers instead of building case management, and the analysts who were promised a better shift are still living in nine browser tabs.

This happens in security more than in most verticals because the incumbent boundary is genuinely blurry. Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, Elastic Security and Google SecOps all present themselves as the centre of the operation, so a team building above them has no obvious line to draw. Without a line, the project absorbs the detection engine by default, and the detection engine is decades of engineering you have no reason to repeat.

The fix is a written system of record map produced before any code. For each of raw telemetry, detection logic, entity records, case state, disposition history, playbook versions and containment audit, name exactly one authoritative system. The split that works puts telemetry and detection with the incumbent, and entities, cases, dispositions, playbooks and containment audit in the platform you are building. Put that map in the statement of work as a constraint rather than as a diagram in an appendix. Every scope argument for the next nine months then resolves in about a minute, which is the entire value of writing it down.

What goes wrong when you migrate years of case history into the new platform?

Institutional memory is the reason to build, so every team plans to import its ticket history on day one. Then the import lands and the history turns out to be a free text field. A closed ticket reads benign, no further action, and that sentence cannot tell you whether this detection has fired eleven times, how often it was benign, or what the two true positives had in common.

There is a second, quieter problem. Historical tickets reference accounts and hostnames as they were written at the time, so a short username, the full address form of the same account and a laptop serial reassigned in March are three unrelated strings. Until aliases are resolved retroactively, imported history is searchable by keyword and not by entity, and entity search is the only search that changes an analyst's day.

Define the disposition taxonomy before the migration rather than after. Decide the closed states, the reason codes and the required fields, then backfill only the alert classes that genuinely repeat, which in most estates is a short list. Run entity resolution across that backfilled set so those cases attach to the same people and hosts your live cases attach to. Everything older comes across as an attachment on the entity, searchable and honest about being unstructured. Paying an analyst to read three years of tickets is a real quote line, and it is almost never worth what it returns.

Why do detection tool integrations break after launch?

Every detection vendor has its own API, its own pagination, its own token lifetime and its own idea of what an alert is. Those differences are visible at build time and get handled. What breaks later is different: a product update renames a field, a tenant migration moves an endpoint, or the identity team revokes a service account during a quarterly access review because nobody could say who owned it.

The resulting failure mode is specific to a security operations centre and it is nasty. When an integration stops delivering, the queue does not throw an error. It goes quiet. A quiet queue at 3am reads as a calm night, so the outage gets discovered days later when somebody asks why the email gateway has produced nothing since Tuesday. In most software a broken integration announces itself. Here it hides inside the exact signal you use to judge whether anything is wrong.

The fix is a heartbeat per source with expected volume bands by hour and by day of week, learned from your own history rather than set as a fixed threshold, plus an alert when a source drops outside its band. Register every integration service account as an owned asset with a named owner, a credential expiry and a review date, so the next access review renews it instead of killing it. Then put source health on the same screen as the queue. A health dashboard nobody opens is not monitoring, it is decoration.

What happens when containment authority and audit logging are not covered?

Containment is where a SOC platform stops being a workflow tool and starts touching production. Isolating a host, disabling an account, blocking a sender: each is one API call and each can take out something that matters. What we see most often is a platform that can contain, an escalation policy that lives in a wiki, and nothing in between.

Two things go wrong from there. A misfiring detection triggers an automated isolation on a payment host during month end close, and the security team gets to explain to finance why the platform bought to reduce risk created an outage. Or the reverse: an analyst who genuinely should isolate a host at 2am cannot find anyone with authority, so nothing happens for four hours and the incident grows.

The compliance side compounds it. Your platform holds the map of your estate and the record of every investigation, which makes it a high value target and a regulated data store at once. A case touching cardholder data or health records carries retention and access obligations that a nuisance alert does not, and those obligations attach to case type rather than to the platform as a whole.

Four parts fix this and none are optional. An authority matrix keyed to asset criticality and time of day, so who may act on a domain controller at 2am is configured rather than remembered. A blast radius check that runs before the action, not after. A recorded authority naming the human who approved it. And a reversal path tested before go live rather than during the first incident.

Should you build custom or configure what you already own?

Configure, if you are a small team on a uniform estate. Three analysts, one detection stack and a mostly Microsoft environment is a case where Microsoft Sentinel plus disciplined ticketing beats anything you build, because Sentinel already groups related alerts into incidents and its workbooks will answer your reporting questions. Spend the difference on detection engineering, which is where the security improvement actually lives at that size. Elastic Security is the same argument on a different stack. If your need is modest case management with no bespoke escalation logic, TheHive is open source and honest about its scope, and Tines will carry straightforward enrichment and containment flows without a project.

That is not a consolation prize. Most teams who ask us about a SOC platform have not exhausted what their current tooling does, and we would rather say so than take the work and watch it under deliver.

Build when two or more of these hold. Your detection stack spans four or more vendors with no shared identity between them. Analysts are re-investigating repeat alert classes because prior conclusions are not retrievable. Your escalation and authority rules are specific enough that a vendor template actively obstructs them. Retention differs by case type for regulatory reasons. Or you are large enough that a ten percent improvement in analyst throughput exceeds the build cost, which at $90,000 to $180,000 for a first release is a smaller headcount equivalent than most managers assume before they run the arithmetic.

How do hidden costs get into the quote?

The biggest one is integrations priced as a category rather than a count. A quote reading integration with your detection tooling is a quote that will be renegotiated, because the fourth source costs nearly as much as the first and no version of this project keeps the source list fixed. Ask for a price per source, get the sources named in scope, and get the long tail explicitly excluded so the exclusion is a decision rather than a surprise.

Containment is the second. Calling an isolation API is an afternoon. The approval gate, the blast radius check, the recorded authority and the tested reversal are the work, and a quote that prices containment as automation has priced the afternoon.

Then the lines nobody volunteers. The parallel run, where analysts work both the old consoles and the new queue for several weeks. Multi region data residency if security telemetry cannot cross a border, which is architecture rather than a feature. Classification handling in government or defence environments, likewise. On call for the platform itself, since a SOC platform that is down during an incident is worse than not having one. And entity reconciliation, which is a person making merge decisions on ambiguous identities and is not a task any tool finishes alone.

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

The builds that work start with the entity model and refuse to move past it. Ask any prospective developer how they will resolve a short username, the address form of the same account, the hostname, the serial, the endpoint agent identifier and the cloud instance identifier into one thing. Listen for alias tables, confidence scoring and a manual merge path for ambiguous cases. Anyone who treats this as data cleanup has not built one of these.

Then ask what happens when a broken detection rule produces two hundred thousand events in an hour, because eventually one will. Backpressure, deduplication and the ability to suppress a noisy detection without deploying code are operational requirements. A platform that falls over during the flood has failed at exactly the moment it was needed.

Insist that measurement is built in rather than added later. Time to acknowledge and time to contain by alert class, split by shift, computed from the event stream by construction, plus the ranked list of detections consuming the most analyst hours for the fewest true positives. That list is your tuning backlog and it is worth more than any detection content you could buy.

Settle code ownership in writing at kickoff, including the repository and the infrastructure accounts. At Digital Heroes the client owns the code from the first commit. A security team that cannot audit or fork its own operational platform has rebuilt the lock in it set out to escape, and has paid for the privilege.