Skip to content
Made in the UK

Managed Detection and Response

How does an MDR provider handle false positives without missing real threats?

By , Head of SOC and IR, CybaVerse. Last reviewed

A good MDR provider handles false positives by having analysts check each alert in context before escalating it, recording why it was benign, and tuning detections narrowly with evidence rather than switching rules off. Tuning is tested, reviewed regularly and reversible, so cutting noise never quietly removes visibility of real attacks.

This page is part of our managed detection and response guide.

What is a false positive in MDR?

NIST defines a false positive as an alert that incorrectly indicates malicious activity is present. In MDR, that might be a legitimate admin script that looks like an attacker's tool, or a sign-in from abroad by an employee on holiday. Each one costs analyst time and, if escalated, MSP engineer time too.

False positives are unavoidable. Detection rules are written to catch behaviour, and plenty of legitimate behaviour looks suspicious out of context. The goal is not zero false positives, which would mean missing real attacks, but handling them quickly and learning from them.

Why does tuning go wrong?

Tuning goes wrong when it is done to make a queue shorter rather than to make detection more accurate. Broad suppressions, such as ignoring a whole process name or every alert from one server, can hide exactly the activity an attacker relies on. Attackers often use legitimate tools for that reason.

  • Too broad. Suppressing a tool everywhere instead of for one approved use.
  • Untested. Changing a rule without checking what it would have missed.
  • Undocumented. Nobody can say later why an exception exists.
  • Never reviewed. Exceptions outlive the reason they were added.

How should false positives be handled, step by step?

The steps below describe how a careful MDR provider handles a suspected false positive. They work just as well for an MSP reviewing its own rules. The aim is to cut repeat noise while keeping a clear, reviewable record of every decision about what the service no longer alerts on.

  1. Step 1: Check the alert in context

    Look at the user, the device, the time and what normally happens for that client.

  2. Step 2: Record the verdict and the reason

    Write down why the alert was benign, with the evidence.

  3. Step 3: Tune narrowly

    Exclude the specific approved activity, not the whole technique or tool.

  4. Step 4: Test before applying

    Check what the change would have hidden in recent data.

  5. Step 5: Review exceptions regularly

    Revisit every exception at least quarterly and remove any that no longer apply.

How should an MSP judge a provider on false positives?

Judge a provider on your own data during a proof of concept, not on headline claims. Ask how alerts are triaged, how tuning decisions are recorded and how often they are reviewed. Expect the first weeks of any new service to be noisier while the analysts learn each client's normal behaviour.

Question to askGood answer
Who decides an alert is benign?A named analyst, with the reason recorded
How narrow are exceptions?Specific to a user, device or approved activity
Are exceptions tested?Yes, against recent data before applying
Are exceptions reviewed?On a regular schedule, with an owner
Will you share tuning changes?Yes, as part of regular reporting

MITRE ATT&CK is a useful shared reference here: tuning should never remove coverage of a technique entirely without a deliberate decision.

Where does CybaOps fit?

CybaOps is the CybaVerse MDR platform, delivered through MSPs, backed by our UK-based security operations centre. Our analysts review activity across client environments, and incidents are worked as cases, so the reasoning behind each decision stays with the evidence for later review and reporting.

  • Our UK-based security operations centre monitors customer environments 24 hours a day, 7 days a week.
  • Incidents are worked as cases in CybaOps, so every alert, action and note sits in one record your team can see.
  • Analysts and partners can search and investigate across their data in CybaOps, with AI help to build queries.
  • We are building a correlation engine into CybaOps that links related alerts into a single incident.
  • We do not publish false-positive percentages, because noise depends on each client's tools and estate. Ask any provider to show you the trend on your own clients.

False positives

How false positives are handled without missing threats

A good MDR provider handles false positives by having analysts check each alert in context before escalating it, recording why it was benign, and tuning detections narrowly with evidence rather than switching rules off.

01 Alerts from

Multi-tenantPartner / MSP CustomerCustomerCustomer+
CybaOps by CybaVerse

False positives

02 The 5-step path

  • Role-based access
  • UK-based analysts
  • ISO 27001

03 Outcomes

Explore

Hover or tap any part of the diagram to see what it does.

  • MDR in
  • CybaCore
  • CybaEdge
  • CybaOne

What else do MSPs ask about false positives?

These are the follow-up questions we hear most from MSPs worried about noise from a new MDR service.

Why is a new MDR service noisy at first?

Analysts are still learning what is normal for each client, such as admin tools, scheduled jobs and travel patterns. Noise usually falls as that context builds up and narrow, evidence-based exceptions are added.

Should we turn off rules that keep firing?

Not without understanding why they fire. A rule that fires often may be catching a real misconfiguration or risky behaviour. Tune it narrowly for the approved activity instead of switching it off.

Can a false positive hide a real attack?

Yes, if an exception is too broad. Attackers often use legitimate tools, so an exception for a tool everywhere can blind the service. Keep exceptions specific, tested and reviewed regularly.

What should you do next?

See how CybaVerse MDR triages alerts on the CybaOps platform page. MSPs can read about the CybaVerse partner model for MSPs.

Related: How do MSPs reduce alert fatigue without missing real threats?, How can an MSP offer 24/7 MDR without building its own SOC? and Who fixes the issue after an MDR provider detects it?

See how alerts are triaged and recorded in CybaOps.

Book a CybaOps demo