What should an outsourced IT exit plan include?

An outsourced IT exit plan is a practical, agreed procedure for transferring technology responsibilities from one provider to another, or back to the organisation, without creating avoidable operational, legal or security risks. It should be specific enough for someone unfamiliar with the environment to understand what must happen, who is responsible, what evidence is required and how the transition will be accepted.

Define the circumstances and scope of the exit. The plan should explain which events trigger it, such as contract expiry, termination for cause, a change in business requirements or an organisational restructure. It should identify the services covered by the transition rather than assuming that every activity is included. For example, service desk support, infrastructure management, cloud administration, connectivity, backup operations, security monitoring and project work may each have different transfer requirements.

The contract should also state the notice period, relevant termination rights, dependencies on other agreements and any charges for transition assistance. This prevents disagreements about whether handover work is part of the existing service or an additional engagement. The organisation should check these provisions before giving notice, particularly where the provider controls systems that are essential to day-to-day operations.

Record the environment in a usable form. A good plan requires the provider to maintain accurate documentation throughout the relationship, not create it only after notice has been given. The handover pack may need to include:

• an up-to-date list of servers, endpoints, network equipment, cloud services and other managed assets;
• network diagrams, system relationships and descriptions of important integrations;
• details of suppliers, support agreements, renewal dates and relevant account owners;
• configuration records, standard operating procedures and known exceptions;
• backup arrangements, restoration procedures and records of recent tests;
• open incidents, unresolved problems, planned changes and known technical risks; and
• licence, subscription and warranty information, including ownership and transfer restrictions.

Documentation should be supplied in formats the organisation or incoming provider can use and maintain. Screenshots alone may not be sufficient if the new team needs structured exports, editable diagrams or machine-readable configuration data. The plan should specify how the receiving party will confirm that the material is complete and intelligible.

Map identity, permissions and ownership. The transition process should distinguish between accounts owned by the organisation and accounts created or controlled by the outgoing provider. It should identify administrative roles, service accounts, recovery methods, multifactor authentication arrangements, certificates, encryption keys and privileged access paths. Credentials should not be exchanged casually by email or placed in ordinary documents. Instead, the parties should agree a secure transfer method, followed by credential rotation and removal of unnecessary privileges.

Ownership should also be clear for domains, tenant environments, hosted services, telephone systems, backup repositories, security tools and software subscriptions. Where a service cannot be transferred directly, the plan should state whether it will be recreated, migrated or replaced, and who bears responsibility for the associated risk and cost.

Set out a transition timetable and decision points. A useful exit plan breaks the work into phases, with named owners and dependencies. A typical sequence may include:

1. confirming the termination date, scope and transition contacts;
2. freezing unnecessary changes while preserving essential maintenance;
3. collecting and checking documentation, inventories and operational records;
4. provisioning the incoming team and transferring control of relevant platforms;
5. testing core services, monitoring, backups, remote access and support routes;
6. resolving gaps or disputed information; and
7. recording formal acceptance and closing the outgoing provider’s access.

Each stage should have an owner from the departing provider, the organisation and, where applicable, the incoming provider. Include target dates, dependencies, escalation routes and a method for approving changes to the timetable. The plan should also identify a final cut-off for new work and explain how urgent incidents will be handled during the overlap.

Plan for continuity and operational risk. The organisation should identify services that cannot tolerate an unmanaged handover, including authentication, internet connectivity, email, line-of-business applications, backups, endpoint protection and access to premises or equipment. For each service, document the fallback arrangement, technical contact, recovery procedure and test required before the outgoing provider is removed.

Particular attention is needed where the outgoing provider supplies a proprietary tool, hosts a system on its own platform or relies on undocumented knowledge held by a small number of individuals. The exit plan should require knowledge-transfer sessions, recorded demonstrations or supervised operational checks where written records do not fully explain the environment.

Include security, privacy and compliance controls. The plan should define how information is classified during the transition, who may access it and how transfer activity will be logged. It should cover the return, migration or secure disposal of personal data, confidential records, logs, backups and temporary working files. Retention requirements, legal holds and contractual duties must be considered before anything is deleted.

At the end of the handover, the organisation should obtain confirmation that the outgoing provider’s accounts, tokens, remote-management agents, firewall rules and other access mechanisms have been disabled or removed. Where deletion is required, request suitable evidence rather than relying solely on an informal statement. The receiving party should then review privileged access and establish its own monitoring and approval processes.

Define acceptance and evidence. The plan should say what constitutes a successful exit. This may include a reconciled asset register, verified administrative control, successful test of critical systems, receipt of agreed documentation, confirmation of data handling and closure of outstanding actions. Record test results, exceptions, decisions and sign-off in a transition log.

Finally, retain the exit plan with the outsourcing contract and review it periodically. Technology estates change, so a document written at the start of a relationship can become inaccurate if it is not updated after projects, acquisitions, platform changes or changes in responsibility. Treating exit planning as part of normal IT governance makes a future provider transition a controlled business process rather than an emergency exercise.