A customer cancels. Billing stops, the account is marked inactive, and everything else stays exactly where it was: their data in your database, their files in your storage, their records in your search index, their API keys still valid, and their users still able to log in until someone notices.
Onboarding a customer is a designed process with an owner. Offboarding one is usually an afterthought, and it is the half that carries the obligations.
This post is what should happen when a contract ends. For whoever owns the product side of the customer lifecycle.
What the contract probably says
Read yours, because the obligations are usually specific and usually missed.
Most enterprise agreements commit you to two things at termination: making the customer's data available for export for a stated period, and deleting it after that period. Both have deadlines, and the second is the one that quietly does not happen.
There is often a third: certifying deletion in writing on request. If you cannot produce that certificate, you are in breach of a term somebody signed, and the customer asking for it is usually doing so because their own auditor asked them.
Define the states
The failure comes from having one state called "cancelled" that means several different things. Make them explicit:
Active. Normal.
Suspended. Access disabled, data retained. The state for non-payment or a dispute, and it is reversible.
Terminated, in retention. The relationship has ended, the customer may export, access is restricted to that purpose, and a deletion date is set.
Deleted. Data removed, with a record of when and what.
Each state has different answers for who can log in, what the API does, whether the data appears in aggregate reporting, and what your support team can see. Writing those down is most of the work, because the ambiguity is what causes data to sit in the first state indefinitely.
Give them their data properly
An export at termination is a commitment, and it is also a moment where the temptation to make leaving difficult is strongest. Resist it: a customer who leaves cleanly is a reference and sometimes a returning customer.
Make it complete, in a format that is usable rather than technically compliant, and available for the period the contract states. Then check who is downloading it: an export at termination is a bulk extraction of data, and it should carry the same logging and verification as any other bulk export.
Then actually delete
This is where the process stops, in most companies, because nothing forces it.
The deletion has to cover the same list as any individual deletion request: primary database, replicas, search indices, caches, object storage, the analytics warehouse, message queue retention, logs, backups on their own schedule, and every third party you forwarded the data to. If you have a deletion pipeline for individual users, a tenant deletion should use it rather than being a separate script written by whoever was asked.
Schedule it as a job rather than a task. A deletion date recorded in the tenant record, with an automated job acting on it and alerting if it fails, is the only version that survives the person who knew about it moving teams.
Revoke everything at the boundary
Easy to forget because it is not data:
- API keys and tokens issued to the tenant.
- OAuth grants their users approved, and grants your product holds into their systems.
- Webhook endpoints you post to, which will keep receiving until removed.
- SSO federation, including any trust relationship configured with their identity provider.
- Shared credentials for any integration set up during onboarding.
- Support access your team holds into their tenant.
That last one matters. A support engineer with impersonation rights into a terminated tenant is access with no customer relationship behind it.
Tell them what you keep and why
You will retain some things legitimately: invoices for statutory periods, audit records of the deletion, aggregate metrics that no longer identify them. Say so specifically at termination rather than leaving it implicit, because a customer who later discovers retained data they were not told about treats it as a breach of trust regardless of whether it was lawful.
A short termination letter covering export availability, the deletion date, what is retained and for how long, and an offer to certify deletion, answers everything before it is asked. It takes one template.
Keep the record
After deletion, keep evidence: the tenant identifier, the termination date, what was deleted from which systems, when, and what was retained with the justification. Not the data, the record of its removal.
This is what you produce when the certificate is requested, and it is what you show an auditor asking how you handle termination. Without it your answer is a description of a process rather than evidence of one.
The concession
Aggressive deletion has a genuine downside: customers return, and a customer who comes back after four months to find everything gone is a worse outcome than one who finds their data waiting. Sales teams will tell you this, correctly.
The reconciliation is the retention window, set deliberately and stated. Thirty or ninety days of full retention after termination, then deletion, gives the returning customer a realistic path and keeps you inside the obligation. What does not work is an indefinite window justified by the possibility of return, which is how a database fills with the data of companies that stopped being customers years ago.
The implication
Every terminated customer whose data you still hold is an obligation without a relationship: no contract revenue, no contact to ask, and the same duty of care.
Count them. If you cannot produce the number quickly, that is the finding, and it is the same question a customer's auditor will ask about you.
