Most product ideas start with a gap in the market. This one started with a pattern we kept seeing in incident response callouts — and a growing conviction that we were repeatedly cleaning up messes that should never have happened.
The scenario was almost always the same. A small organisation. A breach that had been running for days or weeks before detection. No monitoring in place. And a MD or practice manager staring at a screen, asking us what they should have done differently.
The answer was always the same too: you should have had a SOC. But that answer felt hollow when the follow-up question was invariably "how much does that cost?"
The Cost Architecture Problem
Traditional managed SOC services are expensive primarily because of their cost architecture, not because of what they do. The detection engine, the threat intelligence feeds, the analyst team — none of that inherently requires a six-figure contract. The cost comes from everything wrapped around it.
Dedicated infrastructure. Bespoke integration work for each client. Custom log ingestion pipelines. Months of tuning before monitoring goes live. Account management layers. The overhead of treating each client as a unique engineering project.
We already had something the traditional MSSP doesn't: our own SOC platform. SOC365 — built and operated in-house — was already running for enterprise clients. The detection rules, the threat intelligence integration, the analyst workflows, the EmilyAI triage layer: all of it existed and was already proven in production.
The question was whether we could deploy a sensor — a compact, pre-configured appliance — that would sit on a client's premises, collect the right telemetry, and feed it to SOC365 without any of the bespoke integration overhead that makes traditional SOC deployments so expensive.
The Insight: Move the Sensor, Not the Platform
This is the architectural insight that made everything else possible. In a traditional SOC deployment, the client's data travels to the SOC's infrastructure — or the SOC deploys agents and sensors into the client environment, requiring significant engineering time at each site.
We inverted this. Instead of bringing the client's environment to the platform, we built a self-contained sensor that could be pre-configured in our workshop and shipped to the client. Plug it in, point it at the network, and it connects back to SOC365. No on-site engineering. No bespoke integration. No months of setup.
The sensor handles network traffic analysis, endpoint telemetry aggregation, log collection, and deception sensor deployment — all in a single hardened appliance. SOC365 does the rest.
What We Refused to Compromise On
Early in the design process, we made a list of things that were non-negotiable. Things that, if we compromised on them, would mean we were building exactly the kind of product we were criticising.
- Same detection engine. Not a simplified version. Not a rule subset. The full SOC365 correlation engine, updated by the same threat research team that serves enterprise clients.
- Same analyst team. Not a separate tier of junior analysts for small clients. The same CREST-certified team that handles enterprise incidents.
- Named analyst assignment. Every client gets a named analyst who learns their environment. Not a ticket queue. Not a shared inbox. A person.
- No self-service detection. Clients shouldn't have to know what they're looking for. That's the analyst's job.
- Rapid deployment. If it takes months to go live, smaller organisations simply won't go through with it. Five working days, from order to 24/7 monitoring, was our target.
The Name
We spent longer than we expected on the name. "Managed detection and response" was accurate but invisible — every MSSP uses the same language. We wanted something that communicated the product's core proposition immediately: you order it, it arrives, and it is what it says it is.
SOC in a Box does that. It's slightly irreverent. It implies a challenge to the idea that a SOC has to be a vast, expensive operation. And it's memorable in a way that three-letter acronyms rarely are. The first time we said it aloud in a client meeting, they laughed — and then asked how to order one. That seemed like a good sign.
Next week, we'll get into the hardware: what goes inside the box, why we made the decisions we did, and why we offer both a physical appliance and a virtual one.
See What We Built
The concept is one thing. The product is another. If you'd like to see exactly what's inside — the detection engine, the analyst model, the deception technology — take a look at the full product overview.
See what's inside