CSIRT vs SOC: Who Watches, Who Decides and How to Organise Both

Most organisations can say who watches their alerts, but far fewer can say who has the authority to take a production system offline at 3am, and that gap between a security operations centre (SOC) and a computer security incident response team (CSIRT) is where serious incidents lose hours. A SOC runs continuous detection and triage. A CSIRT owns incidents once declared: decisions, coordination, evidence and recovery. Whether they are one team or two is an operating model choice, not a naming question. This guide is for CISOs, SOC managers and incident response leads deciding how to structure, staff and connect the two functions, including when an MDR provider runs detection. For CSIRT build steps, see the Building a CSIRT Guide; for SOC build steps, see the Building a SOC from Scratch Guide.

Key takeaways

• The SOC detects, the CSIRT decides. The SOC turns events into triaged alerts and escalations; the CSIRT holds the authority to declare, contain, coordinate and close incidents.
• Merging is a staffing decision, separating is an authority decision. Small teams merge because the same people do both; large ones separate because incident authority must reach legal, executives and regulators.
• The declaration line is the interface. Write down who may declare an incident, at which severity the CSIRT takes over, and what the SOC hands across.
• Outsourcing detection does not outsource authority. With MDR, the provider may contain within agreed limits, but declaring incidents, notifying regulators and accepting business impact stay with you.
• NIS2 uses "CSIRT" for national teams. Your internal team reports to the national CSIRT or competent authority within 24 and 72 hours, so the internal owner of those clocks must be named.

The short answer

You need both functions, but not necessarily two teams. Every organisation needs someone watching for adverse events (the SOC function) and someone with authority to run incidents (the CSIRT function). The FIRST CSIRT Services Framework treats event monitoring and analysis as one of the CSIRT's own service areas, noting that in larger organisations it "is sometimes fully or partially assigned to a Security Operations Center (SOC)", and that the interface between SOC and CSIRT is crucial. In practice: under about ten security staff, run one team with an incident manager rota; with a 24x7 SOC and multiple business units or jurisdictions, run a separate CSIRT, or at least a separate incident management role with its own authority. If detection is outsourced, keep a small internal CSIRT function that owns declaration, decisions and notification.

Mandates side by side

In CSF 2.0 the hinge is DE.AE-08, "Incidents are declared when adverse events meet the defined incident criteria", followed by RS.MA-04, "Incidents are escalated or elevated as needed". Whoever performs those two outcomes in your organisation sits on the boundary, and that boundary must be written down. NIST SP 800-61 Rev 3 now frames incident response as part of CSF 2.0 risk management, which supports treating detection and response as one lifecycle with two owners rather than two separate programmes.

Authority: who may do what

The Building a CSIRT Guide explains full, shared and advisory authority for the CSIRT itself. The comparison question is how authority is split between the two functions. A practical split, expressed as a decision table:

Treat the severity numbers as placeholders for your own scale; see the Incident Severity Classification Matrix Template. Three rules keep the split working:

• Authority follows the incident, not the team: once declared above the threshold, the incident manager directs SOC analysts on that incident, even if they report to a different manager.
• Pre-approval beats escalation: every containment action the SOC needs at night should be pre-approved in a runbook, with a named owner for exceptions.
• One override: a single named executive can reverse a containment decision, and that reversal is logged with the reason.

For the role that runs incidents, see the Incident Commander Role Guide; for a ready-made responsibility matrix, see the Incident Response RACI Template.

Operating model 1: merged SOC and CSIRT

Threat model: fast-moving incidents in a small or mid-sized organisation, where the biggest risk is delay between noticing and acting.

Architecture in words: one security operations team handles monitoring, triage and incident handling. A rota of senior staff carries the incident manager role; when a severity threshold is met, the on-call incident manager takes command and the rest of the team works the incident. Legal, communications and IT contacts are named and on call through the incident manager.

Strengths: no handoff delay, shared context, lower headcount, and analysts gain incident experience.

Failure modes:

• Queue starvation: a major incident pulls everyone in and the alert queue goes unwatched, so a second intrusion or the attacker's next move is missed.
• Authority by seniority: nobody is formally the decision maker, so decisions default to whoever is loudest.
• Analyst burnout: the same people carry shifts and long incidents.

Controls: a rule that at least one analyst stays on the queue during any major incident, a written incident manager rota separate from the shift rota, and a retainer for surge. See Internal CSIRT vs IR Retainer.

Operating model 2: separate SOC and CSIRT

Threat model: large, multi-jurisdiction incidents where the hard problems are coordination, legal exposure and business decisions rather than detection.

Architecture in words: a 24x7 SOC, often tiered, reports to a security operations manager. A CSIRT of incident managers, handlers, forensic analysts and a threat intelligence liaison reports to the CISO or head of incident response. The SOC escalates through a defined declaration process; the CSIRT takes ownership, pulls SOC analysts into the incident as needed, and runs coordination with legal, communications and executives. Detection engineering may sit with either, and must receive CSIRT lessons learned.

Strengths: clear incident authority, depth in forensics and coordination, a SOC that keeps watching during major incidents, and a CSIRT that can face regulators and peers.

Failure modes:

• Handoff loss: the CSIRT re-does the SOC's triage because the escalation lacks evidence and context.
• Escalation reluctance: the SOC holds incidents too long to avoid "bothering" the CSIRT, or escalates everything to avoid blame.
• Two truths: the SOC case and the CSIRT incident record diverge.
• Feedback gap: CSIRT findings never become new detections.

Controls: one case record that moves across the boundary, a handoff checklist (below), a joint review of every escalation that was declined or downgraded, and a standing slot where CSIRT lessons turn into detection backlog items.

Operating model 3: MDR or outsourced SOC plus internal CSIRT

Threat model: an organisation that cannot staff 24x7 detection but still carries full legal and regulatory responsibility for its incidents.

Architecture in words: an MDR or SOC-as-a-service provider monitors telemetry, triages alerts and takes pre-agreed containment actions in your tenant. A small internal CSIRT function, sometimes one incident manager role on rota plus named contacts, receives provider escalations, declares incidents, makes business decisions and owns notification. An IR retainer adds forensic surge.

Strengths: 24x7 detection without building a shift team; internal authority stays with people who know the business.

Failure modes:

• Nobody answers the phone: the provider escalates at night to a shared mailbox.
• Containment limits unclear: the provider either cannot act when needed, or acts on a production system without warning.
• Clock ownership missing: the 24 hour regulatory clock starts on awareness, and nobody internally owns the decision that a significant incident has occurred.

Controls: a contract annex listing provider-permitted actions by asset class, a named internal on-call with a backup, escalation tests each quarter, and provider access governed as privileged third-party identities. See the MDR Guide and the Co-Managed SOC and SOC-as-a-Service Guide.

Staffing and escalation

The bands are judgement guides, not thresholds from a standard. MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center makes the same point from the SOC side: structure and functions should follow the organisation's mission context. For how analyst and engineering roles divide inside the SOC, see SOC Analyst vs Security Engineer.

Escalation criteria that work across all three models:

1. Confirmed malicious activity on a privileged account, service account or identity provider.
2. Evidence of data access or exfiltration involving personal or regulated data.
3. Impact on a service listed as critical or in scope of NIS2, DORA or sector rules.
4. More than one host or tenant affected by the same activity.
5. Any ransomware indicator, extortion message or media enquiry.
6. The SOC cannot contain within its runbook authority or within an agreed time.

Handoff artefacts

The SOC to CSIRT handoff should carry everything the incident manager needs to decide in minutes, without re-running triage. A minimum escalation package:

The return path matters too: at closure, the CSIRT hands back a post-incident report with detection gaps, new indicators and runbook changes, and the SOC confirms which detections were added. See the Alert Triage Guide for the triage stage that feeds this package.

NIS2 and the word CSIRT

Under Directive (EU) 2022/2555, Article 10 requires each Member State to designate or establish one or more CSIRTs, and Article 11(3) gives them tasks that include monitoring and analysing threats and incidents, issuing early warnings and alerts, responding to incidents and assisting entities, collecting forensic data, scanning entities' systems on request, and coordinated vulnerability disclosure. These are national teams. For an essential or important entity, the obligations land on the organisation itself: Article 21(2)(b) lists "incident handling" among minimum risk-management measures, Article 20 requires management bodies to approve and oversee those measures, and Article 23(4) sets an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after the notification, sent to the CSIRT or, where applicable, the competent authority.

For the operating model, that means:

• Name the clock owner: the internal CSIRT or incident manager decides when an incident is significant and starts the 24 hour clock, not the SOC or the MDR provider.
• Design the handoff for the regulator: the escalation package above is the raw material for the early warning and the 72 hour notification.
• Know your national CSIRT: record the national CSIRT and competent authority contacts for each Member State you operate in; national transposition differs, so check the relevant country page from the NIS2 Directive Guide.

Changes to NIS2 have been proposed; see the NIS2 Amending Directive Proposal 2026 page for status before relying on these timelines in a plan.

Where identity fits

Identity actions are the most common containment step and the most common source of authority disputes: revoking sessions, disabling accounts, rotating API keys and certificates. Decide in advance which identity actions the SOC may take alone (standard user accounts), which need the CSIRT (privileged and service accounts, production secrets), and which need the system owner. Give the CSIRT pre-approved break-glass access to the identity provider and secrets manager, and include non-human identities in the handoff package. See the Identity Incident Response Playbook.

Worked scenario

A 6,000-person logistics company in two EU Member States runs an in-house SOC in business hours with an MDR provider overnight, and has no formal CSIRT. At 02:10 the provider sees an unfamiliar cloud API key listing storage buckets, revokes a related user session, and emails the security mailbox.

1. Nobody reads the email until 08:30. The SOC lead treats it as an alert, not an incident, and spends the morning on triage.
2. At 13:00 the team finds the key belongs to a service account used by a supplier integration and that a bucket with customer delivery data was read.
3. Nobody is sure who may disable the service account, because it supports live shipments. The CIO is consulted and approves at 15:00.
4. Legal asks when the company "became aware"; the honest answer is 02:10, and the 24 hour early warning window is already half used.

After review, the company creates an incident manager rota of four senior staff with written authority over service accounts and production secrets, adds an MDR contract annex requiring phone escalation to the on-call incident manager for anything touching non-human identities or regulated data, and adopts the escalation package as the template for its NIS2 early warning. Six months later a similar event is declared within 40 minutes, the key is rotated within the hour, and the early warning is filed the same morning.

Detection and measurement

• Log: every escalation with time raised, time accepted, severity proposed and assigned, and outcome (declared, downgraded, returned); every incident decision with owner and timestamp.
• Metric 1, escalation acceptance time: minutes from SOC escalation to an incident manager accepting ownership.
• Metric 2, declaration lag: time from first related alert to incident declaration.
• Metric 3, handoff completeness: share of escalations with every artefact in the package.
• Metric 4, regulatory clock compliance: share of reportable incidents where the early warning and notification met their deadlines.
• Metric 5, queue coverage during incidents: share of major incidents where the alert queue stayed within its triage target.
• Metric 6, lessons to detections: share of post-incident detection gaps that became live detections within 30 days.

For SOC-wide metrics, see the Security Operations Metrics Guide.

Framework mapping

Common failure patterns

• No declaration criteria: the SOC decides case by case whether something is an incident, so similar events are handled very differently.
• Authority written for people, not roles: the CISO is the only person allowed to approve containment, and is on a plane.
• The whole team on one incident: the queue goes dark during a major incident in a merged model.
• Provider escalation to a mailbox: overnight MDR escalations wait for business hours.
• Two case systems: SOC tickets and CSIRT records diverge, and the regulator gets a timeline nobody can reconcile.
• Service accounts in limbo: nobody may disable a production service account, so a compromised key stays live for hours.

Practitioner checklist

• Decide the model (merged, separate, MDR plus internal CSIRT) and record why.
• Write declaration criteria and the severity at which the CSIRT takes ownership.
• Publish an authority table for containment actions by role, including identity actions.
• Name an incident manager rota with backups, separate from the SOC shift rota.
• Adopt one case record that moves from SOC alert to CSIRT incident.
• Use a standard escalation package and check its completeness monthly.
• Put provider-permitted actions and phone escalation in the MDR contract.
• Name the owner of NIS2 or sector reporting clocks and test the path to the national CSIRT.
• Turn every post-incident detection gap into a tracked detection backlog item.
• Exercise the handoff at least twice a year, including out of hours.

Standards and references

• FIRST: CSIRT Services Framework Version 2.1
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• CMU SEI: Organizational Models for Computer Security Incident Response Teams
• NCSC: Incident management

Related NHI Mgmt Group resources: Building a CSIRT Guide, Building a SOC from Scratch Guide, Internal CSIRT vs IR Retainer, FIRST CSIRT Services Framework Guide, MDR vs MSSP.