Managed SOC or SOC as a service?

The two terms are used loosely and often interchangeably, which makes comparing offers harder than it needs to be. The distinction that actually matters is not the label. It is who owns the platform, who owns the detection content, and what happens to both if the relationship ends.

The two shapes

A managed SOC, in the sense most providers use it, means the provider operates a security operations capability on your behalf using tooling that you own or license. Your SIEM, your endpoint detection platform, your data. Their analysts, their processes, their coverage model.

SOC as a service usually means the provider brings the platform as well. Your logs go into their environment, their detection content runs against it, and you receive the outcomes.

In practice the line blurs. Plenty of engagements are a mixture: the provider brings the detection platform but you keep your existing endpoint tooling, or you own the SIEM licence but the provider owns everything built on top of it.

What actually changes between them

Who owns the data, and where it sits

With a managed SOC on your own platform, the log data stays in your tenant. You can query it, retain it as long as you choose, and use it for things unrelated to security.

With SOC as a service, the data typically sits in the provider's platform. That raises questions worth answering explicitly: where geographically, retained for how long, who else's data shares the environment, and what happens to yours at the end of the contract.

For organisations with data residency obligations, this is often the deciding factor rather than a detail.

Who owns the detection content

This is the part most often overlooked and the most expensive to lose.

Detection content is not just rules. It is eighteen months of tuning, the exclusions that stop your particular service accounts generating noise, the thresholds set to your actual traffic, and the case history that tells a new analyst what normal looks like here.

If that content lives in your platform, it is yours. If it lives in the provider's, ask directly what you get on exit. "Reports" is not an acceptable answer, and the time to establish this is before signing.

Cost shape

Managed SOC on your own platform means you carry the licensing and ingestion costs directly, and they scale with log volume. That is visible, controllable, and occasionally alarming.

SOC as a service usually bundles it, which makes budgeting easier and the underlying economics less visible. It also means the provider has an incentive to limit what you send, which can quietly constrain coverage. Ask what the ingestion limits are and what happens when you exceed them.

Speed to running

SOC as a service is generally faster to start, because the platform already exists and the detection content is already written. A managed SOC on your own platform is faster only if the platform is genuinely in place and configured, which is worth verifying honestly rather than assuming.

Which fits

Your own platform, managed tends to fit when you already have significant investment in a SIEM, when data residency or retention requirements are strict, when you have internal security staff who need access to the same data, or when you expect to bring the capability in-house eventually.

Platform included tends to fit when you have no meaningful detection tooling today, when you want a defined monthly cost rather than variable ingestion charges, when speed matters more than portability, or when there is no internal team to use the platform for anything else.

Neither is more mature or more serious than the other. They suit different situations.

What does not change

Whichever model you choose, some things remain yours.

Deciding what matters. Which systems are critical, what data would be damaging to lose, what you are prepared to accept. A provider can advise and will ask, but the answer is a business judgement.

Authority to act. What the provider may do without asking (isolate a host, disable an account, block an address) should be agreed in writing in advance, per action, with the out-of-hours case covered explicitly. Left vague, it defaults to waiting for someone, which is exactly the delay you were trying to remove.

Everything after the first hour. Containment is where an external team adds most value. Recovery, root cause, customer communication and regulatory notification involve your systems, your relationships and your obligations.

Telling them what changed. New systems, new applications, decommissioned servers. Coverage drifts silently unless someone reconciles it, and the provider cannot monitor what they do not know exists.

Questions that reveal the difference

1. At the end of the contract, what leaves with us: data, detection rules, tuning history, case records?
2. Where does our log data physically reside, and for how long?
3. Who writes and maintains the detection content, and how often is it reviewed against our environment specifically?
4. Can our own team query the raw data directly, or only read reports?
5. What are the ingestion limits, and what happens when we exceed them?
6. What can you do without asking us, at 2am?

The first and the last two produce the most informative answers.

The exit question is the real one

Both models work when run well. The difference that persists is how easily you can change your mind.

Ask what a transition out looks like in concrete terms: what you receive, in what format, over what period, and at what cost. A provider comfortable with that conversation is usually one worth engaging. A provider who treats it as premature is telling you something useful.