Operate Sophos XDR Cases and Detection Rules

Sophos XDR groups Detections and affected entities into Cases that can be investigated. A Case is not an automatically resolved incident, but the shared workspace for evidence, ownership and Response.

The existing procedures in this article describe case and Detection Rule operations in Threat Analysis Center, the still-available Classic view of Security Operations. The separate Security Operations section explains current MDR ownership and status boundaries. Before making a change, check which view your tenant uses. Security Operations also offers Cases, Detections and Detectors; this does not establish that the same status values, roles, deletion periods or suppression rules apply there. In particular, Detectors is not equated with the Classic Detection Rules described below.

In Classic, Cases require EDR, XDR or MDR. Sophos automatically creates a Case for a High-Risk Detection unless it is already included in a suitable Case on the same day. Later Detections of the same type can be added.

A Sophos-managed Case based on MDR Detections is investigated by the MDR team. A Self-managed Case from XDR Detections remains the customer’s responsibility and is assigned to an administrator. Sophos creates it, but does not investigate it automatically.

This ownership boundary also applies to NDR signals and authorised NDR test detections: the NDR source does not automatically transfer a Self-managed XDR Case to Sophos MDR. The customer administrator remains the owner until the Case is closed according to the organisation’s own process. Only a Case identified as Sophos-managed and based on MDR Detections belongs to the MDR team. The NDR test detection runbook explains how to correlate a test detection unambiguously and clean it up.

Detection, Alert and Case in Classic

Several Detections can belong to the same attack chain. Conversely, one notable Detection may already justify an investigation.

For Self-managed Cases, New, Investigating, On Hold, and Resolved form the complete status flow: newly created, under active investigation, temporarily paused, or closed. Sophos-managed Cases instead use Investigating, Action required, and Resolved. Action required means the customer must take action; Sophos notifies the configured contacts.

Work on a Case in Classic

Start at Threat Analysis Center > Cases. Open an automatically generated Self-managed Case using its Case ID. On Overview, use the menu beside the Case name to set the severity. Change the status from New to Investigating, then select the responsible administrator under Owner. If the administrator is missing, add them there with Add user. The Owner can also be assigned later.

There are two officially documented ways to create a Self-managed Case manually:

• Under Threat Analysis Center > Cases > Create case > Self-managed case, enter a name and description, select Severity, status New, and optionally an Assignee, then save with Create. Under Threat Analysis Center > Detections, select the matches and use Actions > Add to Case.
• Alternatively, first select the matches under Threat Analysis Center > Detections and choose Actions > Create Case. Add later Detections with Actions > Add to Case.

Manually created Cases can contain Sophos XDR Detections only, not MDR or Managed Risk Detections. Sophos recommends using only alphanumeric characters, spaces, and basic punctuation in the Case name because APIs can interpret special characters as syntax.

For the investigation itself:

1. Read the summary, severity and timeline.
2. Check affected devices, users, processes, IPs and files.
3. Assess MITRE ATT&CK techniques and the Detection source.
4. Use Threat Graph, Live Discover and available Enrichments.
5. Document containment such as isolation or Live Response.
6. Record the cause, scope and closure decision.

For a Self-managed Case, keep the investigation notes on the Notebook tab. This preserves the evidence and decision trail directly on the Case.

AI-generated summaries can accelerate triage, but must be checked against raw data and the timeline.

Detection Rules

The following rules apply to the Classic view under Threat Analysis Center > Detection rules, not to Security Operations in general. Detection Rules can currently only suppress unwanted Detections and require a Super Admin. A rule prevents a matching Detection from appearing in the Detection list and from creating a Self-managed XDR Case. It cannot suppress MDR Cases.

Create a rule from an existing Detection: go to Threat Analysis Center > Detections, open the three-dot menu beside the Detection name, and select Add detection rule. Enter a name and description under Rule Details; the rule is enabled by default. Suppress is currently the only option under Actions. Under Conditions, select the characteristics of the existing match that should trigger the rule, then select Save. A tenant can have no more than 25 Detection Rules.

Before saving the default-enabled rule, document its name, purpose, data source, expected frequency, Owner, and review date. Conditions should identify only the confirmed legitimate trigger, not merely a severity or broadly scoped process characteristic.

A new rule can take up to 20 minutes and applies only to Detections created after the rule. Conditions are case-sensitive: Windows and windows can be treated differently.

Manage existing rules under Threat Analysis Center > Detection rules. A rule can be enabled, disabled, duplicated, or deleted, but not edited directly. To change it, duplicate and adjust it from the three-dot menu, then disable or remove the original after controlled replacement.

Control Suppression

Suppression reduces known, expected matches. It is not cleanup and must not hide genuine activity. Every Suppression requires:

• a precise condition rather than a broad pattern,
• a documented legitimate trigger,
• an owner and review date,
• review of Detections already suppressed.

A quiet console is not a sign of quality if rules are suppressed too broadly.

To verify the result, go to Threat Analysis Center > Detections > Show filters. Under Detection Visibility, clear Hide Suppressed Detections and select Apply. This shows what a rule actually matches. Because rules don’t apply retroactively, this view is also a better basis for the next review than simply counting fewer visible matches.

Security Operations: Cases and MDR responsibility

This section applies to Security Operations, not to the Classic statuses and rules above. Under Security Operations > Cases, clicking the Case name first opens the summary. Use the New Tab icon to reach the full details page. It offers Overview, Evidence, Response, History and Enrichment. Comments can be read in the summary but added only on the full details page.

Decide Managed By before confirming

For current MDR Cases, Managed By determines who manages the Case: Self means customer responsibility; Sophos MDR means management by the MDR team. Assignee, by contrast, identifies the user or group for the next action. Changing Assignee does not transfer Case ownership.

On the full details page, select the offered responsibility under Manage Case > Managed By and confirm only after the check above. Then verify the displayed value. Self is selectable only for MDR Case types Investigation and Other; Threat Hunt, Health Check and Incident are Sophos-managed. Customers do not create Incidents. For manual creation, Managed By is determined during creation. For Cases generated automatically from Sophos rules, it must be set before using the Manage Case controls. For Cases from customer rules, it is automatically Self.

Your own team investigates a Self-managed Case; available changes, response actions and split/merge also depend on Case type and permissions. For Sophos-managed Cases, you can read details, comment, assign to Sophos and close when a closure action is available. This does not authorise arbitrary status changes, editing Key Findings, adding further events or Detections as evidence, or splitting or merging the Case.

Current MDR statuses and customer actions

Depending on type, current MDR Cases use New, In Progress, Customer Action Required, Awaiting Sophos Assignment and Closed. These values are not equated with either Classic statuses or the general XDR statuses Open, Active, Awaiting Action, Suspended and Closed. Awaiting Sophos Assignment means internal assignment within the MDR team is pending; Customer Action Required instead requires the organisation to act.

When the MDR team sets a Sophos-managed Case to Customer Action Required, the inactivity counter starts. Without customer action, an email reminder follows every 24 hours; after five days of inactivity, the Case closes automatically. A comment, response action, Assignee change or new link or attachment resets the counter. This does not replace the requested substantive work: clarify questions with the MDR team rather than keeping the counter running through merely formal changes. Never perform response actions solely to reset the counter.

On the full details page, the comment icon on the right opens Comments. Enter the necessary information in Comment and select Save. @sophos notifies the MDR team. After saving, check that the comment is on the correct Case. Set up MDR contacts and response authority before an incident, not only after the first missed enquiry.

Closing also resolves the associated Detections and labels them according to the chosen verdict. MDR offers True Positive – Benign, True Positive – Malicious, Inconclusive and False Positive; with Inconclusive, the Detection label is Not Actionable. A closed Case is not technical proof of cleanup. Check the investigation outcome and outstanding customer tasks before closing.

Within 30 days after closure, a Sophos-managed MDR Case can be reopened through a comment with @sophos; for a customer-managed Case, change the status from Closed. After those 30 days, a new Case is required. This reopening limit says nothing about deletion or retention of current MDR Cases; the Classic periods stated above or below remain restricted to Classic.

Rules rather than Classic suppress-only

Under Security Operations > Rules, there are two separate types of Customization Rules: Custom detection rules generate new Detections from normalised events using an advanced search query. Detection suppression rules resolve matching Detections as suppressed when created, so they do not appear in the Detection list by default. Detectors is not the same management area as these rules.

Cases generated automatically from customer rules are customer-managed and do not trigger an automatic MDR investigation. The Classic limits of 25 rules, a Super Admin requirement, a 20-minute wait and duplication instead of editing are not transferred to this new interface. This section explains the distinctions, not a complete custom-rule creation procedure. Before suppression, still confirm the legitimate cause and assess the loss of visibility.

Closure and lessons learned in Classic

Close a Case when the scope, cause, containment, cleanup and recovery are documented. Then adjust Detection Rules, policies, exclusions and Runbooks if the investigation revealed a gap.

Close a Self-managed Case by setting its status to Resolved. It remains in the list for 30 days and Sophos then deletes it. Partner Super Admins and Enterprise Super Admins can’t close or remove Cases, so account for this role boundary before assigning the owner.

The underlying telemetry and query work are explained in Sophos XDR Data Collection and Live Discover.

Frequently asked questions

The complete current workflow under Security Operations > Rules is explained in Operating Custom Detection and Suppression Rules. It treats streaming conditions, the circuit breaker, preview limitations, and rollback separately from the Classic rules retained here.