Changing IT providers can leave your business with working email and unresolved security responsibilities. The incoming team may be answering support calls while backup access, security alerts or an old administrator account still depend on the outgoing provider.
For an Australian SME owner or managing partner, an IT provider handover checklist should establish three things: the new arrangement works, the business retains appropriate control, and access that is no longer authorised has ended.
Make those conditions part of the handover plan before agreeing that the move is complete. A clear acceptance process gives both providers the same expectations and gives leadership something concrete to sign off.
Start the IT provider handover checklist with responsibilities
Assign one person in your business to accept the handover. That person should understand which services matter to operations and have the authority to resolve scope, timing and cost questions.
Ask both providers to work from the same service list. Include email, business applications, computers, networks, website hosting, domains, backups and security tools. For each service, record who manages it now, who will manage it next, and when responsibility changes.
The Australian Signals Directorate's questions for managed service providers highlight privileged access, secure administration, monitoring and incident readiness. During a handover, ask who owns each of those tasks at every stage.
Its procurement and outsourcing guidance also addresses protecting data after an engagement ends. That guidance is written for government and large organisations. It offers useful principles for an SME handover, rather than a blanket legal checklist for every business.
Cubit Cyber recommends agreeing the following acceptance checks with your providers:
| Area | Evidence to request before sign-off |
|---|---|
| Critical services | A service list with an owner and transfer date for each item |
| Business control | Verified account ownership, recovery contacts and authorised administration |
| Security coverage | Confirmation that agreed protection and alert handling operate after the change |
| Recovery | A successful restore check using the new access arrangements |
| Outgoing access | A reviewed record of removed access and any approved exceptions |
| Unfinished work | An owner, deadline and business decision for each material gap |
Schedule work around business constraints. Payroll, settlements, patient appointments and month-end reporting may justify different migration windows. Agree what would cause the team to pause or reverse a change before it starts.
Confirm business control of critical services
Ask the incoming provider to demonstrate the access it will need to administer each critical service. Include a recovery route if its normal administrator account becomes unavailable.
Start with services that other systems depend on: your domain registration, the settings that direct website and email traffic, central sign-in service, backup platform and password vault. Then work through your operational applications.
Ownership and login access are different checks
A provider may be able to sign in without your business having clear control of the subscription or recovery process. Conversely, an invoice in your business name does not establish that the new team can administer the service.
For each important platform, ask:
- Which organisation holds the account or subscription?
- Who can approve a transfer, change an administrator or recover access?
- Which email addresses and phone numbers receive recovery messages?
- Does the contract allow the proposed transfer, and are fees or notice periods involved?
- Where will the business keep the current recovery instructions?
Not every subscription can simply move between providers. Record any replacement or migration needed, including the effect on stored data and service continuity.
Have the IT team protect emergency access with appropriate authentication, restricted use and logging. Business control should not mean circulating an administrator password among directors. The objective is an authorised, tested recovery path with a clear custodian.
Keep protection and alert handling continuous
Treat each security function as a separate handover item. Agree who handles device protection, software updates, suspicious sign-ins, backup failures and incident escalation during the transition.
ASD's cloud security guidance for tenants describes security as a shared responsibility. Use the handover to make your business's responsibilities explicit, including work performed on your behalf.
Ask the incoming provider for a comparison between the devices and services it expects to manage and those actually reporting into its tools. Give missing devices an owner and a follow-up date. Include laptops used by travelling or part-time staff.
Where security products are changing, let the technical teams plan a supported migration sequence. Some products cannot safely run together. Others need a period of overlap. The acceptance question is whether the agreed protection remains effective through that sequence.
Test the new alert destination using an agreed, safe method. Record who receives the alert, who acts on it and what happens outside contracted support hours. A forwarded mailbox alone does not establish that someone has accepted responsibility.
Update the contacts in your incident response plan, including a way to reach the right people if business email is unavailable.
Prove that backups remain usable after the move
Before ending an old backup arrangement, establish what happens to its existing recovery points. Ask whether they transfer, remain available under a separate agreement or expire when the service ends.
Also confirm who controls the backup account, where recovery keys are held if required, and which software or licences are needed to restore information. Record any gap between the last old backup and the first accepted backup under the new arrangement.
ASD's backup guidance recommends testing restoration. For a provider transition, make that test use the access and arrangements that will remain after the outgoing team leaves.
Define a recovery acceptance check
Choose a representative business system or dataset with the people who use it. Ask the incoming team to restore it into an agreed safe location, then have the business owner check that the result is usable.
Record:
- what was restored and which recovery point was used
- who performed the restore and how they obtained access
- how long it took and what manual steps were needed
- what the business user checked
- any missing information, dependencies or follow-up work
A small restore check proves only what was tested. It does not establish that the whole business can recover within its required timeframe. If recovery depends on several connected systems, a broader exercise may be appropriate through a Cyber Resilience Programme.
Close outgoing access and agree what happens to retained data
Once replacement access is working, have the technical teams review every route used by the outgoing provider. Include named accounts, delegated administration, remote support tools and credentials used by software integrations.
Use a controlled removal plan. Identify dependencies before changing shared credentials or removing tools, then verify the affected business functions still work. Platform behaviour varies, so the team should check whether existing sessions or other access mechanisms also need revocation.
Keep dated evidence of the changes. If the outgoing provider still needs access to finish a task, record its purpose, permitted scope, approver and expiry date. Review the exception when the task ends.
Separately, agree what happens to information held outside your live systems, such as support-ticket attachments, diagnostic exports and historical backups. Identify what will be returned, what can be deleted, and what must remain protected for a justified period.
For businesses covered by the Australian Privacy Principles, the OAIC's APP 11 guidance requires reasonable steps to destroy or de-identify personal information no longer needed for a permitted purpose, subject to exceptions including legally required retention. Confirm applicable retention requirements before instructing deletion; obtain legal advice where those requirements are unclear.
Sign off against evidence and outstanding risks
Hold a short acceptance meeting with your business owner and the incoming provider. Involve the outgoing team where open handover items require it.
Review the service list and evidence together. Separate completed work from unresolved gaps. For each material gap, identify the business consequence, any temporary safeguard, the person responsible and the date it will be checked again.
Store the handover record somewhere your business controls. It should be understandable to someone who was not involved in the migration and useful if you change providers again.
Cubit Cyber works alongside existing IT teams and providers to examine security risks independently. If the handover exposes unclear administrator access, missing control evidence or recovery dependencies, review the scope of a Breach Prevention Assessment to determine whether independent validation would help resolve them.