A simple way to triage endpoint alerts when you’re busy, understaffed, and don’t have time for panic

If you run a small business or manage IT for one, you’ve probably had this moment:

A security tool pops up an alert.
It sounds serious.
You don’t know if it’s urgent… or just noise.

So you do what most people do:

• you ignore it (because you can’t drop everything)

• or you panic (because what if it’s ransomware?)

• or you Google it and get 12 conflicting answers

The reality is: you don’t need a SOC to make good decisions.

You just need a repeatable triage process, and the right signals inside the alert.

This guide shows you exactly how to do that.

First: what “false positive” really means

Let’s clear something up.

A false positive doesn’t always mean “the tool is wrong”.

Often, it means:

✅ The tool detected something unusual or risky
…but it turned out to be legitimate in your environment.

In small businesses, that happens constantly.

• A backup agent might spike CPU.

• An admin script might launch PowerShell.

• A legitimate installer might run from Downloads.

The point of a good alert isn’t to “be right all the time”.
It’s to reliably answer one question:

Does this need attention right now?

That’s triage, not forensic investigation.

The decision you actually need to make

Forget “is this malware?” for a second.

When you’re short on time, your job is to decide:

✅ Ignore

👀 Monitor

🚨 Act now

That’s it.

And you can do that quickly using a simple framework.

The FortiSense 60-second triage framework

When an alert appears, go through these checks in order.

Step 1: Is this “normal for this machine”?

This is the fastest way to cut 70% of noise.

Ask:

• Is this a server, a staff laptop, or a shared PC?

• Does this machine run known heavy workloads?

• Is this machine used by admins / developers?

• Is this in the middle of something expected? (patching, backups, installs)

Example:

• A developer workstation launching PowerShell may be normal.

• A finance laptop launching PowerShell is often not.

If it could be normal, don’t dismiss the alert, move to Step 2.

Step 2: What is the process, and does the name make sense?

Process names matter, but not in the simplistic “bad list” way.

You’re looking for:

✅ Process names that make sense

• chrome.exe

• teams.exe

• outlook.exe

• svchost.exe (sometimes abused, but common)

🚩 Process names that don’t fit the environment

• random letters like a8f3k.exe

• misspellings like micros0ft.exe

• weird names like update-service2.exe appearing out of nowhere

A normal name doesn’t guarantee safety.
But a strange name is usually worth attention.

Step 3: Check the “parent chain” (this is where most real risk hides)

A key difference between “noise” and “real risk” is how something started.

A lot of real attacks don’t begin with “bad.exe”.

They begin with:

• a document

• a browser download

• a script

• a trusted system tool being abused

So instead of asking “What is running?”, ask:

What launched it?

✅ Parent-child chains that are usually fine

• explorer.exe → chrome.exe

• services.exe → expected business software

• winlogon.exe → system processes

🚨 Chains that are often suspicious

• winword.exe → powershell.exe

• excel.exe → cmd.exe

• browser → unknown EXE → scripting engine

Even when the process itself is familiar, the chain can reveal risk.

Example:
PowerShell running isn’t always bad.
PowerShell launched by a document is rarely a good sign.

Step 4: Where is it running from?

This is one of the easiest “tell” signals, even for non-security people.

Legitimate apps generally run from places like:

• C:\Program Files\...

• C:\Windows\System32\...

Risky or suspicious apps often run from:

• temporary folders

• user-writable directories

• odd subfolders in AppData

• the Downloads directory

If the alert shows the executable path and it’s somewhere unusual, your confidence should go up fast.

Step 5: Is this “first seen” or something recurring?

This is where non-security teams can make very good decisions quickly.

Ask:

✅ Has this happened before?

• If it’s been seen repeatedly for weeks, it may be normal.

• If it appears once and never again, it might be a one-off installer.

• If it appears suddenly across devices, that’s more concerning.

🚨 Is this “first seen” today?

If it’s brand new, ask:

• Who installed something recently?

• Was there an update?

• Was there a download or new tool introduced?

If nobody knows what it is and it’s first seen today, treat it as suspicious.

Step 6: Look for “stacking signals”

One signal can be noise.

Multiple signals together is where you should act.

Example: benign pattern

• High CPU

• Known backup process

• Seen before
  ✅ likely ignore or monitor

Example: suspicious pattern

• Unknown process name

• Running from a temp directory

• Spawned by a document or browser

• First seen today
  🚨 act now

This is exactly why FortiSense focuses on risk patterns, not “one alert = one incident”.

So what do you actually do next?

Here’s the practical decision tree you can follow.

✅ Ignore (safe to close / suppress)

Ignore when:

• it’s a known business app

• the activity is expected (updates, backups, scheduled jobs)

• it’s been seen repeatedly

• it has a normal parent chain and normal path

Tip: ignoring doesn’t mean “it was pointless”.
It means FortiSense helped you confirm it was normal.

👀 Monitor (don’t act, but keep an eye on it)

Monitor when:

• it’s new but doesn’t have strong risk signals

• the path is unusual but the process is explainable

• you need to confirm with a colleague first

Monitoring is a valid outcome, especially in small businesses where disruption costs real money.

🚨 Act now (triage + contain)

Act quickly when:

• the process is unknown

• the parent chain is suspicious

• the path is unusual

• it’s first seen

• it coincides with CPU/network spikes

• the endpoint matters (server / finance / admin laptop)

“Act now” doesn’t mean “wipe the machine”

It means:

1. isolate the process (kill if necessary)

2. quarantine if you have high confidence

3. investigate the source (download, email attachment, installer)

4. check if it appears elsewhere

This is the difference between “we noticed early” and “we noticed after damage.”

Quarantine: when to use it (and when not to)

Quarantine is powerful, but it’s also disruptive if you do it blindly.

FortiSense supports:

• manual quarantine per alert / per process

• auto-quarantine for premium users, based on confidence thresholds you set in policy

The key is confidence.

✅ Quarantine makes sense when:

• it’s an unknown executable

• it’s running from a suspicious location

• it has a suspicious parent chain

• it shows behaviour consistent with abuse

⚠️ Be cautious when:

• it could be a business-critical tool

• it’s an installer/update process

• it’s on a server with known heavy workloads

When in doubt: monitor first, then quarantine once you’ve confirmed it’s not legitimate.

Why this matters so much for small businesses

Big companies pay for security teams to triage alerts all day.

Small businesses don’t get that luxury.

That’s why most “enterprise-style” security tools fail in SME environments:

• too noisy

• too complex

• too many “maybe” alerts

• not enough context

The goal with FortiSense isn’t to drown you in detections.

It’s to give you a small number of alerts you can actually act on, with enough context to decide confidently.

Quick recap: the 6 checks

If you remember nothing else, remember these:

1. Is this normal for this machine?

2. Does the process name make sense?

3. What launched it (parent chain)?

4. Where is it running from (path)?

5. Is it “first seen” or recurring?

6. Are multiple signals stacking?

That gets you to Ignore / Monitor / Act in under a minute.

Try FortiSense and test this for real

The fastest way to feel confident in alerts is to see how they behave in your environment, and how quickly you can triage them using the framework above.

👉 Try FortiSense free and build confidence early, before a real incident forces you to.