What is the difference between linking related cases and merging them during an investigation?

Why This Matters for Security Teams

Linking and merging may look like a workflow choice, but it changes how evidence, ownership, and reporting behave inside the case management process. When a team links related cases, each record keeps its own timeline, assignee, and disposition while still contributing to a broader incident picture. That matters when multiple analysts, queues, or business units are working the same threat from different angles. The wrong choice can flatten context, create reporting confusion, or make it harder to reconstruct what was known at each stage. Guidance in the NIST Cybersecurity Framework 2.0 supports coordinated response and traceable handling of security events, which is the practical concern here. The question is not just whether two cases are related, but whether the organisation needs a shared view without sacrificing case integrity. In practice, many security teams discover the cost of premature merging only after a parallel investigation has already lost its independent audit trail.

Linking is also safer where the same actor, malware family, or infrastructure is appearing across multiple reports but the confidence level is still evolving. Analysts can keep weakly connected threads visible without forcing a final judgment too early. Merging should be reserved for situations where the duplicate records truly represent the same operational case and where consolidating them will not erase important ownership or evidence history.

How It Works in Practice

In most investigation platforms, linking creates a relationship object or reference between cases, alerts, notes, or entities such as IP addresses, user accounts, and file hashes. The underlying records remain distinct. That means each case can still preserve its own status, timestamps, reviewer notes, and closure reason. Merging, by contrast, usually moves the content of one case into another or collapses multiple records into a single master record. That can simplify dashboards, but it also reduces visibility into how the investigation developed.

Operationally, teams usually apply linking when one of these conditions is true:

• The cases share indicators but have different owners or reporting lines.
• The evidence suggests a common campaign, but attribution is not yet confirmed.
• Separate business units need separate closure decisions.
• The SOC wants a campaign view without losing original handling records.

Use merging when the duplicates are operationally identical, the evidence set is truly the same, and preserving separate records adds no investigative value. Even then, the decision should be deliberate, because a merged case can make it harder to answer who saw what, when they saw it, and what action they took.

For teams that need consistent event handling, the NIST guidance on coordinated security outcomes is useful, but case management still depends on local process discipline. Linking is especially helpful when incidents move between triage, threat hunting, and response, because each team may need to work from the same relationship graph without inheriting another team’s assumptions. These controls tend to break down in high-volume SOC environments where analysts are incentivised to clear queues quickly, because speed pressures can turn merge decisions into a shortcut instead of an evidence-based choice.

Common Variations and Edge Cases

Tighter case consolidation often reduces dashboard noise, but it also increases the risk of losing investigative nuance, so organisations have to balance efficiency against traceability. There is no universal standard for when a related case should be linked rather than merged; current guidance suggests using the decision that best preserves evidence integrity and reporting accuracy.

Edge cases often appear when cases overlap only partially. For example, two phishing reports may share the same sender domain but involve different victims, different payloads, and different containment actions. Linking is usually the better fit because the shared infrastructure matters, but the response paths do not fully align. Similarly, a recurring threat actor may generate many cases over time. Analysts often link these into a campaign structure rather than merge them, because the timing, affected assets, and remediation steps differ.

Where identity data is involved, linking can also preserve separate user-impact records while still showing a shared source such as compromised credentials or a reused session token. That becomes important for auditability and post-incident review. Merging, on the other hand, is most defensible when duplicate alerts were opened from the same detection logic and the investigation has not diverged.

Teams should also define who is allowed to merge cases, because that action is more destructive than linking and may affect evidence handling, legal review, or metrics. The most reliable practice is a written rule: link when the relationship matters, merge only when the records are truly redundant.

Related resources from NHI Mgmt Group

• What is the difference between delegated and autonomous MCP use cases?
• What is the difference between discovering AI agents and controlling them?
• What is the difference between monitoring MCP agents and controlling them?
• What is the difference between symmetric and asymmetric encryption for IAM use cases?