Maintain a live inventory of former partners, the data they once held, and any deletion or protection attestations they provided. Ended contracts do not erase legacy exposure, especially when records remain in old systems or support workflows. Require confirmation of deletion, review residual access paths, and include legacy integrations in vendor risk and incident response planning, not just active suppliers.
What should organisations retain after a supplier or partner relationship ends?
Ended relationships still leave an audit and exposure trail. The practical question is not whether the contract is closed, but whether the organisation can prove what data was shared, who still had access, what deletion or retention commitments were made, and whether any residual integration or support path remains capable of reaching the data.
That makes offboarding a records problem as much as an access problem. A clean exit depends on knowing the historical data footprint, the systems that once held it, and the evidence that the third party actually removed or protected it. For organisations managing external users and suppliers, NHIMG’s Third-Party, B2B and Contractor Access Guide is a useful reference point for how partner access should be time-bounded and reviewed.
Why historical customer data remains exposed after the contract ends
Contract termination rarely means data disappearance. Historical customer records may persist in exports, backups, support queues, replicated CRM objects, ticket attachments, shared drives, analytics copies, or vendor-controlled archives. If those locations are not enumerated, the organisation can lose visibility into where the data continues to exist and whether it remains protected.
The risk is amplified when a former partner had integration tokens, delegated support access, or a synced copy of production records. NHIMG’s IAM and IGA Basics helps frame why inventory, entitlement review, and revocation are part of the same lifecycle control, not separate tasks. For partner offboarding specifically, the same logic applies to data possession, not just login status.
One common failure mode is assuming the vendor’s contractual deletion promise is enough. In practice, organisations need to know what was deleted, when it was deleted, whether backups were excluded, and whether any downstream processor or subcontractor still retained a copy. When the original relationship ends, the data may still be reachable through old support tooling or retained integration paths unless those paths are explicitly retired.
How organisations should handle deletion proof, residual access, and legacy integrations
Start with a live inventory of the former partner, the specific data sets it once held, and the systems or workflows that delivered them. Then require a deletion or return attestation that is tied to those named data sets, not a generic offboarding statement. Where the partner handled credentials, tokens, or API access, confirm those secrets were rotated or revoked and that any shared accounts were removed from current runbooks.
Legacy integrations deserve the same scrutiny as active suppliers. Old SSO trust, stale API keys, support portals, and file-transfer jobs can outlive the commercial relationship and continue to expose customer data long after the business owner thinks the vendor is gone. NHIMG’s Top 10 NHI Issues is relevant here because stale access, over-privilege, and poor lifecycle control are often the mechanism that keeps these paths alive.
For formal vendor governance, the control point is not only the contract sign-off. It is the combination of deletion evidence, access revocation, residual system review, and incident-ready documentation showing what data the third party could have retained. That is why vendor risk should include former partners, not only active suppliers.
Risk and Threat Considerations
Historical customer data can remain exposed through backups, support tooling, replicated records, or forgotten integrations even after the business relationship is over. The danger is that an organisation may believe exposure has ended when the data is still reachable through a legacy path or a retained copy outside its direct control.
Failure mechanism: Residual access, undeleted copies, stale credentials, or unrevoked trust links let a former partner continue to access or recover customer data after offboarding.
Impact: That can create privacy exposure, breach notification obligations, contractual disputes, and a larger blast radius if the former partner is later compromised or mishandles retained data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Former partner access often persists through stale tokens, keys, or shared secrets. |
| AC-2 — Account Management | Residual third-party access must be removed and evidenced when relationships end. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Deletion attestations and residual access checks need traceable evidence. | |
| Recommendation — Rotate and revoke all partner-issued authenticators before closing the offboarding record. Disable or remove former partner accounts and document the revocation date. Review logs and attestations to confirm data removal and detect lingering access paths. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships must cover data handling and post-contract security obligations. |
| A.5.20 — Addressing information security within supplier agreements | Contracts should define deletion proof, return, and residual-data handling requirements. | |
| Recommendation — Extend supplier security terms to cover retention, deletion, and offboarding evidence. Require contractual deletion and return obligations for supplier-held customer data. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Former partners are still service providers for historical data and should be governed as such. |
| Recommendation — Track supplier offboarding, data return, and access removal through service-provider controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Ended relationships can leave identities, tokens, or data access active after separation. |
| NHI-07 — Long-Lived Secrets | Residual access often survives through long-lived keys, tokens, or API credentials. | |
| NHI-09 — NHI Reuse | Shared or reused partner credentials can preserve unintended access across systems. | |
| Recommendation — Offboard partner identities and validate removal of all access paths and retained secrets. Inventory and expire partner secrets that could still reach historical customer data. Eliminate reused partner credentials and replace them with uniquely scoped access. | ||
Practitioner Guidance
What to verify: Confirm the exact datasets shared with the former partner, the deletion scope they accepted, and whether backups, support archives, and subcontractors were included. If the answer is vague, treat the offboarding as incomplete.
Decision rule: If the partner once had access to production customer records or credentials, require proof of deletion or rotation before closing the file, not after an incident forces the question.
What good looks like: The organisation can produce a current inventory of former partners, their historical data holdings, the dates and method of deletion attestation, and the residual integration paths that were reviewed and retired.
Practitioner takeaway: Treat partner offboarding as a data-lifecycle control with evidence, not a procurement closeout, because legacy exposure usually persists in the places teams forget to inventory.
Related resources from NHI Mgmt Group
- How should organisations modernise identity security after a third-party breach exposes employee or customer data?
- How should organisations build a first-party data strategy that still works after third-party cookies disappear?
- What do security teams get wrong about third-party access after a relationship ends?
- How should organisations decide when to grant access to third-party users and bots in customer and partner environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
