What Happens in the First 60 Days With a New MDR? Tuning, Tickets, and False Positives

Read the complete guide: How do you make your IT cyber-insurance defensible? A 2026 guide for commercial businesses.

You have signed with a new managed detection and response (MDR) provider, or you are about to, and you want to know what the first two months actually look like. The honest answer is that a new MDR does not deliver its full value on day one. It goes through a predictable onboarding curve: deployment, a quiet learning period, a noisy tuning period, and then steady state. Knowing what each phase should look like lets you tell a competent provider from one that will bury you in tickets and never improve.

What actually happens when you turn on a new MDR?

A new MDR follows the same detection-and-analysis lifecycle that structured incident response has always used: instrument the environment, establish a baseline of normal, then detect deviations from it. The NIST Computer Security Incident Handling Guide (SP 800-61) describes preparation and baselining as prerequisites to effective detection, not steps that can be skipped. An MDR that has never seen your environment cannot yet tell a routine administrative script from an attacker abusing the same tool. It has to learn first.

For a business with 10 to 25 employees, the whole arc typically runs 45 to 60 days. The endpoints are few enough that deployment is fast, but the environment still has to be observed long enough to separate normal behavior from real threats. The four phases below are what you should expect, and what you should push back on if they do not happen.

Days 1 to 14: Deployment and baselining

The first two weeks are about connecting sources and watching, not blocking. The provider deploys lightweight sensors to every endpoint, connects your identity and email logs, and confirms that data is actually flowing into their platform. This is the single most common point of failure in an MDR relationship: coverage gaps. An endpoint that never got a sensor, or a cloud log source that was never connected, is invisible, and invisible assets are exactly where incidents hide.

During this window a mature provider runs in an observation or audit posture. Known-bad signatures and obvious threats are caught immediately, but the platform is mostly building a picture of what normal looks like in your environment: which users log in from where, which applications run, what your after-hours traffic pattern is. You will see relatively few alerts. That quiet is not the service being lazy; it is the service learning. Your job in these two weeks is to answer the provider's coverage questions and confirm that every device and account you expect to be monitored is reporting.

Days 15 to 45: Tuning and the false-positive curve

This is the loud phase, and it is the phase that separates a real MDR from a log collector. As the platform starts flagging deviations from baseline, alert volume climbs. Many of those early alerts are false positives: a legitimate remote-access tool, a scheduled backup job, an administrator running PowerShell for a valid reason. This is normal and expected. It is also where the actual work of tuning happens.

A competent provider treats every false positive as tuning input. When they ask you "was this login from a new location expected?" or "did your team install this software?", your answer teaches the system. Over the next few weeks, alert volume should drop steadily as detections are refined to your environment. You are watching for a curve: noisy at first, quieter each week, converging on a small number of high-quality alerts that are worth a human's attention.

Two failure patterns show up here. The first is a provider that never tunes, so you keep getting the same false positives for months and alert fatigue sets in. The second is more dangerous: a provider that suppresses alerts wholesale to make the dashboard look calm, quietly discarding the signal along with the noise. A service that is silent is not the same as a service that is watching. The seven questions that expose that difference are covered in How can you tell if your MDR provider is actually watching, or just logging?

Days 45 to 60: Steady state and what "good" looks like

By the end of the second month a well-run MDR reaches steady state: tuned detections, a manageable ticket volume, and analysts who recognize your normal patterns. This is when the service starts earning its cost. Detections are specific to your environment, false positives are rare, and the alerts that do reach you are ones a human has already triaged and judged worth escalating.

Steady state is also when speed becomes the metric that matters. The reason businesses buy MDR is to compress the time between compromise and containment. Mandiant's annual M-Trends report has tracked global median attacker dwell time falling from months to a matter of days over the past decade, driven largely by faster detection and response. Verizon's Data Breach Investigations Report continues to show that a meaningful share of breaches are discovered by outside parties rather than the victim, which is precisely the gap a tuned MDR is meant to close. At steady state you should be able to ask your provider two concrete questions and get concrete answers: what is your median time to detect, and what is your median time to respond?

What you should demand from the provider during onboarding

The first 60 days are a mutual test, and you have leverage during them that you will not have later. Hold the provider to a short list of onboarding deliverables:

• A coverage confirmation. A written list of every endpoint, identity source, and log source under monitoring, with any gaps flagged. Ask for this at the two-week mark.
• A 30-day checkpoint. A short review confirming baselining is complete, tuning is underway, and alert volume is trending down.
• A 60-day checkpoint. Confirmation of steady state, with the provider's median time-to-detect and time-to-respond stated against the service levels in your contract.
• An escalation path you have tested. Know exactly who gets called at 2 a.m., how, and what happens if they do not answer. A response capability you have never exercised is an assumption, not a control.
• Evidence output. Confirm the service produces the alert and response logs your cyber-insurance carrier will ask for. That evidence trail is part of what makes your program defensible, and its absence is a common thread in denied claims. See Why do cyber insurance claims get denied?

MDR is one control in a larger detection-and-response stack, and it is worth being clear about where it fits relative to the endpoint and log tools it depends on. For that comparison, read What is the difference between MDR, SOC, EDR, and SIEM, and which one does cyber insurance actually want? MDR also pairs with prevention controls: CISA's #StopRansomware guide lists both detection and execution-prevention measures as complementary layers, not alternatives.

Frequently asked questions

How long before a new MDR is fully protecting my business?

Basic monitoring and known-threat detection are usually active within the first one to two weeks, once endpoint and log sources are connected. Full value, meaning tuned detections, a low false-positive rate, and analyst familiarity with your normal patterns, typically arrives around the 45-to-60-day mark. A provider that claims full protection on day one is overstating what any detection service can deliver before it has learned your environment's baseline.

Why does a new MDR generate so many alerts at first?

Early alert volume is expected and healthy. Before tuning, the platform flags anything that could be suspicious because it has no baseline for what is normal in your environment. Legitimate administrative tools, scheduled scripts, and business software can all trigger alerts until the analysts learn your patterns and adjust detection rules. Alert volume should fall sharply through the tuning window. A service that never reduces the noise is misconfigured, and one that suppresses alerts wholesale to look quiet is dangerous.

What should I be doing during the first 60 days of a new MDR?

Stay engaged. Respond promptly when the provider asks whether a flagged activity is legitimate, because those answers are what tune the system. Confirm every endpoint and log source is reporting, review the first weekly summaries, and hold an onboarding checkpoint at roughly 30 and 60 days to confirm coverage and response times against the contract. The quality of your input during this window directly determines how accurate the service is afterward. The Coalition 2025 Cyber Claims Report continues to show that organizations with stronger, actively managed detection controls face lower incident severity than those relying on unmonitored tools.

MDR onboarding does not stand alone. It is one part of the broader defensibility framework carriers evaluate at renewal, alongside MFA, backups, application allowlisting, and a tested incident-response plan. For the complete eight-control picture, read the pillar guide on cyber-insurance defensible IT.