
What to do when antivirus or EDR raises an alert
A practical triage guide for small IT teams and managed IT staff: how to read the alert, when to isolate, how to tell a false positive from the start of an incident, and how to record the outcome.
Reviewed by the ITRS security team · Last updated
Read the alert: detection vs prevention
Start by working out what the tool actually did. 'Blocked', 'quarantined' or 'prevented' means it stopped something, which is good but doesn't tell you how the file got there or whether anything else ran. 'Detected' or 'suspicious activity' with no action taken means something may still be running. Note the device, user, time, file or process name, file path, hash, and the detection name.
Pay attention to what kind of behaviour was flagged. A single known-bad file in a Downloads folder is very different from credential dumping, ransomware-like file encryption, a new remote-access tool, or PowerShell launched by Word.
Isolate the device?
| Isolate now | Usually OK to investigate first |
|---|---|
Alert mentions ransomware, credential theft (e.g. LSASS access), or lateral movement | A single file blocked on download, with no execution |
Several devices alerting at once | Known potentially unwanted app (adware, toolbar) |
Remote-access or tunnelling tools nobody installed | A recognized internal tool flagged before, already reviewed |
Alert on a server or admin workstation | Low-severity alert on a test machine |
You can't tell what happened | — |
Check for related activity
- Process tree: what launched the flagged process, and what did it launch? An Office document or browser spawning a script is a red flag.
- How did the file arrive: email attachment, download, USB, or network share?
- Network connections from the device around the alert time.
- Same file hash or detection name on other devices.
- The user's sign-in activity in Microsoft 365 or your identity provider: anything unusual around the same time?
- New local admin accounts, services or scheduled tasks.
False positive or real?
False positives happen, especially with in-house scripts, older line-of-business software and admin tools. Before you dismiss an alert, confirm the file is what you think it is (signed by the expected publisher, expected path, hash matches a known-good copy), and that the activity matches something someone actually did. Ask the user. If you add an exclusion, make it as narrow as possible (a specific hash or path, not a whole folder) and record why.
If you can't explain it, treat it as real. NIST SP 800-61 Rev. 3 frames this as part of the 'detect' and 'respond' functions: an adverse event becomes an incident when analysis indicates it is one, and that analysis should be documented.
When to escalate
Escalate to your security provider or incident responder, and tell management, when the alert involves credential theft, ransomware behaviour, multiple devices, servers or admin accounts; when blocked malware turns out to have executed earlier; when you find persistence or remote-access tools; or when sensitive data may be involved. Our 24/7 incident line is (289) 582-9930.
Don't reimage the device before escalating unless the responder agrees. A rebuild solves the device problem and erases the evidence of how far the attacker got.
Record the outcome
- What triggered, when, on which device and user.
- What you checked and what you found.
- Decision: false positive, contained malware, or incident, and why.
- Actions taken (isolation, removal, password resets, exclusions).
- Lessons: was there a control gap, such as missing patches, local admin rights or email filtering?
- The Canadian Centre for Cyber Security's baseline controls for small and medium organizations make endpoint protection and an incident response plan core controls; your alert records show the controls actually work.
Common questions
You have less visibility, so lean towards isolating and escalating when an alert is unclear. Consider adding EDR or a managed detection service; the alert you're reading may be the only warning you get.
Keep them with your incident records. If an alert turns out to involve personal information, PIPEDA breach records must be kept for 24 months.
Related reading.
- PageUnder attack? Start hereIf something is wrong right now, this page tells you what to do in the next few minutes, what to avoid, and which step-by-step guide fits what you are seeing.
- ServiceManaged Detection and Response (MDR) Services and Cybersecurity MonitoringMDR services, short for managed detection and response, are a security service in which a team monitors your endpoints, servers, network and Microsoft 365 sign-ins…
- Article24/7 MDR Services: A Guide to Managed Threat Detection and Monitoring for GTA BusinessesWhat 24/7 MDR services and managed threat detection actually do, how MDR differs from antivirus, and what to look for when choosing a provider: for Toronto & GTA…
- ServiceCybersecurity Services in Toronto: Managed Security for GTA BusinessesWe run the day-to-day security of GTA businesses: account and email protection, endpoint detection, firewall management, alert review and incident response, with a 24/7…

Under attack right now?
Call before you reset passwords, wipe a laptop or pay anyone. A responder will help you contain the incident without destroying the evidence you will need later.
