Changing or Leaving a Supplier

A migration moves staff data between systems. During it, the data exists in both, in extracts, in test environments and in somebody's spreadsheet, and the obligations continue throughout.

The supplier test in “Changing or Leaving a Supplier” should cover the real data flow, not only the contract summary. Organisations considering this reference page for does microsoft teams track your activity should document hosting, subprocessors, permissions, deletion and export before rollout, then verify those controls during renewal and exit.

What happens during

Data is extracted, transformed, loaded, checked and reconciled.

For a separate benchmark relevant to “Changing or Leaving a Supplier”, consult the FTC data-security guidance. Use it to test purpose, data flow, retention, access and response procedures rather than substituting a generic checklist for the organisation’s actual records.

Each step creates a copy. Extracts sit on a laptop, a test load sits in a sandbox with real data, a reconciliation spreadsheet circulates by email.

These are the copies that survive the migration, because nobody listed them and the project closed when the new system went live.

Test data

Using real staff data to test a new system is common and is processing for a new purpose.

Where it can be avoided, use synthetic data. Where it cannot — and sometimes it genuinely cannot — restrict the environment, limit who has access, and delete it when testing ends.

A test environment containing a full copy of the payroll, retained indefinitely with wider access than production, is a finding waiting to be made.

Getting the data out and deleted

The contract should require return or deletion at your choice. Use both: return what you need, then require deletion of everything, confirmed in writing with a date.

Then ask about their sub-processors, because the deletion obligation flows down and they frequently have not thought about it.

Your own people's access

Staff with logins to the system you left.

Revoked, as part of the exit, or they retain access to a holding of staff data at an organisation you no longer have a contract with.

Updating the documents

The departed supplier is still named in the record of processing and in the privacy notice, and the new one is in neither.

This is the commonest way the documents fall out of date, and it is why the consistency check exists.

The evidence

A deletion confirmation, dated, filed.

Two years later somebody asks whether a former supplier still holds staff data. The confirmation answers it in a sentence; without it the honest answer is that nobody knows.

Test data, which is real data

Using live staff records to test a new system is processing for a new purpose. Where synthetic data cannot be used, restrict the environment, limit access, and delete when testing ends.

Updating the two documents

The departed supplier is still named in the record and the notice, and the new one is in neither. This is the commonest way documents fall out of date between reviews.

Where the copies survive

Extracts on a laptop, a test load with real data, a reconciliation spreadsheet circulating by email. These outlast the migration because nobody listed them and the project closed at go-live.

Revoking your own people's access

Staff with logins to the system you left retain access to a holding of staff data at an organisation you no longer have a contract with.

The evidence you will want later

A deletion confirmation, dated, filed. Two years on somebody asks whether a former supplier still holds staff data; the confirmation answers it in a sentence.

Your own staff's access

Revoked as part of the exit, or they keep access to a holding of staff data at an organisation you no longer contract with — which is nobody's responsibility and everybody's exposure.