What happens to your data when a virtual IT contract ends?

When a virtual IT contract ends, the organisation’s data remains its responsibility, even if a former provider has hosted, administered or backed up it. A controlled exit should therefore preserve business continuity, establish who controls each dataset, and provide evidence that information has been handled in line with contractual, regulatory and internal requirements.

The first step is to establish the scope of the exit. This normally includes production data, databases, documents, user accounts, configuration files, audit logs, monitoring records, backup sets, disaster recovery copies, encryption keys and data held by subcontractors. Applications and integrations also need to be considered because a data export may be unusable without the associated database schema, permissions model, software version or configuration documentation.

Ownership and control should be documented for each category of information. Business records may belong to the customer, while operational logs, technical documentation or provider-created working files may be subject to different contractual terms. The contract should be reviewed for provisions covering:

• the data and systems included in the handover;
• permitted export formats and any conversion work;
• responsibility for extraction, transfer and validation;
• fees for transition assistance or extended access;
• retention periods imposed by law, regulation or the contract;
• use of subcontractors and the locations in which copies are stored; and
• the procedure for resolving missing, corrupted or incomplete information.

Data should be transferred in formats that the organisation or incoming provider can actually use. A proprietary backup file may technically contain the information but still be unsuitable for normal operations. Depending on the service, a handover may need database exports, original documents, mailbox data, virtual machine images, file permissions, configuration records, encryption-key information and application-specific metadata. The provider should explain any limitations, transformations or omissions rather than presenting an incomplete export as a full handover.

Integrity checks are important during the transition. The receiving party should compare inventories, file counts, database records, timestamps or cryptographic hashes where appropriate. A sample of important files and business processes should be opened and tested, and the results recorded. For structured systems, validation should include relationships between records, user permissions, retention labels and links to connected applications. This can reveal an export that appears complete but cannot support day-to-day work.

Security controls must remain in place throughout the transfer. Access to the data should be limited to named, authorised people, with strong authentication and encryption used for the transfer method selected. Portable media, if used, should be protected and tracked. Credentials, certificates, tokens and encryption keys require separate treatment: they should not be placed in an ordinary data archive without appropriate protection, and any credentials that will no longer be needed should be changed or disabled as part of the transition.

The incoming environment should be prepared before the handover begins. This includes confirming storage capacity, access permissions, backup arrangements, monitoring, malware protection, retention settings and recovery procedures. A staged migration may be preferable where the dataset is large or the systems are business-critical. Running agreed validation checks before the old service is withdrawn reduces the risk of discovering later that a vital dependency was missed.

Some information may need to be retained after operational access has ended. For example, records may be subject to statutory retention, litigation holds, audit requirements or an agreed transition period. Retained material should have a documented purpose, owner, location, access restriction and disposal date. It should not remain indefinitely simply because nobody has confirmed who is responsible for it.

Deletion requires more than removing the visible production copy. Relevant copies may exist in backup repositories, snapshots, replicated storage, disaster recovery systems, test environments, support tools and subcontractor platforms. The applicable retention and backup cycles should be documented, along with the point at which expired copies will no longer be recoverable through ordinary restoration processes. Where deletion cannot occur immediately because of an overriding retention requirement, the data should be isolated, access restricted and its eventual disposal recorded.

A suitable exit record usually includes the final data inventory, transfer dates, recipients, transfer methods, validation results, known exceptions, retention decisions, access changes and disposal evidence. It should also record unresolved risks and the person responsible for each action. This documentation gives the organisation a defensible account of what happened to its information and supports later audits or investigations.

For a small or medium-sized organisation without dedicated transition expertise, an independent review can help test whether the handover is complete and whether the new environment is ready to accept the data. S2 Technology Group can provide advice on the technical and security considerations involved in planning a virtual IT exit, alongside wider managed IT, cloud and cyber security requirements.