Custom SOC Platform Development: Why Do Analysts Re-Investigate the Same Alert Every Week?

The shift that explains why this gets funded

Tuesday, 02:10. An analyst has nine browser tabs open. The EDR console shows a suspicious PowerShell execution on a laptop. The identity provider console shows a sign in from a new country for what may be the same user, except one tool calls the account jsmith and the other calls it john.smith@company.com and nothing joins them automatically. The email gateway has a quarantined message that may be the delivery vector. The asset system, which is a Confluence page, says the laptop belongs to someone who left in March. The analyst copies a hash into a threat intelligence portal, gets nothing useful, writes four lines in a ticket, and closes it as benign at 02:40.

Eleven days later the same detection fires on a different host. A different analyst does the same forty minutes of work and reaches the same conclusion, because the first analyst's reasoning went into a free text ticket field that nobody searches. That is the actual cost centre in a security operations centre. Not licences, not storage. Analyst attention spent re-deriving conclusions the team already reached, in an environment where the scarce resource is the number of judgements a trained person can make in a shift.

What Splunk, Sentinel, QRadar and the SOAR tools genuinely give you

Be fair to the incumbents, because they solve real problems and you will keep paying at least one of them. Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, Google SecOps and Elastic Security are detection and search engines. They ingest at volume, run correlation rules, and let you hunt across historical data. That is genuinely hard engineering and you should not rebuild it. Cortex XSOAR, Tines and Swimlane automate response actions, and Tines in particular is pleasant to work with for straightforward enrichment and containment flows. TheHive gives you open source case management if your requirements are modest.

Where they stop is the layer between them. A SIEM's case management is a byproduct of its detection engine, so it models an alert well and models an investigation poorly. It does not know that three alerts across EDR, identity and email are the same story, unless you have already built the identity resolution that lets it know. It has no opinion about which of your assets matter, because asset criticality is your business context and not something a vendor can ship. And a SOAR platform automates the steps you can already describe precisely, which excludes the majority of triage work where the decision is judgement rather than a branch.

The second issue is commercial gravity. Every one of these platforms would prefer to be the centre of your operation, which means your case history, your enrichment and your institutional knowledge accumulate inside a product whose pricing model is ingestion volume. Teams that build the workflow layer themselves keep the option to change detection vendors without losing five years of investigative history, and that optionality is worth real money in a market where per gigabyte pricing moves.

The three things a custom SOC platform has to get right

Identity resolution first. Nothing else works until an entity in your platform can absorb jsmith, john.smith@company.com, the workstation hostname, the serial, the EDR agent identifier and the cloud instance identifier as aliases of one thing. This is unglamorous plumbing and it is the whole foundation. Once entities exist, an alert is not a row, it is an event attached to a person, a host and an account, and three alerts from three tools collapse into one case automatically because they touch the same entities inside a time window you define.

Asset criticality second. A generic platform treats every host equally because it has no way not to. Your platform should know that a domain controller, a payment processing host and a developer laptop in the graphics team are three different risk conversations, and it should know this by pulling from your configuration management database, your cloud tagging and your identity groups rather than from a field someone maintains by hand. Criticality is what turns a queue of two thousand alerts into a queue of forty that matter.

Institutional memory third, and this is the feature that changes analyst throughput more than any automation. Every closed case records the disposition, the reasoning and the indicators involved, in structured fields rather than a text box. When a similar alert arrives, the analyst sees that this detection has fired eleven times, was benign nine times, and the two true positives shared a specific parent process. That is not machine learning, it is a database query that no vendor product runs because no vendor product owns your history. It is also where a language model earns its place: summarising prior similar cases and drafting the first paragraph of an investigation note from the raw events, which saves ten minutes per case and, more importantly, means the note actually gets written.

Playbooks that encode your escalation, not a template

The playbook library is where the organisation specific work lives. A phishing playbook in a bank with a fraud team escalates differently from one in a manufacturer where the same email hitting an engineering workstation on a plant network is a different problem. Escalation paths, out of hours authority, who may isolate a host in production and who may not, when legal must be told, when a regulator clock starts: none of that is generic.

Build playbooks as versioned artefacts with the same discipline you would apply to code. Each step declares whether it is automated, analyst assisted or a judgement gate. Automated steps run enrichment and containment through your existing tooling. Analyst assisted steps present the evidence gathered so far and ask one specific question. Judgement gates stop and require a named person. When a case goes badly, and one will, you want to open the case and see which version of the playbook ran, what it collected and where the human decided otherwise. Regulated organisations also need evidence retention rules attached to case types, since a case touching cardholder data or health records has retention and access obligations that a case about a nuisance alert does not.

Measurement is the part everyone skips and then needs

Ask most SOC managers for time to acknowledge and time to contain by alert class over the last quarter, split by shift, and you will get a two week data project. Build the platform to compute those from the event stream by construction. You want to know which detections consume the most analyst hours and produce the fewest true positives, because that list is your tuning backlog and it is worth more than any new detection you could buy. You want to know queue depth by hour so you can staff the shift that actually needs it. And when you go to the board for headcount or budget, you want a number derived from your own records rather than a vendor's benchmark.

What it costs and how long it takes

Across the projects Digital Heroes has delivered, a first release covering entity resolution, alert ingestion from your top three or four detection sources, case management with structured dispositions and a basic playbook engine runs $90,000 to $180,000 and ships in 14 to 20 weeks. That is a system your analysts run their shift in, not a prototype. The full platform adding the complete playbook library, automated containment actions, asset criticality integration, retention rules by case type, metrics and reporting, and a threat intelligence layer runs $250,000 to $600,000 phased over 9 to 15 months.

What drives cost up here specifically: the number of detection tools to integrate, since each has its own API, its own rate limits and its own idea of what an alert looks like. Containment actions, because isolating a host or disabling an account touches production and needs approval flows and a rollback path. Multi region data residency if you operate under rules that prevent security telemetry crossing borders. And classification handling in government or defence environments, which changes the architecture rather than adding a feature.

What keeps it down: integrate the tools that generate most of your alert volume and leave the long tail on manual triage for now. In most estates three sources produce the large majority of the work.

When you should not build this

If you have three analysts, one SIEM and a fairly uniform Microsoft estate, Sentinel plus a disciplined ticketing process will outperform anything you build, and the money is better spent on detection engineering. If your alert volume is low enough that every analyst remembers every prior case, you do not have the institutional memory problem yet.

Build when two or more of these are true. Your detection stack spans four or more vendors with no shared identity. 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 gets in the way. You need evidence retention that differs by case type for regulatory reasons. Or you are large enough that a ten percent improvement in analyst throughput is worth more than the build.

How to choose a developer for a SOC platform

Ask them how they will resolve identities across your tools before anything else, and expect a real answer involving alias tables, confidence scoring and a manual merge path for ambiguous cases. A developer who waves this away has not built one of these.

Ask what they will do about alert volume: how the ingestion path behaves when a misconfigured rule produces two hundred thousand events in an hour, because it will. Backpressure, deduplication and a way to suppress a noisy detection without deploying code are operational requirements, not nice to have.

Ask whether they have worked inside a security team's constraints: least privilege service accounts for tool integrations, audit logging of every analyst action, and the fact that your platform is itself a high value target holding the map of your estate. Then ask about containment specifically. Anyone can call an isolate API. Fewer people design the approval, the blast radius check and the undo.

Get code ownership in writing at kickoff, including the repository and 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 recreated the vendor lock in it was trying to escape.