Co-Managed SIEM for MSPs: What You Own, What the Client Owns, What Still Needs Testing

A client gets hit on a Tuesday, you open the co-managed SIEM, and the timeline is clean.

No alerts. Nothing escalated. Somebody moved through an environment you're paid to watch and the console has nothing to say about it. That isn't always a product failure, and it usually isn't laziness either. It's a boundary problem.

Here's the sentence worth keeping. Your SIEM tells you what fired. It can't tell you what it missed.

Two different questions. Only one of them has an answer sitting inside the platform.

What co-managed SIEM actually means

MSP Pentesting is channel-only, and we spend most of our week on the far side of that boundary, testing environments other MSPs monitor and writing the report under their brand.

Co-managed SIEM means the client owns the platform and you own the work. Their tenant, their license, their retention, their exit path. Your engineering, your detection content, your analysts on the queue. That's the whole definition, and it's worth being pedantic about it, because three neighboring terms get used as synonyms and they aren't.

• Comanaged SIEM is the same product with a missing hyphen. Both spellings turn up in RFPs and both should return your page.
• Co-managed SOC shares an operations function, not just a tool. Shift handoffs, escalation trees and analyst notes matter more than rule syntax.
• Co-managed security services and co-managed IT security services are commercial wrappers. They describe a contract shape, not a technology. When a prospect uses either one, ask which functions are actually shared before you price anything.

Clients choose co-managed for unglamorous reasons. They already bought the license. Their compliance scope says log data stays in their tenant. Their board doesn't love one vendor holding both the evidence and the accountability. That's control, not technology.

You choose it for equally unglamorous reasons. Recurring revenue without carrying license risk, a way into an account that won't hand over the keys, and a seat at the table when they decide what to buy next.

Draw the ownership line before go-live

Every ugly co-managed engagement we've been called into afterward shares a root cause. Nobody wrote down who owned what, so the gaps went to whoever noticed last. Which is nobody.

Put the split in the service description, not the sales deck. Then attach the log source inventory as a dated appendix. When a source falls off six months later, that appendix is the difference between a fix and an argument about whose fault it is.

The four places a co-managed SIEM goes quiet

1. Log sources nobody turned on

Windows process creation events don't carry command lines until somebody enables command line auditing in policy. PowerShell script block logging is off until you switch it on. DNS query logging is usually off because it's loud. Cloud identity sign-in and audit logs depend on the license tier the client bought, and so does how long they're kept.

So the rule shows enabled, the dashboard shows green, and the telemetry that rule needs was never collected. It can't fire. There's nothing for it to fire on.

2. Parsers that break quietly

A vendor ships an update, a field name shifts, the parser stops mapping it. The rule still reads enabled. It just never matches anything again, and nobody gets alerted about the absence of alerts unless somebody built that check deliberately.

Build it deliberately. A per-source heartbeat, checked daily, catches more real problems than most detection content does.

3. Tuning that quietly became suppression

The noisy rule throws forty tickets a week. An analyst adds a filter. Then a wider filter. Six months on, the exclusion covers a whole subnet and the service account everyone got tired of seeing.

That's the account an intruder will use. It's the one that already has everything.

Review exclusions on a schedule. Each one needs an owner, a reason and an expiry date, or your detection logic slowly becomes a list of things you've agreed to ignore.

4. Ingest caps and the cost conversation

SIEM licensing usually meters volume. When the bill climbs, somebody drops the verbose sources: firewall, proxy, DNS, the chatty endpoint telemetry. Those are precisely the sources you need to reconstruct an incident.

If the client won't fund the ingest, that's a legitimate business decision. Just record it as a decision they made, with the detections it switches off listed underneath. Otherwise it turns into your failure during the postmortem.

Clock skew also makes correlation lie, and assets nobody onboarded aren't monitored at all. The site from last year's acquisition, the lab subnet, the vendor jump box. All in scope for an attacker. None of them in the SIEM.

What a SIEM structurally can't tell you

This is the part that sells the test, and we'd rather be blunt than clever about it.

• Whether a detection fires against a technique run the way an operator runs it. Content gets written against documented behavior. Real tradecraft varies the parameters until it stops matching.
• Whether a path exists that produces nothing worth logging. Credential abuse that looks like a normal logon, an over-permissive directory ACL, a password sitting in a share on a script from 2019. None of it is anomalous. All of it is a route.
• Whether anybody actually responds. The alert fires at 2am and the runbook says call a number. Does someone pick up? Do they hold the rights to isolate a host in the client's environment without waking a change board? Coverage isn't response.
• Whether the coverage map means anything. Mapping rules to MITRE ATT&CK techniques measures rules. It doesn't measure whether they work. A heatmap full of green is a claim, not evidence.

The frameworks already treat these as separate obligations, which is a useful thing to point at during a renewal. PCI DSS v4.0.1 keeps logging and monitoring in Requirement 10, penetration testing in Requirement 11.4, and intrusion detection separately at 11.5.1. The SOC 2 common criteria handle monitoring for anomalies under CC7.2. NIST CSF 2.0 splits detection into DE.AE and DE.CM and never implies either replaces testing. Nobody writing those documents believes a SIEM proves a control works.

The test that answers the missing question

Run it so every action produces two records: what the tester did and when, and what the platform produced. Then reconcile. Each action lands in exactly one of three buckets.

• Alerted. A rule fired, it reached a human, the ticket exists.
• Logged, not alerted. The telemetry was there and nothing correlated it. Cheapest bucket to fix, usually the biggest.
• No telemetry. Nothing recorded at all. This bucket costs money, because the fix is a log source or an agent, not a rule.

That three-bucket table is the deliverable. It turns an abstract argument about coverage into a funded line-item remediation plan, which is a much easier conversation than "we think you have gaps". Our pentest report template shows the format partners hand to their clients.

Decide up front whether the SOC knows. Both modes are honest. Blind gives you a true read on triage and escalation. Informed gives you far more coverage per hour, because nobody's waiting around to see whether anyone bites. Most co-managed clients should start informed and go blind on the second round.

Sell it without promising something you can't deliver

Two contract details prevent arguments later, and the first one is this. Split notification from response. Telling somebody inside fifteen minutes is a commitment you control. Containing something inside fifteen minutes depends on the client's change process, their approval chain, and whether your analyst has rights to act at 3am. Word them separately and price them separately.

And don't test your own detections and call the result independent. You wrote the rules. You picked the sources. You decided what to suppress. A review of that work by the team that did the work isn't independent under any definition an auditor, an insurer or a client's counsel will accept. That's the entire reason white-labeled penetration testing exists in the channel.

If the client is still choosing between building detection with you and buying an outcome from a vendor, walk them through the SIEM versus MDR comparison before you quote either one.

Questions that come up at the ownership boundary

Is co-managed SIEM the same as a co-managed SOC?

No. Co-managed SIEM shares a platform. A co-managed SOC shares an operations team. You can run co-managed SIEM with two engineers and a business-hours queue. You can't run a co-managed SOC that way without misleading somebody about what happens overnight.

Who owns the data in a co-managed SIEM?

The client, and that's usually why they picked the model. Say it explicitly in the agreement anyway, including what happens on termination: how long they keep access, what format an export arrives in, and who pays for it. Retention obligations don't end because the contract did.

How often should detections be validated?

Annually as a floor, and after anything that changes the telemetry: an identity migration, a new EDR, a SIEM version jump, an acquisition, or a rebuild of the log pipeline. If a change touched a log source, it touched detection coverage whether anyone meant it to or not.

Does the penetration test have to be detection aware?

If you want it to say anything about your SIEM, yes. A standard test reports exploitable findings. A detection-aware test also records a timestamped action log and reconciles it against what the platform produced. Same testers, extra deliverable, and you have to ask for it in the scope.

What if the client won't fund the missing log sources?

Document what that decision removes and get it acknowledged in writing. Then rank the gaps by what an intruder would actually use, because some sources are worth arguing for and some genuinely aren't. A short, ranked list gets funded far more often than a demand to onboard everything.

Reconcile the boundary before the next incident

Co-managed SIEM is one of the highest-value things an MSP sells and one of the easiest to oversell. The platform reports what fired. It stays silent about what it missed, and silence reads like safety right up until it doesn't.

Different question, different tool. Keep running the SIEM. Then have somebody who didn't build it come and find the gaps.

Nobody finds out what a SIEM missed by reading the SIEM. Get a pentest quote and put a live operator in front of it.