Changing security providers without losing the handover

Decide what actually needs to change

Document why you are considering a transition. The issue may be unclear responsibilities, unsuitable coverage, limited reporting or a different business footprint. Separate problems in the service agreement from problems in the underlying products. Some tools and internal processes may remain useful. Define the desired outcome before writing a replacement specification so procurement does not reproduce the same gaps under a new supplier name. Include renewal dates, notice periods and internal dependencies in the planning assumptions, with legal review where contractual interpretation is required.

Inventory the things that must transfer

Identify configurations, access arrangements, integration knowledge, operating procedures, relevant evidence and open actions. State who owns each item and what the existing agreement allows you to retain or transfer. Data retention and transfer obligations need specific review rather than an assumption that every record can be copied indefinitely. Prepare the minimum information the incoming team needs to understand the current state. Include known blind spots and temporary exceptions; these are often more useful than a polished service overview that describes the intended operation.

Keep one clear incident path during the change

If two providers overlap, clarify which one owns triage and escalation at each stage. If they do not overlap, make the cutover boundary explicit and resolve any gap before relying on the new arrangement. Internal incident contacts must know which channel to use and who can authorise action. Do not allow both suppliers to assume the other owns a case. Walk through a benign example that starts before the transition and remains open afterwards. Record who carries the investigation context and communicates the change to the business owner.

Treat access removal as part of acceptance

Create an access register for the transition with grant, review and removal responsibilities. Confirm how outgoing privileges, tokens, integrations and emergency access will be retired after the agreed handover. Avoid removing essential evidence access before open matters have been transferred, but do not leave broad access in place without a defined reason. The incoming provider should use its own approved arrangements. Document how ownership of automation and configuration changes transfers so future administrators can understand and maintain the environment without relying on undocumented supplier knowledge.

Close the transition with evidence

Require an acceptance record for the new service, a disposition for every open issue and confirmation of the agreed outgoing actions. Verify contact routes and escalation responsibilities after cutover. Schedule an early review to identify differences between the procurement assumptions and the actual environment. Keep unresolved items visible to management if they affect coverage or business decisions. A migration is not complete simply because billing has moved: the client should be able to show who owns the operational work and how important gaps will be resolved.

For the next procurement discussion, read our related guides on comparable service requirements and assessment procurement boundaries. These cover complementary decisions; technical testing still needs its own scope and authorisation.

Prepare your requirements

Use the managed security services RFP builder to select your platforms, describe existing support and review suggested workstreams. You can edit your requirements before sending them through the contact form with an NDA or RFP. Approximate counts and business context are enough initially. Do not include credentials, personal records or live incident evidence. Service hours, delivery capacity and commercial commitments must be agreed in the proposal; submitting a form does not activate a service.