How to Run the First 90 Days of Your MDR Engagement

Signing with a managed detection and response provider feels like the finish line. It is not. The Monday after signature is when the real work starts, and the first 90 days decide whether your managed security services engagement produces usable detections or a year of alert noise. This how-to walks the onboarding sequence that most vendor-selection guides skip: asset and log discovery, ticketing and identity integrations, telemetry staging, tuning windows, and escalation handoffs. It also covers internal prep that shortens onboarding, including named owners on both sides and staging telemetry by business risk rather than convenience.

You will learn how to run Days 1 to 30 for discovery, baseline, and integration; Days 31 to 60 for detection tuning, false-positive reduction, and validated escalation handoffs; and Days 61 to 90 for steady-state ownership, documentation, runbooks, and formal close. We include day 30, 60, and 90 tuning reviews, a checkpoint table, and practical guidance for mid-market teams without a full SOC. Treat onboarding as a joint project, not a handover.

Why the First 90 Days Decide the Outcome of a Managed Threat Detection Service

Provider selection gets every checklist, comparison table, and buying guide the industry can produce. The operational reality starts on the Monday after signature, when a managed threat detection service has to learn your environment from nothing.

That learning period is the whole game. The first 90 days decide whether the engagement produces detections your team acts on or a year of alert noise your team learns to ignore. Vendors promise faster answers through AI-driven threat detection in practice, but those gains depend on telemetry and tuning that do not exist on day one.

Onboarding is a joint project with named owners on both sides, not a vendor task you supervise. Unclear ownership is the most common reason onboarding stalls.

The failure mode is rarely a missed intrusion on day one. It is a queue that grows until analysts close alerts without reading them. Mid-market teams feel that delay hardest: no dedicated detection engineering function, one or two people wearing the SOC hat, and no slack to absorb ambiguity.

This guide runs in three phases, each closing with an explicit review:

• Days 1 to 30: discovery and baseline.
• Days 31 to 60: detection tuning and escalation handoff validation.
• Days 61 to 90: steady state, ownership, and close.

A transparency note before you plan around it: this cadence is recommended practice drawn from operational experience, not a published standard. No public benchmark defines MDR onboarding timelines, so treat these dates as checkpoints you set, not guarantees a provider owes you.

Prerequisites: The Internal Prep That Shortens Onboarding

Preparation is the phase you control completely. Treat it as a project with deliverables, not a contract to re-read.

Name Owners Before Day One

Identify three roles: an internal technical lead who answers environment questions, an internal decision owner who authorizes change, and named counterparts at your cyber security managed services provider. Unnamed owners are how onboarding stalls.

Build the Asset Inventory

Separate what you know you run, what you suspect you run, and what nobody has claimed. That third category is where discovery surprises live. Apply the same discipline to identities: service accounts, break-glass accounts, local administrator sprawl, and shared credentials that complicate containment later.

Agree the Escalation Tree

Who is called first at 2 a.m.? Who second? What authority does each contact hold to isolate a host or disable an account, and how does the provider reach you out of band? NIST frames incident readiness as a pre-incident activity. Third-party exposure belongs in the same exercise, so run vendor and partner access through your supply chain cyber risk audit workflow instead of leaving it undocumented.

Confirm the Ticketing Path

Decide before telemetry flows whether the provider opens tickets in your ITSM, in their portal, or both, and who closes them and records the reason.

Define Day 30 Success

Write down what day 30 success looks like for your organization, so the first review measures something concrete instead of a feeling.

This is the prep teams skip when contract signing consumes everyone’s attention, and the cheapest part to get right.

Days 1 to 30: Discovery, Baseline and Telemetry Integration

With owners named and escalation paths agreed, phase one has one job: understand the environment, then get the highest-value telemetry flowing. In that order. Breadth comes after.

Expect discovery to contradict your documentation. The gap between what the register claims and what is actually running is the real deliverable of month one, not a tidy inventory.

Resist onboarding every available log source in week one. Low-value feeds generate volume that buries the signals you staged deliberately, and a flooded queue looks like progress while delaying tuning.

Put the day 30 review on the calendar on day one, with named attendees from both sides. Reviews that are not scheduled get skipped. That checkpoint is where the demands in your MDR procurement checklist meet operational reality.

Asset and Log Discovery: Inventory What You Are Handing Over

Discovery starts with a list, not a log. Enumerate every category you own: endpoints, servers, cloud workloads, identity providers, network devices, SaaS applications, and any operational technology or IoT present in your environment.

Rank candidate sources by the questions they let an analyst answer: who authenticated, what executed, what left the network, what changed in the cloud control plane. Those four questions carry most investigations, so sources answering them outrank sources that are merely convenient.

For each source, confirm the collection method (agent, API, syslog forwarder, cloud-native connector), retention period, and licensing or cost implication before committing. NIST’s log management guidance treats this as a lifecycle of generating, transmitting, storing, accessing, and disposing of log data, so record all five fields per source.

Name the gaps you cannot close this month: unmanaged devices, unsupported legacy systems, encrypted east-west traffic. Record each as accepted risk with an owner and a review date. If coverage priority is unsettled, a security risk assessment settles it.

Finally, maintain one shared asset and log register both sides can edit. Two versions that drift apart are worse than no register at all.

Ticketing and Identity Integrations That Determine Response Speed

With the asset and log register in hand, turn next to the integrations that decide how fast anything actually gets done once an alert fires. Wire the ticketing integration first: alerts should become tickets, tickets should reach a named analyst, and closure reasons should flow back to the provider. That feedback loop into detection is what makes tuning possible later. Agree a severity mapping between the provider’s scale and yours before the first real alert, because mismatched scales produce arguments about urgency at the worst possible moment. Integrate identity so containment is achievable: single sign-on, directory, mobile device management, and the ability to disable an account or revoke active sessions on request. Decide the out-of-band contact path now, whether that is a phone tree, a dedicated channel, or both, and never let a genuine escalation depend on email. Test every integration end to end with a synthetic case before marking it complete, and record who signed off. Teams building genuine cyber resilience treat these as day-one requirements, not follow-ups.

Staging Telemetry by Business Risk, Not by Convenience

Once integrations are signed off, the harder decision arrives: what gets connected first. Convenience staging connects whatever is easiest, the SaaS tool with a ready connector, the server nobody depends on. It produces a wide, shallow picture that photographs well in a status report and answers none of the questions that matter at 2 a.m.

Stage by business risk instead. Revenue-generating systems, customer data stores, privileged identity infrastructure, and internet-facing assets go first.

Use a coverage checklist. CISA’s Zero Trust Maturity Model Version 2.0 (April 2023) organizes around five pillars, Identity, Devices, Networks, Applications and Workloads, Data, plus cross-cutting capabilities. Mapping those pillars to telemetry priority here is our framing, not CISA guidance for managed security services.

Write down what phase one deliberately excludes, with a target date for every deferred source. Deferral becomes a decision rather than an oversight.

At day 30, reconcile the register against reality and chase the sources that were promised but never arrived. For how risk ranking should drive that order, see Security Risk Management in 2026: What Mid-Market Organizations Need to Know.

The Day 30 Tuning Review

Reconcile that register at day 30 by walking it line by line, not scanning it. For each entry, state what was committed, what is actually flowing, what is missing, and the name of the person who owns the gap.

Then open the volume dashboard by source. Any source clearly capable of drowning the queue gets flagged now, before it does, and either tuned or throttled with a recorded reason.

Integrations deserve a harder test than the one that passed in week two. Confirm ticket creation and identity lookups hold up under peak-hour load, not just in a test case. The same scrutiny belongs on internet-facing assets, where exploited zero day vulnerabilities can compress breakout times to under an hour.

Reset expectations explicitly: detections at day 30 are baseline behavior, not tuned output. Treating them as final invites premature judgment on the engagement.

Close by recording decisions, owners, and dates for the next 30 days, then circulating the notes to both sides.

Days 31 to 60: Detection Tuning and Escalation Handoffs

Day 30 answered what is flowing. Days 31 to 60 answer what is worth acting on. The phase goal: convert raw telemetry into detections your team can act on without reading every alert twice.

Expect a first wave of false positives. This is routine during tuning, not evidence the engagement is failing. Every environment produces them. Treat them as data.

Keep a tuning backlog: every alert triaged as noise, logged with the reason, timestamp, and alert identifier. Apply the documentation discipline the Step-by-Step NIST Cybersecurity Framework 2.0 Tutorial brings to risk management: dated, owned entries rather than impressions.

Tuning is a two-way conversation with your managed threat detection service provider, not a complaint list. Evidence makes a request actionable. Include the alert identifier, the timestamp, and the business reason the activity is expected. Vague complaints produce vague responses.

Cutting False Positives Without Going Blind

With the backlog established, resist the urge to suppress the loudest alert and move on. Tune with context first: add allowlists for known-good administrative tools, vulnerability scanners, and scheduled jobs before disabling any rule that fired.

Distinguish a false positive, where the rule fired and nothing happened, from a true-but-uninteresting alert, where real activity occurred and was expected. The remedies differ: the first calls for rule logic review, the second for an exception scoped to the business process.

Attach evidence to every tuning request: alert identifier, timestamp, the business reason the activity is expected, and the scope of exception requested. Then ask what the tuned rule still catches. Aggressive suppression creates detection gaps nobody notices until an incident review.

Work the highest-volume alert sources first. Tuning effort should follow the queue, not an analyst’s curiosity about an elegant detection.

Next, validate the escalation handoffs those tuned rules feed.

Validating Escalation Handoffs Before You Need Them

Tuning decisions assume the escalation path works. Prove it before an analyst needs it at 2 a.m.

Run a tabletop walkthrough of one real alert, from detection through the containment decision, with both sides on the call. Use a recent ticket rather than a hypothetical. Confirm the named contacts answer, that authority to isolate a host or disable an account is unambiguous, and that the provider knows which systems you consider business critical.

Agree containment thresholds in advance for host isolation, account disablement, session revocation, and domain blocking. Pre-approving these conditions removes the improvisation that slows a response while someone hunts for an approver.

Define the post-incident handoff too: who writes the summary, who notifies leadership, who handles customer communication, and where the record lives. A managed detection and response engagement fails quietly when nobody owns the write-up.

Fix what the walkthrough exposes during the tuning window. Friction found in a rehearsal is a process fix; the same friction found mid-incident is a delay with consequences.

The Day 60 Tuning Review

With the escalation walkthrough complete, the day 60 review shifts from rehearsal to evidence.

Trace the ticket path. Pull 30 days of tickets and follow one end to end: alert, triage, escalation, containment, closure. Flag every stall and name the party holding it. A ticket waiting hours on an outdated contact list is a process gap, not an analyst failure.

Work the tuning backlog. Each item earns one of three states: closed, in progress with an owner and date, or declined with the reason recorded. A backlog that only grows is a complaint file.

Reopen the day 30 gap register. Confirm which coverage gaps closed. Escalate the rest with named owners and target dates.

Revisit the severity mapping. Real examples replace hypothetical ones, so urgency disputes become specific and settleable now.

Fix what you find before day 90, when the engagement is expected to run on its own.

Days 61 to 90: Steady State, Ownership and the Day 90 Review

The day 60 review closes the tuning sprint. Days 61 to 90 carry a different goal: leave project mode and settle into an operating rhythm that holds when the people who built it move on, or when a quiet week passes with nothing to triage.

Progress here is qualitative, not numeric. Your analysts spend less time per alert, because context arrives with the ticket instead of requiring a phone call. The provider asks fewer clarifying questions, because its picture of your environment has filled in. If neither is true, you are still in project mode.

This is the window where documentation gets skipped. The urgent work is done, so the asset and log register, escalation tree, and tuning decisions stop getting updated. That gap is what causes an engagement to decay by month six.

A managed cyber security services engagement without a documented operating rhythm reverts to ad hoc escalation within a quarter.

Documentation and Runbooks That Keep the Engagement Alive

Steady state only holds if the runbook outlives the people who wrote it. Consolidate the asset and log register, escalation tree, severity mapping, tuning decisions, and accepted risks into one document set with a single named owner on your side. Include the negative space: write down what the provider is not monitoring. Unwritten scope becomes a dispute the first time something fails outside it.

Then define how systems enter monitoring. Name who can request it, what they must supply (owner, business function, collection method, log source), and the expected turnaround from request to live coverage. Without that path, new systems sit unmonitored for months.

Finally, set a review cadence beyond day 90, such as quarterly register reconciliation, so the document does not rot as systems are retired, migrated, or replaced. Put each review on the calendar with an owner, or the register becomes a snapshot of a network that no longer exists.

Defining What Working Means at Day 90

With the register consolidated, define what working looks like at day 90 before you judge the engagement.

Working means:

• Named owners on both sides of the handoff
• Telemetry staged by business risk, not volume
• A tuning loop that runs on evidence
• Escalation paths that have been exercised, not just documented

It does not mean zero alerts or zero false positives. A silent queue signals a broken or over-suppressed pipeline, not coverage. Those are marketing outcomes; operational ones look messier.

No public benchmark defines successful MDR onboarding. Set qualitative criteria against your own operations and risk tolerance: does your team act on what it receives, and would a 2 a.m. call reach someone with authority to act?

Agree in advance how you will recognize an engagement that is not working, and what the reset or exit conversation looks like before anyone needs to have it.

The Day 90 Tuning Review and Formal Close

With your working definition settled, the day 90 review closes the project. Treat it as a formal close, not a status meeting.

Confirm the steady-state cadence: how often tuning reviews happen, who updates the asset and log register, and when escalation contacts get re-verified. Monthly for the first year is a reasonable practitioner default; document whatever you choose.

Walk residual noise and residual blind spots in the same pass. Every remaining item needs a named owner and a date, including the ones you have decided to accept.

If staffing changed during onboarding, re-confirm escalation contacts, coverage hours, and containment authority. Turnover in month two quietly invalidates a tree built in month one.

Then close onboarding in writing: one document set, one designated owner, and a start date the operating rhythm runs from. Engagements that trail off instead of closing tend to decay within a quarter.

The Day 0, 30, 60 and 90 Checkpoint Table

Treat the cadence as a reusable checkpoint structure: what must be true at each date, who owns it, and the evidence that moves the project forward.

Two cautions. Fill this table with process states, never invented numbers or borrowed benchmarks. The 30/60/90 cadence is recommended practice drawn from operational experience, not a contractual norm, and presenting it as a guarantee invites a dispute the first time an environment takes longer to integrate.

Review the table weekly. A checkpoint that slips three weeks is a project risk, not a scheduling detail.

Mid-Market Resourcing: Running This Without a Full SOC

The checkpoint table only works if someone has the hours to execute it. In most mid-market teams, that someone is also handling patching, identity, backups, and the helpdesk queue.

Name that constraint and plan around it. Treat discovery and integration weeks as real project work with blocked calendar time, not background tasks squeezed between tickets. A useful test: if the work has no named owner and no allocated hours, it will not happen.

Keep decision authority and business context internal. A managed threat detection service cannot know which system carries revenue unless you say so. Treat the provider as an extension of your team for execution, not as the source of your business priorities. Provider fit matters here. A cyber security managed services provider that expects enterprise-scale process maturity as a precondition will stall a mid-market onboarding. HecateLabs provides cybersecurity services designed for mid-market organizations, and the implication is straightforward: let mid-market constraints shape the plan instead of working around them.

Own the asset register and tuning backlog internally. Institutional knowledge should not live only inside a vendor portal you might leave. One shared document, updated at each tuning review, keeps that continuity yours.

Budget the hours, keep the context, and the checkpoint table becomes achievable rather than aspirational.

Conclusion: Onboarding Is the Engagement

Mid-market constraints should shape the plan. They do not excuse skipping it.

The contract decides who watches your environment. The first 90 days decide whether that watching produces anything you act on. Three takeaways carry the rest:

• Run onboarding as a joint project with named owners on both sides, and schedule the day 30, 60, and 90 reviews before day one. Reviews that are not on the calendar do not happen.
• Stage telemetry by business risk rather than by whatever is easiest to connect, and document every source you deliberately deferred, with a target date attached.
• Keep a tuning backlog with evidence attached to each entry, and exercise escalation handoffs before an incident forces the test.

No published benchmark defines a correct onboarding timeline, so treat this cadence as recommended practice. Adjust it to your environment instead of defending it.

If you are heading into or already inside a managed detection and response engagement, open the checkpoint table and compare it against where you actually are this week. Then fix the first gap you find. That gap is usually an unnamed owner, an untested integration, or a deferred log source nobody wrote down.

HecateLabs provides cybersecurity services designed for mid-market organizations that need this kind of onboarding discipline to hold.