By Dan Stark
Before your current security provider steps away, confirm who will receive the next alert, who can act on it and what evidence shows that the new arrangement works.
When changing managed cybersecurity services, make those decisions for each service or system being transferred. An agreed start date can leave individual accounts, devices or open investigations unresolved.
A handover record brings the work into view: what the outgoing provider still handles, what the incoming provider has accepted, and what happens if a dependency isn’t ready.
This guide starts after provider selection. If you’re still comparing proposals, use our cybersecurity services buying checklist first.
Agree when each responsibility changes hands
List the services, systems, accounts and locations involved. Record the current agreement’s end date, the incoming provider’s start conditions and any licensing or vendor dependencies.
Have both providers confirm their respective responsibilities. If the new arrangement won’t be ready before existing coverage ends, resolve that mismatch while there’s still time to act. Continuing the current service requires the outgoing provider’s agreement and workable terms.
Separate four assignments:
- Business approval: Who authorizes spending, operating restrictions and risk decisions?
- Technical execution: Who makes changes and produces the required test evidence?
- Coordination: Who tracks dependencies, obtains decisions and keeps the providers and business informed?
- Acceptance: Who’s authorized to confirm the agreed work is ready to transfer?
One person may hold several assignments. Coordinating the move doesn’t automatically give someone authority to accept risk or change a contract.
NIST’s Cybersecurity Framework 2.0 includes defined responsibilities and planning for activities after supplier relationships end. The handover record below is a practical way to organize your decisions. NIST doesn’t prescribe this worksheet or staffing arrangement.
What must transfer between managed cybersecurity services providers
A useful handover covers the access, information and operating dependencies needed to perform the agreed work.
Accounts and tools
Identify who controls each account, security platform and subscription. Record what stays with the business, what belongs to a provider and what must be transferred, replaced or separately licensed.
Include delegated administrator permissions, service accounts, integrations and recovery access. In Microsoft 365, distinguish the business’s own access from the permissions granted to a provider. Our guide to Microsoft 365 security management covers administrator and guest access in more depth.
Have the technical leads confirm product-specific requirements before removing software or changing management systems. A tool still appearing on a laptop doesn’t prove that its license, reporting or monitoring service remains active.
Agree on the checks that demonstrate readiness. Depending on the service, these might include expected devices reporting to the correct system, an authorized test reaching the right alert queue, and confirmation that the assigned team can investigate it.
Records and open work
Carry forward active alerts, investigations, unresolved remediation, known exceptions and scheduled changes. Each open item needs a current owner, relevant history and an agreed next action.
Decide which logs, configurations, reports and case records the business needs after the outgoing provider leaves. Confirm what can be exported, who can receive it securely and where it will remain accessible. Don’t assume the new platform can import every annotation or case history.
NIST’s incident-response guidance emphasizes coordination and defined responsibilities with relevant third parties. During a provider change, apply that principle to open incidents as well as future alerts.
Monitoring and recovery
Name the team responsible for monitoring at each stage, its coverage hours and the route for urgent escalation. If a coverage commitment changes during the handover, make that change explicit. Our response-time guide explains how to define what counts as a response and when the clock runs.
Include backup and recovery responsibilities wherever the change affects them. Identify who can access backups, who authorizes and performs recovery, which records must be retained and which checks are needed before the new arrangement is accepted.
For businesses with several locations, record differences in systems, operating hours, local contacts and on-site needs. A successful check at one office doesn’t establish that every branch or remote device is covered.
Use one handover record for each service
Copy this record for each service, system or group whose responsibilities change together. Split it when a location or device group has different conditions.
| Field | What to record |
|---|---|
| Service and scope | The control or service, systems, accounts, devices and locations included. |
| Assigned people | Business approver, technical leads, coordinator and acceptance authority. |
| Outgoing responsibility | Work still covered and the agreed date or condition ending it. |
| Incoming responsibility | Work being accepted and the agreed start date and readiness conditions. |
| Dependencies | Access, licenses, records, vendors or technical changes needed to proceed. |
| Evidence and acceptance | Required checks, their results, who reviews them and the acceptance decision. |
| Interim coverage | The feasible arrangement if checks fail or can’t be completed, including any required provider agreement, coverage, licensing, access limits, business approval, cost and an end or review date. |
| Open exceptions | What remains unresolved, its operational effect, decision owner and deadline. |
| Access closeout | Access to remove or restrict, any temporary access still needed, and evidence that changes were completed. |
Use clear status labels such as not ready, accepted with an approved exception, or accepted. An approved exception should identify the remaining limitation and interim arrangement.
This is an editorial planning tool. Your acceptance alone doesn’t extend the outgoing provider’s contract or start the incoming provider’s monitoring. The providers’ commitments still need to appear in the agreements that govern their work.
Example of a handover that is only partly ready
Consider a hypothetical business changing endpoint-security providers for 86 laptops across three locations.
The current service ends Friday. The incoming provider has completed the agreed enrollment and alert-routing checks for 81 laptops. Both providers confirm when responsibility changes for that group, and the authorized business contact accepts the tested scope. The incoming provider confirms that monitoring is active from the agreed transfer time.
Five field laptops are unavailable for those checks. Their status remains open.
The coordinator proposes a short extension for those five devices. Before it can become the fallback, the outgoing provider must agree to the coverage, licensing, access limits, cost and end date. An installed agent alone doesn’t establish that monitoring continues.
If an extension is unavailable, the technical lead must identify a feasible alternative. That could include taking the affected devices out of service under an approved plan until the work can be completed. Any access restriction must be technically enforceable, and the business must understand its effect on operations.
The record now shows:
- Accepted scope: The 81 laptops that passed the agreed checks.
- Open scope: The five unavailable laptops and the work still needed.
- Decision owner: The operations director, acting within the company’s approval authority.
- Deadline: Thursday, before existing coverage ends.
- Required decision: Agree and implement the extension, or approve and implement a feasible alternative.
Until a feasible interim arrangement is implemented, coverage after Friday for the five devices remains unresolved. An extension can settle that immediate coverage question, but the five-device handover stays open until the required work, checks and acceptance are complete.
Close outgoing access deliberately
Review the outgoing provider’s accounts, delegated permissions, remote-access tools and integrations as the work they support ends. Retain only authorized access needed for a defined purpose and period, with an owner and a removal or review date.
A suspected compromise or another urgent security risk may require earlier restriction or revocation under the incident-response plan. The transition schedule shouldn’t delay necessary containment.
Treat each access path separately. For example, Microsoft’s guidance on reviewing partner administrator privileges notes that a reseller partner can still make purchases for your organization after its delegated Global Administrator role is removed. Microsoft recommends asking the partner to remove that ability in Partner Center. Closing one permission doesn’t prove that the whole relationship has ended.
Record the changes and verify the resulting access. Close temporary exceptions when their purpose ends.
Discuss the handover scope with CTMS
CTMS supports organizations nationwide through remote security management, connected security controls and incident assessment or escalation coordination. The work included in a provider change depends on the agreed engagement. On-site availability is confirmed by location, scope and need.
Talk with CTMS about your cybersecurity-provider transition. Bring your current service end dates, systems, locations and known dependencies so the discussion can focus on the work and coverage that need to be agreed.
