Co-Managed SIEM: What It Is, How It Works, and Who Needs It

A co-managed SIEM is a shared operating model in which an organization's security team and an external provider divide the work required to run a security information and event management platform. The customer remains actively involved; the provider supplies agreed operational capacity or specialist skills.

The model suits organizations that already have security ownership and business context but cannot cover every shift, maintain every detection, or supply every SIEM engineering skill internally. It is a poor fit when nobody on the customer side can own risk decisions, coordinate response, or keep the provider informed about the environment.

The phrase has no universal service boundary. One provider may tune rules and monitor alerts overnight. Another may also investigate incidents, build use cases, prepare evidence, or execute preauthorized response actions. This guide turns the label into a responsibility map a buyer can test.

What is a co-managed SIEM?

Co-managed SIEM is a service arrangement in which the customer and a provider jointly operate the customer's SIEM capability under a documented division of work.

A SIEM collects and analyzes security telemetry to identify activity that needs investigation. Co-management addresses the people and operating process around that technology: who keeps data flowing, maintains detections, reviews alerts, investigates suspicious behavior, approves containment, reports incidents, and improves coverage afterward.

Customer ownership of the software is common, but it is not a defining rule. The platform can be customer-owned, provider-hosted, or cloud-based. The defining feature is active participation by both parties. Rapid7's public explanation and Trustwave's service description illustrate different versions of the model, which is why buyers need a written responsibility schedule rather than relying on the service name.

How does a co-managed SIEM work day to day?

A co-managed SIEM works through a shared queue, agreed coverage hours, role-based access, escalation rules, and a responsibility matrix that assigns every recurring SIEM and incident task.

The table below is a planning model, not a default contract. "Shared" still needs one accountable owner, a deadline, and an escalation route.

A serious incident exposes the model quickly. The provider may validate suspicious identity activity at 02:15, gather related endpoint and cloud events, and page the customer's on-call contact. The contract must already say whether the provider can disable an account, isolate a host, or block a token. If it cannot act, the customer needs a reachable person with authority to decide.

NIST SP 800-61 Rev. 3 recognizes that third parties can take primary or limited incident-response roles within a shared-responsibility model. It recommends documenting each party's roles, responsibilities, authorities, coordination method, information flow, and measures of effectiveness. Those details belong in operating documents and exercises, not only in sales slides.

Who needs a co-managed SIEM?

Co-managed SIEM fits an organization that has an accountable internal security owner and useful in-house capability, yet needs outside coverage, engineering capacity, or specialist investigation support.

Strong signs that the model fits

• The organization already owns or has standardized on a SIEM and wants to preserve the investment.
• Internal analysts understand the business and can handle selected investigations or response decisions, but staffing does not cover nights, weekends, leave, and incident surges.
• Detection content, parsers, connectors, or platform health are falling behind because engineering time is scarce.
• Regulated or sensitive environments require internal oversight, direct platform visibility, defined data access, or close control over response authority.
• The security team wants outside specialists while keeping selected workflows, detections, or environments under internal control.
• The organization is preparing to build more capability internally and wants a documented transfer of knowledge rather than permanent dependence.

Signs that another model will fit better

• No internal person can own the service, provide business context, or make time-sensitive response decisions.
• The organization wants the provider to supply the platform, people, operating process, investigation, and most response work as one service.
• The internal team cannot maintain contacts, asset scope, escalation rules, credentials, or approved actions.
• Leaders expect the provider to carry regulatory accountability or business risk on the organization's behalf.
• The main need is a one-time SIEM deployment or consultancy project rather than continuous operation.

What should the internal team keep?

The internal team should keep accountability for security priorities, business context, service oversight, risk decisions, and the organizational work needed to contain and recover from incidents.

At minimum, assign one service owner who can update scope, resolve disputes, review performance, coordinate internal responders, and approve changes. The organization also needs current asset owners, after-hours contacts, escalation thresholds, and a clear path to legal, privacy, communications, and management teams.

• Security and detection priorities tied to critical systems and business processes
• Accurate asset, identity, application, cloud, and third-party context
• Approval of access, integrations, telemetry scope, retention, and major detection changes
• Authority for disruptive containment actions and exceptions
• Remediation, recovery, business continuity, and acceptance of residual risk
• Regulatory and contractual decisions, including notifications and customer communication
• Supplier oversight, performance review, renewal, and exit decisions

What can a co-managed SIEM provider handle?

A provider can handle contracted SIEM engineering, monitoring, triage, investigation, reporting, and response assistance, while the customer keeps the responsibilities chosen for internal control.

Common provider work includes connector maintenance, parsing, rule development, tuning, threat-intelligence enrichment, queue monitoring, initial investigation, case documentation, service reporting, and recommendations after incidents. Some services add 24/7 human coverage, threat hunting, forensics, or preauthorized containment. Others stop after alert escalation.

Coverage must be checked activity by activity. A proposal that says "24/7 monitoring" may refer to automated ingestion health, human alert review, or full investigation. Ask what a named analyst will do after a high-severity alert and how soon that person is required to act. For the ongoing work behind tuning and onboarding, see Q-Sec's Managed SIEM maintenance guide.

What should co-managed SIEM onboarding produce?

Co-managed SIEM onboarding should produce a verified scope register, access model, responsibility schedule, escalation tree, detection baseline, response-authority list, reporting plan, and acceptance record before routine monitoring begins.

Connecting log sources is only the technical opening move. Each source needs an owner, purpose, criticality, expected volume, retention rule, parser status, health check, and documented gap. The buyer should be able to distinguish a source that is connected from one that is producing usable security data.

• A source inventory with criticality, data owner, expected activity, ingestion status, retention, and known blind spots
• Named provider and customer accounts with role-based permissions, strong authentication, approval, logging, and revocation procedures
• A responsibility schedule covering steady-state work, service changes, major incidents, reporting, access reviews, and exit
• An agreed severity model, contact tree, ticket route, coverage calendar, escalation clock, and communication method
• A detection baseline showing enabled use cases, required sources, testing results, exclusions, versions, and unresolved gaps
• A response-authority register separating recommendations, preauthorized actions, customer approvals, and prohibited actions
• Sample service reports, case records, evidence exports, and management summaries with delivery dates and owners

Acceptance should include evidence that critical sources are arriving, priority detections generate the expected cases, contacts receive escalations, authorized actions work, and both teams can retrieve the same incident record. Open gaps need owners and deadlines. Without that acceptance record, the service can enter production with a green dashboard and a red operating reality.

How does co-managed SIEM compare with in-house and managed SIEM?

Co-managed SIEM divides operations between the customer and provider. In-house SIEM keeps the work inside the organization; fully managed SIEM assigns most contracted platform and monitoring work to the provider.

Managed SIEM may also cover detection maintenance, alert triage, investigation support, and reporting, while the customer retains business-risk ownership, internal coordination, remediation, recovery, and decisions outside the provider's authority.

A co-managed SIEM also differs from a co-managed SOC. SIEM co-management can be limited to one platform and its alerts. A co-managed SOC describes the wider security-operations model, which can include endpoint, identity, cloud, network, threat hunting, case management, incident response, and management processes beyond SIEM.

Where do co-managed SIEM arrangements fail?

Co-managed SIEM arrangements usually fail at the seams between teams: an alert is seen, but no one clearly owns the next action, the deadline, or the business decision.

An activity is marked "shared" without one accountable owner

Shared work needs one accountable owner for each outcome. Assign who performs the task, who approves it, who must be consulted, and who receives the result. Add a deadline and escalation route for missed handoffs.

Coverage hours do not match response availability

Overnight alert review has limited value when the customer cannot approve containment until morning. Pair provider hours with an internal on-call rota or preauthorized actions that are technically and legally acceptable.

Access is broader than the work requires

External analysts may need access to sensitive logs, cases, identities, endpoints, and cloud consoles. Use named accounts, least privilege, strong authentication, time-bound access where practical, session logging, approval for elevated actions, and prompt revocation when roles change.

Detection changes lack versioning and approval

A tuning change can reduce noise or hide a real threat. Require documented rationale, testing, version history, rollback, exception handling, and customer approval for changes that affect critical coverage.

The customer stops building internal knowledge

Co-management can quietly become dependence when the provider holds rule logic, parser knowledge, investigation history, and service documentation. Schedule regular working sessions, keep shared records current, and define export and handover requirements before renewal pressure arrives.

Which service levels matter in co-managed SIEM?

Useful co-managed SIEM service levels measure source health, human triage, escalation, investigation, approved response, detection changes, evidence delivery, and shared-queue backlog.

Platform uptime alone cannot show whether anyone noticed a failed security source or acted on a serious alert. Define the result, timer, severity, coverage period, evidence, exclusions, and owner for each measure. Where both teams affect the outcome, separate the provider clock from the customer's decision or remediation clock.

• Log-source health: time to detect and report silence, malformed data, queue delay, or failed parsing for critical sources
• Triage: time from an eligible alert entering the queue to human review and disposition by severity
• Escalation: time from validation to delivery of the required evidence to a reachable customer contact
• Investigation: first analysis, update frequency, and time to an agreed investigation output
• Response: time to execute a specifically preauthorized action after the required conditions are met
• Detection maintenance: turnaround for urgent tuning, new use cases, broken rules, testing, and approved release
• Reporting and evidence: time to deliver case records, timelines, access records, and agreed audit material
• Backlog: age and volume thresholds for untriaged alerts, open investigations, failed sources, and overdue changes

State when every timer starts, pauses, and stops. Record whether the clock runs in calendar hours or service hours, which inputs the customer must supply, and what happens after repeated misses. Service credits can address a commercial failure; they do not repair a delayed containment decision. Trend measures and root-cause reviews are more useful than a monthly average that hides one severe miss.

What should European buyers verify before signing?

European buyers should verify legal roles, data and remote-access locations, subcontractors, security controls, incident support, reporting timelines, audit evidence, and exit terms before a co-managed SIEM contract is signed.

Under NIS2, entities in scope remain responsible for their cybersecurity risk-management and incident-reporting duties. Article 21 includes incident handling and supply-chain security among the required measures. Article 23 sets an EU-level reporting sequence that includes an early warning within 24 hours and an incident notification within 72 hours for significant incidents, subject to the directive and national implementation. The contract should make provider detection, escalation, evidence delivery, and customer decision points fast enough to support that clock.

The official ENISA technical guidance gives practical examples for entities covered by Commission Implementing Regulation (EU) 2024/2690, including incident roles, activity logs, and evidence records. It is useful procurement evidence within that scope; it does not make SIEM mandatory or replace sector and national requirements.

Security telemetry can contain personal data. Where GDPR applies, document the processing roles, purpose, instructions, confidentiality, security measures, subprocessors, international transfers, assistance, deletion or return, and audit information. Financial entities should also map relevant provider terms to DORA requirements for ICT third-party risk, contract content, incident assistance, access and audit rights, and exit.

• Where logs, cases, backups, and support data are stored and processed
• From which countries provider staff and subcontractors can access the environment
• Which party acts as controller, processor, or subprocessor for each data flow
• How quickly the provider validates, escalates, and supplies evidence for a significant incident
• Who communicates with management, customers, insurers, CSIRTs, and competent authorities
• Which reports, case records, timestamps, access logs, and detection versions remain available for audit
• What the customer can export at termination and how access, copies, credentials, rules, and integrations are removed

How should you evaluate a co-managed SIEM before buying?

Evaluate co-managed SIEM by testing one written responsibility map against real alerts, an after-hours incident, a detection change, a failed log source, and contract exit.

1. Inventory the work

List every recurring task across platform health, ingestion, detections, monitoring, investigation, response, reporting, improvement, access, and compliance support. Include work that occurs monthly or only during a serious incident.

2. Assign the responsibility and clock

Give each task a performer, one accountable owner, required inputs, deadline, evidence output, and escalation route. Replace vague entries such as "joint investigation" with observable actions.

3. Run an after-hours scenario

Use a scenario that requires a real decision, such as suspicious privileged access followed by endpoint activity. Trace detection, validation, contact, authority, containment, evidence preservation, internal communication, and recovery. Record every wait and missing permission.

4. Test service change

Add a critical cloud source, change a detection, investigate a false positive, and simulate a broken connector. Confirm approval, turnaround, version history, quality checks, and any extra charge.

5. Test the exit before entry

Request sample exports for cases, rules, parsers, dashboards, reports, access records, and service documentation. Confirm transition assistance, deletion evidence, credential removal, timing, format, and fees in the contract.

Final thoughts: Who should choose co-managed SIEM?

Choose co-managed SIEM when the organization has a capable internal owner, wants to retain meaningful control, and can define the specific coverage or skill gaps an external team must fill. Choose a fully managed model when the internal team cannot operate its retained share reliably.

Before comparing providers, write down who watches the queue at night, who changes detections, who can contain a compromised account, who produces evidence, and who answers when a handoff is missed. Then run the model against one serious incident. A workable answer is a better buying signal than a long feature list.

Frequently asked questions about co-managed SIEM

Is co-managed SIEM the same as managed SIEM?

No fixed industry definition separates every offer, but the common distinction is customer involvement. Co-managed SIEM keeps the customer's team active in selected operations or decisions. Fully managed SIEM assigns most contracted SIEM operation to the provider. The responsibility schedule is more reliable than either label.

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

No. Co-managed SIEM concerns operation of the SIEM capability. A co-managed SOC covers a broader security-operations function and can include endpoint, identity, cloud, network, threat hunting, incident management, and response processes beyond the SIEM platform.

Do you need an internal security team for co-managed SIEM?

Yes. The team can be small, but the organization needs an accountable service owner, business and asset context, reachable response contacts, and authority for decisions the provider cannot make. Without that internal core, a fully managed model is often more practical.

Who owns incident response in a co-managed SIEM model?

Ownership depends on the contract. The provider can triage, investigate, recommend actions, or execute preauthorized containment. The customer still governs business risk, recovery, legal decisions, and actions outside the provider's authority. Assign each incident step before service begins.

Does co-managed SIEM include 24/7 monitoring?

Only when the contract includes continuous human monitoring. Confirm whether 24/7 refers to platform availability, automated alerting, human triage, investigation, or response. The service should also state which severity levels receive overnight action.

Is co-managed SIEM cheaper than fully managed SIEM?

Sometimes, but there is no dependable universal rule. Co-management can reduce the provider's scope while leaving more staffing and management cost with the customer. Compare the full platform, people, coverage, support, retention, investigation, and response cost. Q-Sec's Managed SIEM pricing guide explains the main European cost drivers.

Can co-managed SIEM support NIS2 compliance?

It can support logging, monitoring, incident detection, investigation records, and evidence delivery when those activities are properly scoped. NIS2 does not prescribe a SIEM product, and using a provider does not transfer the entity's risk management, governance, or incident-reporting duties.