> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raidenhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cases and alerts in RAIDEN: triage and investigation

> Learn how RAIDEN groups individual detections into investigation cases and how to triage, investigate, and close threats effectively.

RAIDEN surfaces threats as two distinct concepts: alerts, which are individual detection events, and cases, which are grouped investigations built from related alerts. Understanding the difference helps you triage faster and avoid working detections in isolation.

## Cases vs. alerts

| Term      | What it is                                                                                            |
| --------- | ----------------------------------------------------------------------------------------------------- |
| **Alert** | A single detection event — for example, one suspicious login from an unusual location                 |
| **Case**  | A group of related alerts for the same user, treated as one investigation with an AI-generated report |

Start with **Cases**, not individual alerts. Each case includes an AI-generated investigation report that summarises all the evidence. Read that report before drilling into individual alerts — it gives you the full picture in seconds.

## Alert severity levels

Every alert carries a severity level that tells you how urgently it needs attention.

| Severity     | Meaning                                | When to act      |
| ------------ | -------------------------------------- | ---------------- |
| **Critical** | Active or confirmed account compromise | Immediately      |
| **High**     | Strong indicators of attack            | Today            |
| **Medium**   | Suspicious but unconfirmed             | Within 48 hours  |
| **Low**      | Unusual activity, low risk             | Monitor          |
| **Info**     | Contextual data, no direct risk        | No action needed |

<Tip>
  When your alert volume is high, filter by **Critical** and **High** first. Work cases rather than individual alerts — the case report gives you the consolidated picture with context.
</Tip>

## Responding to a real threat

When a case looks like a genuine threat, work through it in this order:

<Steps>
  <Step title="Read the AI-generated investigation report">
    Open the case and read the report at the top. It summarises all related alerts and evidence in plain language, written for IT admins rather than security analysts.
  </Step>

  <Step title="Take action from the Remediation panel">
    Use the **RAIDEN Actions** buttons in the Remediation panel to contain the threat directly — revoke sessions, disable the account, or delete malicious inbox rules — without opening a separate admin portal. See [Response Actions](/response-actions) for details on each action.
  </Step>

  <Step title="Document what you did">
    Use **Case Notes** to record what actions you took and when. This creates an audit trail and helps teammates who pick up the case later.
  </Step>

  <Step title="Close the case with a disposition">
    Once the threat is resolved, close the case and record a **disposition** — your verdict on what the activity was (True Positive, True Positive — Remediated, False Positive, and so on). See [Case statuses](#case-statuses) for the full list. If you contained a real attack, close it as **True Positive — Remediated**, not False Positive.
  </Step>
</Steps>

## Case statuses

A case is either open (being investigated) or closed. When you close a case, you record a **disposition** — your verdict on what the activity actually was. The disposition is what tells RAIDEN whether the detection was right, and it drives downstream behaviour such as suppression and (for MSSP fleets) cross-tenant threat-intel sharing.

| Disposition                    | When to use it                                                                                                                               |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **True Positive**              | A real threat that needs remediation                                                                                                         |
| **True Positive — Remediated** | A real threat that has already been contained (sessions revoked, account disabled, etc.) — never mark a contained attack as a false positive |
| **True Positive — Benign**     | Real but authorised activity, e.g. a red-team exercise or an approved admin action                                                           |
| **False Positive**             | The detection fired incorrectly on legitimate activity                                                                                       |
| **Benign**                     | The activity was legitimate and expected                                                                                                     |
| **Inconclusive**               | Not enough evidence to reach a verdict                                                                                                       |
| **Monitoring Timeout**         | No further suspicious activity was observed within the monitoring window, so the case was closed automatically                               |

<Note>
  RAIDEN's AI investigation can auto-close a case it is confident is a false positive or benign. It will **not** auto-close a case it has verdicted as a real threat — that case stays open until the threat is remediated or the monitoring window times out, so a genuine attack is never silently closed.
</Note>

## Marking a false positive

If an alert fired on known-safe activity, mark it as a false positive and suppress future alerts for that entity.

<Steps>
  <Step title="Open the alert">
    Navigate to the alert inside the case.
  </Step>

  <Step title="Change the status to False Positive">
    Set the alert status to **False Positive**.
  </Step>

  <Step title="Apply suppression and save">
    Use the suppression options to stop future alerts for the same IP address, application, or user. Click **Save** to apply.
  </Step>
</Steps>

## Suppression options

When marking a false positive, you can suppress future alerts by:

* **IP address** — RAIDEN will not alert on that detection rule when activity originates from this IP
* **Application** — suppresses the rule for a specific application
* **User** — suppresses the rule for a specific user account

<Note>
  Suppression applies per detection rule. It prevents that specific rule from firing against the suppressed entity — other rules continue to run normally.
</Note>

## Blast Radius tab

Every case includes a **Blast Radius** tab showing how far the threat has spread across your environment. For each case you will see:

* **Targeted** — how many users in this tenant received the same phishing or attack indicators
* **Clicked** — how many users interacted with the threat (opened a link, submitted credentials, etc.)
* **Compromised** — how many users have confirmed findings from the same campaign

MSSP partners also see a cross-tenant count: how many other tenants in their managed fleet have encountered the same campaign indicators. This context helps prioritise response — a campaign active across 8 of your 20 customers warrants a different response posture than an isolated incident.

## User Context: live remediation status

The **User Context** tab on a case shows the current state of the affected user's account, including a **via Graph** pill that reflects real-time remediation confirmation from Microsoft Graph:

* **Green (via Graph)** — RAIDEN has confirmed that the user's password was reset and all active sessions have been invalidated. The remediation is complete.
* **Amber (via Graph)** — The session window is still open. Even if a password reset occurred in the audit log, RAIDEN cannot confirm full session invalidation — a revoke session action is recommended.

This is more reliable than audit-log-only checks, which can miss self-service portal resets and Conditional Access session revokes.

## Case Notes

Every case has a **Case Notes** section where you can add free-text entries. Use it to:

* Record what actions you took and the timestamps
* Note context that is not visible in the alert data
* Leave handover information for teammates

Case Notes are visible to all team members with access to the case.
