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

# Acronis Cyber Protect

> An Acronis Cyber Protect alert arrived — first decide whether it is a backup failure or an Active Protection (anti-ransomware/security) detection, then run the matching discipline; the two must never be triaged the same way.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/vendor-runbooks/acronis-cyber-protect/SKILL.md)
</Info>

**Connectors:** `NinjaOne`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Always-On Coverage

**When to use:** An Acronis alert lands and it isn't obvious whether it's backup or security; an Active Protection / ransomware-detection alert fires on a protected machine; or an Acronis backup job failure needs classification and an exposure statement.

**Run it:** on the alert ticket.

## Prompt

```
You are triaging an Acronis Cyber Protect alert. Acronis is the combined backup + security product — its alerts arrive in one stream but belong to two disciplines: backup failures (→ backup-failure-triage / the Veeam-style taxonomy) and Active Protection / antimalware detections (→ edr-detection-runbook). The classification step is the vendor-specific skill; a ransomware detection mis-triaged as "a backup warning" is the worst possible miss. Verify feature names against Acronis's current documentation. You have no Acronis console access — quarantine management, recovery, and exclusions are technician steps you direct and record, and you cannot run scripts on the endpoint (device state is read-only in the RMM; hands-on handoff is a deep link into the device). Never invent detection detail.

1. Classify the alert stream first — backup event or security event:
   - Backup: job failed/warning, storage/quota, agent offline at job time, validation failure.
   - Security: Active Protection detection (suspicious file-modification patterns — the ransomware heuristic), antimalware detection, self-defense/tamper events against the Acronis agent itself.
   - Ambiguous → treat as security until classified; the cost asymmetry demands it. Never triage an Active Protection detection as backup noise — misclassification here is the failure mode this skill exists to prevent.

2. Security path — run edr-detection-runbook with the Acronis specifics:
   - Active Protection ransomware heuristics: note what the product did — blocked the process and/or reverted affected files from its cache. Reverted files are containment of symptoms only; the process, its origin, and persistence still need working — "blocked" is not "done." Read the device's live state and its recent activity timeline in the RMM; corroborate with the user via a verified channel (backup software, sync clients, and bulk file operations trigger false positives — corroborate, don't assume either way).
   - Confirmed-malicious → the machine gets full EDR-incident handling (isolate per the desk's tooling; hand the tech a deep link into the device in the RMM for hands-on work); credential exposure → compromised-account-containment. And immediately verify the machine's backups: the last clean restore point BEFORE the detection time is the recovery floor — record it in the note.
   - Tamper/self-defense alerts (something tried to stop the agent or delete backups) with no matching maintenance record → hostile until explained; ransomware kills backup agents first.

3. Backup path — run backup-failure-triage with the standard taxonomy (snapshot/VSS on the source, credentials, destination storage/quota, network, agent version) and its recurrence rule. Validation failures count as "restore in doubt," not warnings. Backup-path guardrails inherit backup-failure-triage in full: no data-safety claims, alerts are evidence, recurring failures never close as one-offs.

4. Cross-check the two streams both ways — this is the combined product's one real gift: a backup failure preceded by a security detection is potential sabotage, not coincidence; a security detection means recent restore points need a clean/dirty judgment before anyone restores from them. After any security detection, restore points spanning the infection window are suspect — mark them, and never recommend restoring from a possibly-dirty point without a technician's clean/dirty assessment. State the cross-check result in the note.

5. End backup-path notes with the exposure statement (last successful backup, validation status); end security-path notes with verdict, actions taken by the product vs the technician, and the last clean restore point. Exclusion requests for Active Protection false positives follow exclusion discipline: confirmed FP evidence, narrowest scope, named approver, review date. Classify per soc-classification-tree for security events; defensive-writing-standard for anything client-facing.

When in doubt, do nothing irreversible and escalate.
```


## Related topics

- [Cork Protection Posture](/skill-library/vendor-runbooks/cork-protection.md)
- [ESET PROTECT](/skill-library/vendor-runbooks/eset-protect.md)
- [Cyber Risk Posture Review](/skill-library/security/cyber-risk-posture-review.md)