Why live is not the same as covered
A service declared operational whose escalation path has never been tested is a confidence interval, not a control. The provider has connectivity. Logs are flowing. The contract is signed. None of that means your environment is covered.
The gap between technical integration and meaningful detection coverage is an exposure window with a definable edge — and that edge is evidence, not a calendar date. MDR providers can technically connect to your environment while missing whole asset classes, ingesting logs at degraded fidelity, or routing alerts to a shared queue your team has never validated. Each of those conditions produces a service that looks operational and fails silently under real adversary pressure.
NIST SP 800-61 Rev. 3 frames preparation — not detection — as the activity that determines whether incident response actually works, treating IR as a continuous capability with defined roles and coordination paths rather than a point-in-time integration (Source: NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations, https://csrc.nist.gov/pubs/sp/800/61/r3/final). That framing applies directly to onboarding: the preparation work is the escalation path verification, the containment authority test, the baseline agreement. Without it, you have detection infrastructure without response capability.
This guide covers executing an onboarding from a clean start, assuming vendor procurement is already complete and there is no incumbent provider to replace. It picks up immediately post-selection and focuses on the critical gap between signing the contract and ensuring telemetry and detection fidelity are actually working.
Telemetry activation and fidelity verification
The first gate is simple and frequently failed: does the agreed source list match what is actually ingesting? Onboarding agreements define a telemetry scope — endpoint, identity, network, cloud, email — but the mapping between that scope and what arrives in the provider's SIEM is almost always incomplete at initial integration. The failure mode is not an outage; it is a silent gap. Assets that never registered are indistinguishable from assets with no alerts.
Before any tuning work begins, run a source-completeness check: pull the agreed telemetry source list from the contract, then query the provider's ingestion layer for the actual source inventory. Gaps between those two lists are your first exposure measurement. Any asset class present in the contract but absent from the query result is uncovered, regardless of what the onboarding status dashboard shows.
Fidelity verification goes one level deeper. Log volume is not a proxy for log completeness — a source can ingest at reduced field fidelity, drop high-cardinality events under EPS throttling, or apply collection-side filtering that removes the exact events detection rules depend on. For telemetry dependency theory — what specific fields a detection requires — SECOPS-DE-PRAC-004 owns that analysis. Here the question is narrower: confirm that events are queryable, that timestamps align with event-source time rather than ingestion time, and that retention is consistent with the agreed window.
A practical verification sequence for each source class: write a synthetic or known-good event at the source, confirm it arrives in the provider's environment within the expected latency window, then confirm it is queryable by field. If your identity platform generates an authentication event and it is not retrievable by user principal within the agreed latency, you have a fidelity failure, not a tuning problem. For endpoint telemetry depth and retention criteria specifically, EP-DR-004 owns the evaluation framework — reference it there rather than re-deriving coverage thresholds here.
Gate 1 exit condition: every source on the agreed list has a confirmed ingestion record, at least one synthetic event per source class has been verified end-to-end, and any gap is documented with a remediation owner and date.
The baseline tuning period
Noise at onboarding is structural, not indicative of a detection problem. A new MDR integration into a real environment generates high false-positive volume because detection rules calibrated to a generic baseline encounter environment-specific behavioral patterns that have not yet been profiled. The tuning period exists to close that gap.
Two structural limits shape what tuning can achieve, and both should be understood before the baseline period begins:
- MDR detection is bounded by known threat patterns. An MDR provider's detection logic covers techniques that have been modeled and built into rules or behavioral baselines. Novel attacker behavior that falls outside those models will not generate alerts regardless of how well the service is tuned. Onboarding does not change this boundary — it calibrates detection within it. Threat intelligence gaps belong to a separate programme; do not expect tuning to compensate for them.
- False-positive reduction has a practical ceiling. Every SOC has a finite capacity to tune out noise before the tuning process itself starts introducing false negatives — suppressing rules or conditions that are noisy but also catch real activity. That ceiling is lower during onboarding than in steady state. For most environments, the right approach is to reach an acceptable threshold for go-live and continue optimization afterward, rather than holding go-live open until tuning is exhaustive. The goal at onboarding is a stable, workable rate — not a perfect one.
NIST SP 800-137 requires an ISCM strategy to explicitly assign who monitors what, at what frequency, and who acts on results — not leaving those assignments implied (Source: NIST SP 800-137, Information Security Continuous Monitoring ISCM, https://csrc.nist.gov/pubs/sp/800/137/final). During the baseline period, that assignment question is live: your team and the provider are both receiving alert output, and without explicit agreement on who triages what, duplicate effort and missed handoffs are both common failure modes.
Define a triage ownership model before the baseline period begins, not during it. A workable structure assigns initial triage of all alerts to the provider, with your team receiving escalations only above a defined confidence threshold during this period. What that threshold is should reflect your team's capacity and your risk tolerance — there is no universal number. The output the baseline period is accountable for is a stated false-positive rate against a defined alert category set, agreed in writing between your team and the provider.
The scheduling question: baseline tuning concludes when the false-positive rate stabilizes to a level both parties have accepted, not when a fixed number of days have elapsed. If you're using a calendar deadline to close the baseline period, you're accepting residual noise as a permanent condition rather than confirming stability. The gate is the rate, not the date — but the rate does not need to be zero to proceed to go-live.
Failure mode: baseline tuning is declared complete by the provider before stabilization because the contract timeline is driving the milestone. Observable symptom: alert volume does not decrease week-over-week, and your team is still manually triaging events the provider should be absorbing. Remediation: escalate the false-positive rate in writing, document the open items against the contract's coverage SLA, and do not sign off on gate closure until stabilization is confirmed.
Gate 2 exit condition: false-positive rate is documented and mutually accepted at a threshold sufficient for go-live; triage ownership is explicit for all alert categories; no alert category is in an unassigned state; any optimization work deferred post-go-live is documented with a named owner and timeline.
Testing escalation before you need it
An escalation path that has not been tested under conditions that resemble real use is an assumption, not a control. NIST CSF 2.0 makes accountability and role definition a first-class governance outcome — not an implementation detail — by adding GOVERN as a co-equal function alongside Detect, Respond, and Recover (Source: NIST Cybersecurity Framework CSF 2.0, https://www.nist.gov/cyberframework). Testing escalation during onboarding is how that governance claim becomes operational.
Run an end-to-end escalation test before go-live. The test should inject a synthetic alert at the detection layer — preferably using a technique from your agreed threat model — and verify: the alert fires in the provider's environment; it routes to the correct analyst tier; the analyst escalates to your designated contact within the agreed SLA; your team receives the escalation with sufficient context to make a containment decision; and the containment action, if exercised, executes with the authority that was agreed in the contract.
Each of those steps is a distinct failure point. The most common failures in practice are:
- Escalations arrive at an unmonitored shared mailbox. Shared inboxes that are not actively staffed during off-hours create coverage gaps that are invisible until an incident falls into one.
- The escalation contact on record is not the on-call engineer. Provider systems often carry the name of whoever signed the contract. If that person is not reachable at 2 am, the escalation chain breaks at the first handoff.
- Containment authority exists in the contract but has not been provisioned in the tooling. The most important distinction to verify: containment authority must be operationally activated, not just contractually authorized. That means the provider's tooling can actually execute the agreed action in your environment, confirmed with a test isolation, revocation, or block — whichever your agreement covers.
Gate 3 exit condition: at least one end-to-end escalation test has been completed, documented, and reviewed; every step in the escalation chain has a named owner; any failure identified during the test has been remediated and re-tested.
Coverage validation and the gaps you accept
No MDR deployment covers an environment completely. The question at onboarding is not whether gaps exist but whether the gaps are known, evaluated against a threat model, and explicitly accepted rather than discovered during an incident.
Map what the provider's detection logic covers against your threat model — at minimum, against the technique categories most relevant to your industry and environment. Gaps that fall inside your high-risk surface are material; gaps that fall outside it may be acceptable. Either way, they require a documented decision from a named owner. This is the first measurement of coverage — not the recurring programme. While ongoing controlled detection testing and continuous coverage mapping belong to steady-state operations, this initial pass establishes the baseline that the programme will track against.
Two categories of gap deserve explicit treatment at this stage. First, gaps that could be remediated but are deferred post-go-live should be documented with a remediation timeline, not silently carried. Second, gaps that reflect the structural boundary of MDR detection — techniques that are not yet modeled in any provider's ruleset — should be noted as risk carried, with a named owner and a review trigger if the threat landscape changes.
NIST SP 800-137's requirement that an ISCM strategy name who monitors what and at what frequency applies directly to coverage gaps: if a gap is accepted, the strategy should name whether anything else is compensating for it or whether the risk is simply carried (Source: NIST SP 800-137, Information Security Continuous Monitoring ISCM, https://csrc.nist.gov/pubs/sp/800/137/final). Accepted gaps without a compensating control or a risk acceptance decision create implicit exposure.
Gate 4 exit condition: coverage is mapped against the threat model; all gaps are classified as accepted with a named decision owner, or assigned to a remediation timeline; no gap is unreviewed.
Go-live criteria and who signs them
Go-live is not a provider declaration. It is a bilateral confirmation that specific, verifiable criteria have been met — signed by the person on your side with authority to accept the residual risk of any open items. What constitutes go-live readiness depends on your environment's risk profile, regulatory obligations, and the threat surface the MDR service is intended to cover. The criteria below reflect what a complete onboarding should be able to demonstrate; the specific thresholds within each criterion are decisions your team makes, not defaults to accept from the provider.
Go-live readiness table
| Criterion | How it is verified | Evidence required | Who signs |
|---|---|---|---|
| Telemetry completeness against agreed source list | Query provider ingestion inventory against contract source list; reconcile line by line | Ingestion inventory report with gap analysis; zero unresolved gaps or documented exceptions with remediation dates | Customer security lead + provider onboarding lead |
| Log fidelity and queryable retention | Synthetic event test per source class; timestamp alignment check; retention window query | Test event receipts with latency timestamps; retention query results confirming agreed window is queryable | Customer detection engineer |
| Escalation path tested end-to-end | Tabletop or live-fire escalation test per agreed threat scenario | Documented test run: alert fired, routed, escalated, received, acted on; all chain links confirmed with named contacts | Customer IR lead + provider SOC lead |
| Baseline tuning concluded with stated false-positive rate | Mutual sign-off on false-positive rate documentation | Written agreement on rate per alert category; no alert category in unassigned triage state; post-go-live optimization items documented | Customer security lead + provider detection lead |
| Coverage validated against threat model with accepted gaps recorded | Coverage map reviewed against threat model; gap classification complete | Coverage gap register with named decision owners; accepted gaps have explicit risk acceptance or compensating control noted | Customer CISO or delegated risk owner |
| Containment authority activated and tested | Provider tooling confirmed to execute agreed containment actions in customer environment | Test isolation, revocation, or block executed and logged; authority confirmed in both contract and tooling | Customer security lead + provider operations lead |
Any open item at go-live sign-off should be documented as a named exception with a remediation owner and a date. Signing go-live with unnamed open items is accepting unknown residual risk — that decision belongs to the person with authority to carry it, not to the onboarding team.
Once this table is signed, the onboarding is complete, and the steady-state operating rhythm begins.
Sources
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations: https://csrc.nist.gov/pubs/sp/800/61/r3/final
- NIST SP 800-137, Information Security Continuous Monitoring (ISCM): https://csrc.nist.gov/pubs/sp/800/137/final
- NIST Cybersecurity Framework (CSF) 2.0: https://www.nist.gov/cyberframework
