Keep your SIEM.Rent the shift you cannot staff.
A co-managed SIEM leaves the platform, the license and the data where they are, with you, and moves a defined part of the work to somebody who does it around the clock. The arrangement is only as good as the split, so this page publishes ours.
A co-managed SIEM is one you continue to own while a provider takes a written, bounded share of running it, typically the out-of-hours shift, detection engineering and the data pipeline. It differs from a fully managed SIEM in ownership rather than in effort: the license, the tenant and the data stay yours, and the provider supplies labor into an environment you control. The distinction that matters at renewal is that you can end a co-managed engagement without migrating anything.
Who owns what,
written down.
Every co-managed engagement lives or dies on this table, and almost nobody publishes one. Ours is a starting point rather than a contract: the line items move to suit your team, and the moving happens before you sign rather than during the first incident.
| Task | You | Vijilan |
|---|---|---|
| The SIEM license and the data | Yours. On your paper, in your tenant. | We operate inside it. We do not resell it back to you. |
| Log source onboarding | You decide what gets connected and when. | We build the collection, the parsers and the normalization. |
| Detection engineering | You keep any detections your team wants to own. | We write, tune and version the rest, and we own the false-positive rate. |
| The overnight and weekend shift | Nothing. That is the shift you could not staff. | Analysts on rotation, not an on-call phone. |
| Triage and investigation | Your team keeps business-hours context we will never have. | We work the queue continuously and hand over what needs your judgment. |
| Containment actions | You set the authority, in writing, per action type. | We execute inside it, and escalate rather than improvise outside it. |
| Pipeline and ingest cost | You own the budget and the retention policy. | We control what is routed, shaped and dropped before it is billed. |
| Audit evidence | You own the control narrative for your auditor. | We produce the monitoring and response evidence that sits underneath it. |
Any source you run.
One standard underneath it.
Co-managed only works if the provider can meet your estate where it is. Ours is built to.
We take the sources you have
Whatever your clients run, and whatever they bought before you met them. Where a purpose-built connector exists we use it. Where one does not, we write the parser, normalize the fields, build the detections on top and the reporting on top of that. There is no list of supported vendors you have to be on first.
CrowdStrike underneath ours
Where the platform is ours rather than yours, it runs on CrowdStrike Falcon LogScale, which is the best log engine we have worked on and the reason our retention is index-free. Vijilan is a CrowdStrike Powered Service Provider. In a co-managed engagement the platform decision stays yours, and the engineering discipline is the same either way.
Plans written, then run
We write the incident response plan, rehearse it with you, and are the ones executing it when it is needed, which is a different promise from handing over a document. The same applies to the security program around it: built with you, operated by us, reported back in a form your board and your auditor can both read.
Vijilan is a boutique firm and takes on a small number of clients on purpose. In practice that means a named team who know your estate rather than a queue position, and work delivered finished rather than as a set of instructions for your engineers to carry out. It is the reason we can say yes to a source nobody else has written a parser for.
When co-managed is
the wrong answer.
It is a genuinely good model for a specific situation and a bad one outside it. Three cases where we will tell you so on the first call.
You have nobody in-house at all
Co-managed assumes somebody on your side owns the relationship, sets response authority and answers questions about the business. With no internal owner it is not co-managed, it is fully managed with extra steps. Look at ThreatRespond™ or NextDefend™ instead.
You want somebody to blame
Splitting a workload splits accountability, and the seams are real. If a single throat to choke is the point of the exercise, take the fully managed route and accept the loss of control that comes with it. That is a legitimate trade and we would rather you make it deliberately.
Your SIEM is the actual problem
If the platform itself is the constraint, adding analysts to it buys you better-staffed frustration. A move is the honest answer rather than a co-managed contract, and the one we would recommend is CrowdStrike Falcon Next-Gen SIEM. We publish the migration paths instead of pretending operations can fix an architecture.
Nothing fails in the middle.
It fails at the seam.
Handover, both directions
The dangerous hour in a co-managed SOC is the one where your team logs off and ours picks up, and the one twelve hours later going the other way. Both handovers are a written step with a named owner, not an assumption that the queue speaks for itself.
Authority, not intention
What we may isolate, disable or block on your estate without calling first is agreed per action type before day one. A provider who cannot answer that question in writing has not thought about the 3am case, which is the only case that matters here.
One queue, not two
Two teams working two views of the same estate is how an alert gets closed twice and an intrusion gets closed never. We work your queue in your platform rather than shadowing it in ours.
Questions worth asking,
of anyone.
What is a co-managed SIEM?
An arrangement where you keep ownership of the SIEM platform, its license and its data, and a provider takes a defined part of the work of running it. Usually that is the out-of-hours shift, detection engineering and the data pipeline. It sits between running the SIEM yourself and handing it over entirely, and the value of the arrangement depends almost completely on how precisely the split is written down.
What is the difference between co-managed and fully managed SIEM?
Ownership. Under a fully managed SIEM the provider owns the platform, the tenant and usually the license, and you consume the outcome. Under a co-managed SIEM those stay with you and the provider supplies labor and engineering into an environment you control. Fully managed is simpler; co-managed keeps your data, your tooling decisions and your exit options in your hands.
Is a co-managed SOC the same thing as a co-managed SIEM?
They overlap and are not identical. A co-managed SIEM is about the platform: collection, parsers, detections, retention. A co-managed SOC is about the people: who is on shift, who triages, who is allowed to act. Most real arrangements are both, which is why the two phrases get used interchangeably, but a provider who will do one and not the other is worth catching early.
Do we have to move to CrowdStrike Falcon Next-Gen SIEM?
No. Co-managed means you keep what you have, and we operate inside SIEMs we did not choose as a matter of routine. Vijilan runs Falcon Next-Gen SIEM on LogScale as its own platform because we think it is the strongest engine in the category, and we are a CrowdStrike Powered Service Provider, so if you ever do want to move we are well placed to do it. None of that is a condition of working together. The platform decision on a co-managed engagement is yours and already made.
What if we run something obscure that nobody supports?
Then we write the parser. Sources without a purpose-built connector are normal in a real estate, particularly in OT, older line-of-business systems and anything a company inherited through an acquisition. Building the collection, the normalization and the detections for those is ordinary work here rather than a change request, and it is usually where a co-managed engagement earns its keep in the first quarter.
Who owns the detections you write for us?
You do. Detections written against your environment stay with your environment, and you keep them if the engagement ends. A provider who treats your detection content as their intellectual property has built a switching cost into a service you are supposed to be able to leave.
How does co-managed affect our SIEM bill?
It is the part of the arrangement most likely to surprise you, in either direction. Ingest volume drives the bill on most platforms, and what gets routed, shaped or dropped before it lands is an engineering decision rather than a policy one. We control that side of it and you keep the budget, which only works if both parties can see the same numbers. Ask any provider how the ingest decision gets made and who reviews it.
What has to be agreed before day one?
Response authority, in writing, per action type. Everything else in a co-managed engagement can be adjusted as you go, but what we may do on your estate at 3am without calling you is the one thing that cannot be worked out in the moment. That document is the engagement.
Related reading
- Fully managed SIEMThe same problem solved by handing the platform over instead.Read
- NextDefend™Deploy, Sustain, Operate: the same split, on Falcon Next-Gen SIEM.Read
- ThreatRespond™Your tools, our SOC, over the EDR and identity stack you already run.Read
- SIEM migrationFor when the platform itself is the constraint, not the staffing.Read
- What 24/7 actually meansWho is on shift at 3am, and what they are permitted to do.Read
Bring us the table.
We will tell you which rows we can take.
Twenty minutes, your split, our answer on each line. If co-managed is the wrong shape for your team we will say that too.