The Departure Trail: A UK Procurement Audit of SaaS Offboarding

Offboarding is often treated as a closing administrative task: a ticket is raised, a manager confirms the final day, and the service desk disables an account. For UK procurement teams, that view is too narrow. Every leaver tests whether the software estate can surrender access, cost and data in the right order. When the process fails, the consequences are rarely dramatic at first. They appear later as unused licences on a renewal quote, an unresolved subject access request, or a supplier holding personal data that the business assumed had been deleted.

The practical response is to audit the departure trail before the next leaver creates it. That means selecting a recent departure, reconstructing what happened across identity, licensing, data and supplier records, and converting the findings into a repeatable test plan. The exercise belongs with procurement and operations because it crosses contractual, financial and compliance boundaries that no single IT team controls.

Offboarding as a buying problem

SaaS agreements frequently specify what happens when a user leaves, but buyers rarely read those clauses alongside the internal leaver process. The gap matters. A contract may allow the customer to reassign a licence, but only through an administrator console and only if the account is suspended rather than deleted. Another may permit data export for a fixed period after termination, yet say little about an individual employee's departure. Procurement should map supplier terms to the organisation's own identity and records practices, not assume that a standard offboarding workflow satisfies both.

The audit should begin with a sample leaver from the past six months. Gather the HR end date, the service desk ticket, the identity provider record, the application administrator log, the licence record and any data retention instruction. Where those sources disagree, the disagreement is the finding. A common example is an account disabled in the identity provider while a local application login remains active because it was created outside single sign-on. Another is a licence removed from the finance system but not from the vendor portal, leaving the subscription quantity unchanged at renewal.

Suspension is not deletion

Disabling an account is an access control action. Deleting it is a records management action. The two should not be conflated. Suspension usually preserves the account identifier, mailbox, files and audit history so that work can be reassigned and legal or regulatory obligations can be met. Deletion removes the account and may trigger supplier-side retention periods or irreversible data loss. The correct sequence depends on the role, the data held and the organisation's retention schedule.

A useful test is to ask what remains accessible to the leaver after the final day. The answer should be nothing, including through personal devices, cached credentials, API tokens, shared passwords and third-party integrations. Procurement should also ask what remains accessible to the organisation. If the account is suspended, can a manager still retrieve business records? If it is deleted, does the supplier preserve a copy, and for how long? These questions turn a technical setting into a contractual and compliance issue.

Reclaiming licences without losing evidence

Licence reclamation is where offboarding meets budget. Many SaaS products are sold in named-user tiers, and an unused seat may be reassignable or may simply be wasted until renewal. The audit should establish whether the supplier permits reassignment, whether a suspended account continues to consume a licence, and whether any minimum commitment prevents reduction. For products billed by consumption, the relevant question may be whether the leaver's API keys or automated jobs continue to generate charges.

Do not reclaim a licence before confirming that the associated data has been preserved where necessary. A leaver's account can hold contracts, customer records, research or correspondence that the business needs. Reclaiming the seat may remove the simplest route to that material. A controlled process might suspend access, transfer ownership of files to a manager, export required records, then reassign the licence and schedule deletion in line with the retention schedule.

Retention, erasure and UK GDPR

UK GDPR and the Data Protection Act 2018 require personal data to be kept only as long as necessary for the purpose for which it was collected. Offboarding is a point at which that principle becomes concrete. The organisation must decide what employee data to retain, for how long and on what lawful basis. It must also be able to respond to rights requests, including access and erasure, across the SaaS estate.

This is not only an HR records question. A departing employee may be a data subject in their own right and may also have created records about customers, suppliers or colleagues. The audit should identify where those records live, who inherits them and how retention is applied. Supplier terms matter here: a processor may delete data after a set period, but the controller remains responsible for the decision. Procurement should check whether the contract includes deletion or return obligations, whether backups are excluded, and whether the supplier requires a written instruction before acting.

What supplier terms actually say

Read the offboarding clauses as if they were part of the purchase. Look for the definition of an authorised user, the process for reassignment, notice periods for reducing quantities, data export formats, deletion timelines and any charges for retrieval or early termination. Check whether the supplier treats a departed employee as a security incident requiring notification, and whether administrator accounts are subject to separate controls.

Where the terms are silent, record the gap. Silence is not necessarily a reason to reject a supplier, but it is a reason to design an internal control that compensates for it. For high-risk systems, the buyer may seek a contractual commitment on deletion or a documented exit plan before renewal.

A pre-departure test plan

Before the next leaver, run a tabletop exercise and a live sample audit. Use the following checklist:

• Identify every application the leaver can access, including shadow SaaS discovered through single sign-on logs or expense records.
• Confirm the identity provider suspension time and compare it with the HR end date.
• List local accounts, API tokens and shared credentials that bypass single sign-on.
• Confirm which licences are reassignable and whether suspension or deletion affects billing.
• Identify business records that must be transferred and the manager responsible for them.
• Check retention obligations and any legal hold before deleting data.
• Confirm supplier deletion or export terms and the process for instructing them.
• Test a subject access or erasure request across the sample leaver's applications.
• Record the evidence and assign an owner for each gap.

The next leaver is the test case

The value of this audit is not a perfect offboarding form. It is evidence that access, cost and data are being handled deliberately. UK organisations should treat the next departure as a controlled test of the software estate, with procurement watching the contractual edges and operations watching the process. If the trail cannot be reconstructed after the event, it is unlikely to hold up before the next leaver arrives.