It's 2 a.m. Ransomware is spreading across production. Security wants to freeze the environment to preserve forensic evidence. IT wants to wipe and restore from backup before the SLA clock runs out. Same incident, same systems, two teams pulling in opposite directions.
The conflict is structural. Security conducts investigations using Security Information and Event Management (SIEM) and Endpoint Detection and Response (EDR) platforms, classifying events by threat-actor behavior and data-exposure risk.
IT operations run parallel investigations through IT Service Management (ITSM) and monitoring tools, classifying the same events by service disruption and service-level agreement (SLA) impact. The pattern is hard to miss: extended breach timelines often come from two teams working the same incident from incompatible starting points.
The instinct most organizations follow is to throw better tools at each silo, a faster SIEM for security, a more capable ITSM platform for IT. The investment improves each team's individual throughput and leaves the coordination gap exactly where it was. The real bottleneck is the lack of coordination between the two teams. Before we get into what a shared lifecycle looks like in practice, let's level-set on the terms.
What is incident management?
Incident management is the practice of detecting, triaging, responding to, and recovering from events that threaten an organization's systems, data, or services. It covers the full coordination effort. Who gets paged, how severity is assessed, what containment actions are authorized, and how teams document what happened afterward all fall within scope.
The definition has shifted substantially. When NIST finalized Special Publication 800-61 Revision 3 in April 2025, it retired the legacy four-phase incident response model, remapped the lifecycle to CSF 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover), and expanded responsibility beyond the Security Operations Center (SOC) to include legal teams, communications, business stakeholders, and third parties.
NIST treats incident management as an ongoing organizational capability integrated into business processes, with metrics and continual improvement used to manage it over time.
Recent public reporting on data compromises and the exploitation of zero-days points to sustained pressure on response and reporting workflows. Separate incident programs make it harder to meet regulatory timelines, such as GDPR's 72-hour notification window, when incident volume is high. The gap between incident definitions and day-to-day response is where many programs break down.
Security incidents and IT incidents: where they differ and where they overlap
The two disciplines start from fundamentally different definitions of what an incident is, and those definitions create conflicts during active response. Here's how they compare side by side:
The conflict shows up most clearly during response. Restoring service fast often means wiping systems and rebuilding from backup, which can destroy the forensic evidence security needs for regulatory reporting or legal action. Major incident response guidance emphasizes preserving evidence before restoration, while service owners are measured by time to restore.
Tool sprawl makes the overlap harder to manage. IDC's Voice of Security 2025 found that 54.8% of security teams manage 20 to 49 security tools, and IT operations teams run their own parallel stack. Ransomware, identity compromise, and cloud account takeovers force both frameworks to activate simultaneously, and coordination often fails during that overlap.
A lifecycle that works for both teams has to hold up across four phases, from the quiet work that happens before an incident to the review that closes it out. Here's how each phase looks when security and IT run it together.
1. Preparation
Security teams develop playbooks for threat categories, configure SIEM correlation rules, and pre-authorize containment actions.
IT operations teams define service severity tiers, build on-call rotations, and maintain runbook coverage for common failure scenarios. Teams align severity taxonomies, establish pre-authorized cross-team containment runbooks, and configure shared tooling here.
2. Detection and triage
A Elastic Security correlation search fires a credential-access detection. Your team enriches the alert with asset data, threat intelligence, reputation checks, and correlated CrowdStrike Falcon process trees. Your team then uses a workflow to create an incident ticket in the team's ITSM/SIR system, page the SOC on-call analyst via PagerDuty, and create a dedicated Slack incident channel.
The failure mode appears when detection runs in parallel without coordination. Security opens a SIR ticket on a compromised host; IT opens a separate ITSM ticket for the same host, causing network degradation, and two investigations run against the same system with no shared context.
3. Investigation, containment, and eradication
Security maps attacker TTPs using MITRE ATT&CK and determines lateral movement scope. IT correlates logs across affected services and maps business impact using the Configuration Management Database (CMDB).
When a CrowdStrike process tree reveals a suspicious parent-child chain on a production database server, the security analyst proposes network containment, but the IT operations engineer needs five minutes to promote a replica before isolation can proceed. If security executes containment without that coordination, the isolation causes a production outage more severe than the original incident.
Eradication runs on parallel tracks. Security removes persistence mechanisms and sweeps endpoints for Indicators of Compromise (IOC). IT rebuilds affected systems from validated baselines. Both teams return systems to production only after the IOC sweep and the infrastructure rebuild are complete.
4. Recovery and post-incident review
Recovery follows a gated pattern. IT restores affected systems to a staging environment and runs integration tests. Security runs detection searches against the staged host and confirms EDR agent coverage. Both teams sign off on the incident record before production promotion proceeds.
Post-incident review produces artifacts that feed both teams. Updated detection rules go to security engineering. Infrastructure improvement tickets go to IT operations. When reviews run separately, security identifies an unpatched vulnerability as the initial access vector but stores the finding in a security-only system, and the IT patching team never receives it.
What it takes to manage incidents across both teams
The failure modes above are not hypothetical. Teams that have actually closed the gap between security and IT didn't do it by buying better individual tools. They did it through shared accountability, coordinated communications, cross-training, and shared dashboards. Three coordination gaps tend to show up first, and they're worth naming before you design around them:
Severity mismatch: Security severity draws on CVSS scores, threat activity, and data classification. IT severity derives from availability impact, SLA tier, and business service criticality. A critical CVSS vulnerability on a non-internet-facing system may rightly be a standard priority in IT, while a low-CVSS flaw actively exploited against a tier-one service may warrant a critical response, with nothing in the score to signal it. Alert volume already leaves many SOC teams behind in their own queues, and cross-team escalations get deprioritized when both sides are underwater.
Unclear authority: Guidance on incident response consistently calls for clearly defined authority, roles, and escalation paths. Incident response plans defined notification paths but stopped short of assigning decision authority until an incident reached a material risk threshold. When security wants to isolate a host and IT owns the system's availability SLA, hesitation during active incidents translates directly to extended dwell time.
Parallel work as risk: Teams often discover overlap only after parallel work has already started. In incident response, parallel work is an active risk, with two teams potentially taking conflicting remediation actions against the same system.
Closing these gaps takes more than process alignment. It requires a shared operating layer where severity definitions, authority boundaries, and remediation actions are visible to both teams in real time, so that coordination becomes the default rather than an exception negotiated mid-incident.
One platform for security and IT incident management
Teams that need security governance, IT service mechanics, and cross-team coordination in one place need an intelligent workflow platform built for both sides of incident management. Governance requirements include audit trails and evidence-chain documentation to satisfy regulatory reporting obligations (e.g., GDPR, HIPAA, PCI DSS). ITSM requirements include SLA tracking, on-call routing integration, and service restoration workflows.
Teams also need a coordination layer that connects to both security and IT toolchains via APIs, because no organization is replacing its SIEM, EDR, ITSM, and monitoring stack with a single one.
Through an intelligent workflow platform, teams connect those systems without replacing the stack they already run. Tines sees this pattern across its customer base, with the average customer connecting to 68 different tools through the platform. No prebuilt connector library limits what you can connect to. No developer dependency blocks what your team can build.
Connecting the toolchain is only half the equation, though, because what runs on top of it determines whether incidents actually move forward. The execution model matters too. Some incident response steps are predictable and auditable, such as alert enrichment, ticket creation, and IOC lookups. Those steps need deterministic automation. Other steps require judgment: triaging an ambiguous alert, classifying severity when the signal is mixed, deciding whether a containment action is warranted.
Those steps need either AI-assisted analysis with human oversight or direct analyst decisions. Teams need deterministic, agent-based, and human-led execution, or they end up compromising in one direction.
How Tines supports both security and IT incident management
The Tines platform is built for exactly this pattern, letting teams operate across the full set of execution modes on a single intelligent workflow surface. Every step runs under the same governance layer, with audit trails, role-based access, change control, and test/live credential separation built into the architecture.
Stories handle predictable steps, while Agents handle ambiguous triage. For approval and sign-off, teams rely on Tines Pages, web pages connected to your stories that end users can provide input to and view output from, for custom forms and internal apps. Tines Cases then handles built-in ticketing and incident management, closing the loop between automated workflows and the human decisions that drive them.
Taken together, these capabilities address the core problem the article started with. Incident management breaks down when security and IT coordinate through disconnected systems, conflicting priorities, and unclear authority. A shared lifecycle fixes part of that problem, but teams still need a common operating layer where deterministic automation, AI-assisted triage, and governed human sign-off can happen together.
That's the role Tines plays. Organizations build intelligent security and IT workflows on the same platform, using it to connect security and IT systems, run deterministic, agent-based, and human-led execution, and maintain governed case management within the same operating model.
Frequently asked questions about incident management
What is the difference between an event, an alert, and an incident?
An event is any observable occurrence in a computing environment: a user login, a configuration change, a network connection. An alert is generated when a monitoring tool detects a pattern in event data that matches predefined criteria or thresholds. An incident is an escalated alert that requires investigation and response, either because it involves a violation or imminent threat of violation of security policies, acceptable use policies, or standard security practices (NIST definition) or because it disrupts a service (ITIL definition).
What changed in NIST SP 800-61 Revision 3?
NIST finalized SP 800-61 Revision 3 in April 2025, aligning incident response recommendations with the six CSF 2.0 functions as part of cybersecurity risk management activities. The revision also abandoned the dedicated incident-handler model, expanding incident-management responsibility to include legal, communications, and business stakeholders.
How does incident management differ from problem management?
Incident management focuses on restoring service or containing a threat as quickly as possible during an active event. Problem management, a separate ITIL 4 practice, focuses on identifying and addressing the root causes behind incidents to prevent recurrence. An incident ticket tracks what happened and how it was resolved. A problem record tracks why it happened and what systemic change prevents it from happening again. Post-incident review is the bridge between the two.
Can security and IT teams use the same incident management platform?
They can, and the frameworks are converging to require it. NIST SP 800-61r3 distributes incident response across all six CSF 2.0 functions, including Govern and Identify. The structural requirement is a platform that supports security governance (audit trails, evidence preservation, regulatory reporting) alongside IT service management workflows (SLA tracking, on-call routing, service restoration) without forcing either team into the other's tooling.