When switching managed detection and response (MDR) providers, agree when the incoming team takes responsibility for each group of systems, each open investigation, and access to earlier evidence. Keep the outgoing coverage in place until the agreed acceptance conditions are met, or put an explicitly approved interim arrangement in place. Coordinate those transfers before the contract ends.
The IT manager needs a handover that both providers can execute: who receives an alert, who investigates it, who may act, and what happens to work already underway. Resolve the overlap, costs, exit assistance, and exceptions before the old agreement expires.
Agree the operating handover before removing tools
The UK's National Cyber Security Centre (NCSC) recommends defining provider and customer responsibilities, incident-reporting arrangements, log access, retention, and exit terms in its guide to working with managed service providers. For an MDR transition, turn those requirements into an agreed sequence rather than assuming the new service inherits the old one's work.
List the systems and event sources moving, the person who approves acceptance, and the permitted response actions. Identify anything staying with the current IT provider. Application maintenance, identity administration, backups, and recovery work need explicit owners; changing the monitoring service does not automatically transfer them.
Network Box USA's NBX managed detection and response service combines security operations center (SOC) monitoring, alert triage, investigation, endpoint context, escalation, and response guidance. Its deployment process includes defining coverage and responsibilities, validating telemetry, testing policy behavior, and documenting the operational handoff. That managed work gives an incoming service a concrete basis for accepting responsibility. Confirm supported systems, integrations, response authority, and any migration assistance in the actual proposal.
Work through a handover with two unfinished items
Consider Cedar Design, a hypothetical architecture firm changing MDR providers. Its IT manager, Mia, has agreed a limited transition period with both teams. Most staff laptops and the design-file server are ready to move. One employee's laptop is offline, and the outgoing analysts still have an open investigation into a suspicious sign-in to the server.
Before cutover: Mia and the incoming team validate the ready systems using agreed, harmless test activity. They check that the expected events arrive, can be interpreted, and reach the intended analyst and escalation contact. They also walk through the response permissions, including which actions need Mia's approval and what happens when she is unavailable. Testing a disruptive action on the live design server would require its own authorization and operating safeguards.
The endpoint-tool sequence is part of this preparation. Do not assume two agents can safely run with every prevention and response function enabled. Microsoft's guidance on concurrent security solutions, for example, describes performance conflicts, overlapping functions, and protection tradeoffs from exclusions. This illustrates why vendor-specific migration instructions matter; it does not establish compatibility with NBX. Have the suppliers approve the actual versions, operating modes, removal steps, and rollback path.
At the agreed cutover: the incoming team accepts monitoring and the agreed response duties for the validated systems. Mia records the exact time and time zone with the accepted asset list. The outgoing team stops its routine monitoring responsibility for that group as agreed. Both teams know where to route a duplicate or delayed alert, so two analysts do not independently issue conflicting instructions.
The offline laptop remains a named exception under the agreed temporary arrangement. The incumbent retains responsibility for it until a separate transfer is accepted. That does not create live visibility while the device is offline. When it returns, the teams validate its supported tool transition and monitoring before moving it into the accepted group. If the temporary arrangement will expire first, Mia must choose an approved alternative or restriction before that deadline.
The open investigation: Mia does not close the server case merely because the server has moved. The outgoing investigator supplies the evidence gathered, actions already taken, unresolved questions, and next action. The incoming investigator explicitly accepts the case, and both records cross-reference one another. Until that acceptance, the agreed case owner continues the investigation and coordinates any action affecting the now-transferred server.
Put the continuing case responsibility in writing:
The incoming team owns monitoring of new activity on the accepted server from the recorded cutover time. The outgoing investigator remains responsible for the existing sign-in case until the incoming investigator acknowledges its evidence and next action. Coordinate all proposed server changes through the designated incident lead under the agreed response permissions.
Ready systems can now move while the absent laptop and unfinished investigation retain explicit owners and next actions.
Keep earlier evidence usable after the transfer
A later alert may require records from before cutover. Agree how authorized investigators will retrieve that history before the old portal closes. Obtain the required event data and case records in a supported format, or arrange a defined retrieval service. Test a sample retrieval, including timestamps, device and user identifiers, and the context needed to interpret the records.
Historical data may need to remain in a protected archive rather than the incoming platform. Do not assume another provider's exports, detection rules, or case history can be imported. Record where the evidence is held, who can retrieve it, how long access remains available, and any retrieval charges. Our security-log retention guide explains how to set the underlying retention requirements.
End access when the remaining work ends
The NCSC's supplier assurance questions explicitly address returning or securely deleting data and transferring services at contract exit. Make that an acceptance task with the outgoing provider. Preserve records subject to an approved retention or preservation requirement, then apply the agreed return and deletion process.
Revoke access that is no longer needed: administrative accounts, delegated permissions, remote-support connections, service credentials, and automation integrations. Replace or rotate shared credentials through an approved change process that accounts for their dependencies. Keep any remaining historical-retrieval access separate and limited; retaining evidence is not a reason to leave broad administration privileges active.
Before approving a provider change, ask both teams to work through one late device and one open investigation. To discuss a move to NBX MDR, contact our team with your current coverage, contract dates, critical systems, and the response work you want managed. Describe the environment in the form; arrange sensitive case evidence and credentials through an agreed secure channel.