Between “we build all of it ourselves” and “we hand all of it over” sits the model that actually works for most organizations: co-managed SIEM. The platform is yours; operations and detection work sit with the provider.
The problem with the term: it describes a division of labour and that division rarely appears in concrete form in a proposal. This article writes it down, the way we actually handle it in our engagements.
The licence question: who owns the platform?
That’s the first fork in the road, and its consequences reach well beyond price.
In our model, the customer buys the subscription. We work from an MSSP tenant, managing the customer tenant from there. Throughout, the customer keeps independent access, the same data, the same rules, the same alerts, reachable without us.
Why that matters only becomes visible in three places:
- On exit. If the provider holds the licence, the contract ending also ends access to the platform and frequently to the historical log data inside it. Owning the subscription means you change providers, not systems.
- During your own investigations. Your team shouldn’t have to wait for someone to work a ticket before seeing raw data.
- For evidentiary obligations. Regulators and auditors ask for data, not for reports about data. Direct access is the simplest answer.
The opposite model (provider owns licence, tenant and data) isn’t wrong as such, but it’s a dependency you should enter deliberately rather than by accident. The test question: what exactly do we still hold the day after the contract ends?
Who writes the detection rules?
We do. And typically without a dedicated customer approval process. We decide on professional judgement which rule goes live, gets adjusted, or gets retired.
That sounds like less control at first. In practice it’s the reason the model is faster than building in-house: a detection rule that waits four weeks for a change advisory board has detected nothing for four weeks. Detection work is a continuous cycle of writing, observing, sharpening and discarding: put an approval body in every step and the cycle stops.
What replaces approval is transparency: you see the rules in your own platform. If you want one of them different, that’s a conversation, not a form.
How an alert reaches you
This is where a SOC service either works under pressure or doesn’t. Two things have to be defined beforehand, not during the incident.
Prioritization: severity times confidence
We rate every finding on two axes:
- Severity: how bad would it be if the finding is correct?
- Confidence: how sure are we that it is?
The combination produces a priority of P1, P2 or P3. The distinction matters practically: a highly critical finding with weak confidence is a different thing from a confirmed finding of medium severity and both deserve different handling from an alert that is neither.
That separation is why you don’t get a phone call at three in the morning for every theoretically critical hit.
The communication matrix
Before go-live we agree a communication matrix with you: which priority travels over which channel, to whom, in what order, with which fallback. Usually that means email and phone: email for anything that has to be documented, phone for anything that can’t wait.
It’s unglamorous, and that’s exactly why it matters. The most common reason a verified critical alert goes nowhere isn’t missing detection. It’s a phone number nobody updated after the last role change.
What you have to deliver
Co-managed means obligations stay with you. Two of them are not negotiable.
Reachability. A P1 alert needs someone on your side who picks it up and is allowed to decide. Who holds that role and how cover is arranged belongs in the communication matrix, not in individual people’s heads.
Reporting changes. New systems, changed network segments, migrated workloads, one additional cloud service: anything touching scope has to reach us so we can bring the log sources in.
The second point is routinely underestimated. A SIEM’s most dangerous blind spot isn’t the badly configured source: it’s the source nobody mentioned. A server that has been running in production for three months and appears in no ingestion configuration produces no alerts. It produces no error either. It’s simply invisible, and that only surfaces once it’s compromised.
How long onboarding takes
A few weeks to production: considerably faster than standing up your own platform, because deployment, source onboarding and the initial rule library are practised work rather than a blank page.
Realistically, a tuning phase follows. The first weeks of live operation always produce findings that made sense in theory and are noise in your specific environment. That isn’t a defect; it’s the part of the work that can’t be done in advance.
What “median response time under one hour” actually measures
We quote that figure on our Managed SIEM / SOC page, so here is precisely what it means and what it doesn’t.
It measures from alert to first analyst action. That is: how long does it take, at the median, for a human to actually pick the finding up?
What the number does not say is that an incident is contained within an hour. How long containment takes depends on the incident, on the affected infrastructure, and on decisions made on your side. Any metric that promises a blanket containment time deserves scrutiny.
We deliberately publish the pickup time, because it measures what the provider alone controls. When comparing vendors, always ask for the measurement points: “under one hour” means nothing without a start and an end.
What the choice between a cloud platform and an installation in your own data centre means in practice is covered in Cloud SIEM vs. On-Premises.
When co-managed is the wrong model
- When no platform exists and none is wanted. If you deliberately don’t want to hold a SIEM subscription at all, a fully outsourced model serves you better.
- When there’s nobody to reach internally. The model presupposes a counterpart. Without a named, reachable role, even the best P1 alert goes nowhere.
- When you can sustain your own 24/7 SOC. Then you need targeted support at most, not co-management.
How technology, function and delivery model relate to one another in general is broken down in SIEM, SOC, MDR.
Bottom line
Co-managed SIEM works when the dividing line is explicit. Ours, in short:
| You | Subscription, tenant, data sovereignty, reachability, reporting changes |
| Us | Operations, detection engineering, tuning, triage, prioritized handover |
| Together | Communication matrix, scope, escalation paths |
What’s missing from a proposal ends up mattering more than what’s in it. Ask about licence ownership, data access after contract end, rule authority, prioritization logic, and the measurement points behind every stated time. A provider who answers those five clearly has an operating model. One who deflects is selling a dashboard.