Co-Managed SIEM: Who Owns Detection, Tuning, and Response

Co-managed SIEM is an arrangement where you keep your SIEM platform and its data, and an outside provider takes on part of the daily work of running it. The provider's share usually covers monitoring, rule tuning, parser upkeep, and log health. It lets a team buy round-the-clock labor it cannot staff while keeping control of the platform.

The risk is in the split: when the provider owns the rule and the customer owns the response, an alert can pass every contractual checkpoint and still reach nobody who will act on it at 3 a.m. on a Saturday. The arrangement holds up when the contract assigns each handoff to a named party, and the breach investigations below show what happens when it doesn't.

TL;DR:

• Co-managed SIEM has no standard scope. Contracts with the same label can assign triage, investigation, and response decisions to different parties, so the responsibility matrix matters more than the service name.
• Accountability tends to break at handoffs, where one team sees the alert and another is supposed to act on it. A loosely scoped split creates more of them.
• A contract can move the work without moving the risk. Payment card, financial-services, and proposed healthcare rules keep compliance responsibility with the organization that outsources.
• Detection content ownership decides how portable the program is. If custom rules and tuning history cannot leave with the customer, switching providers means rebuilding.
• Co-management fits teams that already make risk decisions but cannot staff every shift. Teams without anyone to own the response decision need a managed service that takes it on.

What Co-Managed SIEM Is and How It Differs From Managed SIEM and MDR

Co-managed and fully managed SIEM differ in who controls the platform. In a fully managed SIEM, the provider typically runs the platform end to end and the customer sees the outputs, such as alerts and reports. In a co-managed SIEM, the customer keeps full platform access, can review and approve detection content, and stays in the decisions, while the provider handles the time-consuming operational work.

MDR is a different contract. An MDR provider monitors around the clock, owns the investigation of agreed-upon alerts, and takes response actions where the agreement allows, which extends the customer's team. Its scope is the alert, wherever it comes from, and the upkeep of a specific platform generally falls outside it. SOC as a service goes further than MDR, often bundling it with managed SIEM, detection engineering, and compliance reporting under one contract. Co-managed SIEM is the one model built around a platform the customer already owns.

Scope also varies inside the co-managed label. One provider may monitor alerts overnight and tune rules. Another may also investigate incidents, build use cases, prepare audit evidence, and execute preauthorized response actions. Some route SIEM alerts into their own MDR workflow and treat the SIEM as one more data source.

Who Does What in a Co-Managed SIEM

The table below lists the work streams a co-managed contract has to assign, where each one usually lands, and how it tends to break when the contract leaves it vague.

‍

These gaps usually open where each side assumed the other owned the work. If neither side owns rule approval timelines, for example, untuned rules and open exceptions pile up because each expects the other to clean up the false positives.

Where Accountability Breaks in a Co-Managed Split

In the Target, Interserve, and HSE incidents below, a detection fired and nobody acted on it. None of the three involved a co-managed SIEM, but each failed at the kind of seam a co-managed split adds by design: a boundary between the team that sees an alert and the team that acts on it.

The Alert Fires and Nobody Acts on It

As Businessweek reported in March 2014, Target's monitoring team in Bangalore sent FireEye malware alerts to Target's security operations center in Minneapolis during the 2013 breach, and nothing happened. A Senate committee analysis published the same month found that Target learned of the breach only when the Department of Justice contacted it on December 12, 2013.

Interserve's antivirus quarantined malware delivered by a phishing email and raised an alert, and the company did not investigate it thoroughly. The attacker kept access, compromised 283 systems and 16 accounts, uninstalled the antivirus, and encrypted personal data on up to 113,000 current and former employees. In October 2022, the UK Information Commissioner's Office fined Interserve £4.4 million and listed the failure to respond to that first alert among the causes.

The Detection Source Is Neglected and Its Alerts Go Unworked

Ireland's health service, the HSE, was hit by Conti ransomware in 2021. The independent post-incident review PwC completed that December found that the first workstation the attacker compromised hadn't received antivirus updates in over a year. The HSE relied on a single antivirus product that wasn't monitored or maintained across its systems. The product still detected Cobalt Strike, a tool ransomware groups commonly use, on six servers on 7 May 2021, but the alerts weren't acted on properly. The HSE only noticed them when its security provider flagged them on 12 and 13 May.

In a co-managed split, the provider may watch alerts from a sensor the customer maintains, and neither side's SLA covers keeping that sensor current or working what it reports.

The SLA Measures Only the Handoff

Some SLAs start the clock when the provider opens a ticket and stop it when the provider notifies you. Such an SLA measures the handoff, and containment falls outside the clock. Credits capped at a fraction of the monthly fee, and exclusions that apply whenever the customer misses an obligation, narrow the SLA further. Before treating an SLA as a promise about outcomes, read when the clock starts and stops, what's excluded, and what you get if the provider misses the target. "We will monitor 24/7" commits to an activity; an outcome commitment names a containment time for P1 incidents.

Rules Stop Firing and Nothing Turns Red

A detection rule can stay enabled, throw no error, and stop producing the alert it was built for. CardinalOps' 2025 analysis of production SIEMs found that, on average, 13% of an organization's SIEM rules were broken because of problems such as misconfigured data sources, missing fields, and parsing errors. The same report found the average SIEM had detections for only 21% of MITRE ATT&CK techniques. In a co-managed split the rule belongs to the provider and the log sources to the customer, and unless the contract makes someone responsible for confirming each rule still fires, the drift sits between them.

Ingestion Cost Quietly Shrinks Coverage

Many SIEMs are licensed on data volume. Microsoft Sentinel, for example, bills analytics logs per gigabyte or through daily ingestion commitment tiers. In a co-managed model the customer pays that bill while the provider writes the detections that depend on the data, so cost pressure lands on the side that cannot see the coverage impact. Volume-based billing pushes teams to cut high-volume sources first, and a dropped source can silently disable rules the provider still lists as active. Agree in writing that no source leaves the SIEM until the provider confirms which detections depend on it.

The Record of What the Provider Did Disappears

The tickets, chat logs, and alert history that show what a provider did with an alert usually live in the provider's systems. If the contract does not require those records to be retained, a customer may be unable to reconstruct a monitoring failure during an investigation or dispute. Write preservation, retention, export, and access rights into the contract.

The Contract Does Not Move the Risk

A co-managed SIEM or MDR contract moves liability for a missed detection only where its terms say so. Compliance responsibility doesn't move at all. The contract should spell out what the provider is liable for: a wrong investigation call, a response action it agreed to take and didn't, or some other defined failure. It should also state the cap on that liability.

Some providers offer a breach warranty. It's a separate promise from the service itself, so review its cap, any ransomware sub-cap, waiting period, eligibility rules, conditions on how your environment is maintained, and which costs it covers. A warranty that pays certain breach costs is different from liability for missing a detection. Ask the provider to state in writing whether any warranty covers the co-managed service.

Regulators and standards bodies agree that the organization outsourcing the work keeps the responsibility. Under PCI DSS v4.0.1 Requirement 12.8.5, you have to document which requirements each service provider handles, which you handle, and which you share. The standard also notes that using a compliant provider "does not make a customer PCI DSS compliant." DORA Article 28 says financial entities that rely on ICT service providers "remain fully responsible" for meeting their obligations. In healthcare, the proposed HIPAA Security Rule update, published in January 2025 and not yet final, says an organization handing Security Rule work to a business associate "remains liable for compliance."

Detection Engineering Ownership Is the Real Test

In most co-managed contracts, the provider writes and maintains the detection rules and the customer approves changes. You still answer for what those rules miss, and legal liability for false negatives needs a clause of its own. The contract should also say whether the provider writes rules for your environment or adapts a shared library, and whether the rules, playbooks, parsers, and configurations built for you belong to you, as distinct from the provider's reusable library. If they do, and you can export them with their tuning history, switching providers means replacing the labor while keeping the detection program.

Externally authored rules can carry a second cost. Heavy reliance on a provider's content can leave the internal team less familiar with both the threats and the detection logic, and false negatives may go unnoticed longer as a result. Name one owner for the detection-as-code pipeline, covering version control, rule testing in CI, and attack-simulation regression tests mapped to ATT&CK. Keep suppressions for your environment outside the provider's base rules, where tuning out local noise can't weaken the shared rule.

When Co-Managed SIEM Fits and When It Doesn't

Co-management works when your team already makes the security decisions and needs more hands to carry them out.

• If your team owns detection priorities and business context but lacks the people to cover nights, maintain every detection, or supply every SIEM engineering skill, co-managed SIEM fits.
• If nobody internally understands the SIEM, skip co-management, which assumes an informed internal owner. An MDR service that investigates and responds on top of the SIEM is the better match.
• If nobody on your side can own risk decisions or coordinate response, co-managed SIEM is the wrong model.
• If retention and audit are why the SIEM exists, keep a system of record for them, whether that is the SIEM or a security data lake, and decide separately who owns response.
• If your priority is a named party accountable for the response decision at 3 a.m., you are buying a managed service, and the contract should say so.

A cheaper co-managed fee can cost more overall if your team still investigates every alert the provider hands over, and a pricier managed service may need far less of their time.

Questions to Settle Before You Sign

Get written answers to these before signing:

• Who approves a detection rule change, and how quickly does the customer have to respond before the change ships?
• What does "closed" mean for an alert, and who is allowed to close one?
• When does the SLA clock start and stop, and does it measure notification or containment?
• Which response actions can the provider take without calling you, and who holds authority after hours?
• Who notices, and who pays, when a log source stops sending or gets dropped for cost?
• What leaves with you at termination: custom rules, tuning history, parsers, playbooks, and the provider's records of what it did?

Treat any answer of "it depends" as a term still to negotiate.

Keeping the SIEM While Handing Off the Response Decision

Co-management fixes the staffing problem on the platform side and leaves the response decision with the customer, where Target's alerts stalled. Teams that can own that decision around the clock keep their platform, and their detection content where the contract allows, while buying labor they cannot hire. Teams that cannot should staff for it or hand it to a managed service that owns investigation and response, so someone other than the Saturday on-call owns the next step.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. Its MDR service works with the SIEM and data lake you already have. It investigates security alerts from those tools, plus alerts from its own proprietary detection rules on log data.

Frequently Asked Questions About Co-Managed SIEM

Is Co-Managed SIEM the Same as a Co-Managed SOC?

No. A co-managed SIEM splits the operation of one platform: monitoring, tuning, parsers, and platform health. A co-managed SOC splits the security operations function itself, which can span several tools, shift coverage, investigation, and incident response. A co-managed SOC often includes SIEM work, but a co-managed SIEM contract rarely covers the rest of the SOC.

Does Co-Managed SIEM Include Incident Response?

Rarely in full. Incident response, from containment to recovery, is usually a separate engagement or retainer, even when the co-managed contract lets the provider take a few preauthorized containment actions. Ask what happens, and who pays, when an investigation turns into an incident that outgrows the co-managed scope.

How Is Co-Managed SIEM Usually Priced?

Few providers publish list prices, and quotes tend to scale with log volume, data sources, or assets in scope. The SIEM license and ingestion costs typically sit on top, which makes the provider's fee only part of the total. Ask whether new use cases and after-hours response carry extra charges.

Can a Co-Managed SIEM Provider Work With the SIEM You Already Have?

Usually. Many co-managed providers support the major SIEM platforms, and the practical check is your log sources. A provider that supports your SIEM may still lack parsers or detections for a homegrown application or a niche SaaS tool. Ask for its supported-source list and a plan for anything missing.