/edr-incidents

name: "Acronis EDR Incidents"
description: >
  Endpoint Detection and Response (EDR) incident review in Acronis Cyber
  Protect Cloud: listing open incidents across customers, reading an
  incident's detections, activities and response actions, checking the
  status of a response action started in the console, and updating the
  investigation state or adding a comment (off by default, write tier in
  Conduit). Starting response actions is not available.
when_to_use: >-
  When an MSP needs to review Acronis EDR or Cyber Protect security incidents,
  triage open incidents by severity, read what happened on an endpoint,
  check whether an isolation or other response action finished, or record an
  investigation decision. Use when: acronis incident, acronis edr, acronis
  malware detected, cyber protect incident, acronis investigation state,
  acronis isolate status, or security incident review.

Acronis EDR Incidents

Overview

Acronis EDR groups related detections on an endpoint into an incident. Each incident has a severity, a verdict, a mitigation state (was the threat stopped) and an investigation state (has a person looked at it). An MSP's job is to make sure every incident that isn't auto-mitigated gets looked at, and that the investigation state reflects reality.

Anti-triggers

• **Backup failures and missed backups** — those are alerts, not incidents.

Use `acronis-backup-health`.

Key Concepts

| Field | Values | |-------|--------| | `severity` | `LOW`, `MEDIUM`, `HIGH`, `CRITICAL` | | `verdict` | `SUSPICIOUS`, `MALICIOUS` | | `mitigation_state` | `NOT_MITIGATED`, `MITIGATED`, `AUTO_MITIGATED` | | `state` (investigation) | `NOT_STARTED`, `INVESTIGATING`, `TRIAGED`, `FALSE_POSITIVE`, `CLOSED` | | `incident_category` | Such as `MALWARE_DETECTED`, `PROCESS_DETECTED`, `URL_BLOCKED`, `MS_DEFENDER` |

`is_mitigated` is a simple true/false filter on whether the threat was stopped. `positivity` is a confidence score from 0 to 10 that you can filter with `range(min, max)`.

Workflow: Daily Incident Review

1. **Open incidents for a customer.** Call `acronis_fetch_incidents` with `customer_id`, `state: "or(NOT_STARTED,INVESTIGATING)"` and `created_at: "ge(<start date>)"`. With a partner-level API client, always pass `customer_id`; without it the call uses the API client's own tenant. 2. **Unmitigated first.** Re-run with `mitigation_state: "NOT_MITIGATED"`. Those are threats Acronis didn't stop, and they come before everything else regardless of severity. 3. **Then by severity.** `severity: "or(HIGH,CRITICAL)"` next, then the rest. 4. **Page.** Use `limit` and `cursor`. Keep every other parameter exactly the same between pages or the cursor is rejected. 5. **Read one incident.** `acronis_fetch_incident` with `path.incident_id`, `customer_id`, and `with_detections`, `with_activities` and `with_incident_actions` set to `true`. Detections say what was seen, activities say what happened on the machine, and incident actions say what was done about it. 6. **Check a response action.** If someone isolated the machine or killed a process from the console, call `acronis_fetch_response_action_status` with the incident ID and the action's `activity_id` from step 5.

Deciding the Outcome

| Situation | Typical investigation state | |-----------|-----------------------------| | Auto-mitigated known malware, nothing else on the machine | `TRIAGED`, then `CLOSED` after a quick check | | Not mitigated, or malicious verdict with unexpected activity | `INVESTIGATING`; open a PSA ticket and escalate | | Legitimate admin tool or line-of-business software flagged | `FALSE_POSITIVE`, with a comment naming the software and who confirmed it | | Same detection across many machines at once | Treat as one event; investigate the common source before closing any |

Updating the Investigation (write, off by default)

`acronis_update_investigation_state` changes an incident's investigation state, adds a comment, or links an external ticket. Body fields: `state`, `comment`, `ticket_id`, `ticket_subject`, `assignee`, `assignee_id`, and `priority` (`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`). Pass `customer_id` in `query` with a partner-level API client.

• It's **off by default**. If it isn't in the tool list, writes are turned

off for the Acronis connector; tell the operator to update the incident in the console.

• When writes are on, Conduit puts it at the **write** tier (not admin).
• Put the PSA ticket number in `ticket_id` so the incident and the ticket

point at each other.

• Never set `FALSE_POSITIVE` or `CLOSED` on an unmitigated incident without

the operator's explicit confirmation.

• Send an `Idempotency-Key` header when retrying after a network error, so a

retry doesn't add the same comment twice.

What This Connector Can't Do

Starting a response action (isolating a machine, killing a process, quarantining a file, rolling back) is **not available** through this connector. Say so, and point the operator to the incident in the Acronis console. Reading the status of an action started there is available.

Gotchas

• `incident_id` filtering on `acronis_fetch_incidents` only works for a

single customer, so pass `customer_id` with it.

• Multi-workload incidents span several machines. Pass

`with_multi_workload: true` to get the `workloads` list; without it you see one machine.

• Incidents that were merged into another are hidden unless you pass

`with_transferred: true`.

• Incident dates use `range(from, to)` and `ge(from)`, not the nanosecond

operators that alerts use.

Related Skills

• [api-patterns](../api-patterns/SKILL.md) - Headers, pagination and errors
• [tenants-and-usage](../tenants-and-usage/SKILL.md) - Find the customer tenant UUID