You cancelled the contract. Did you cancel the access?

When you onboard a vendor, there's usually a project. Someone is leading the implementation, credentials are being created, integrations are being built, and access is being provisioned. It's a visible, active process that people are paying attention to.

Offboarding is the opposite. It happens at the end of a relationship, often when the company has moved on to something else, sometimes after the person who managed the original relationship has left. The cancellation email gets sent, the payment stops, and then — nothing. The access that was provisioned during onboarding just sits there, dormant but present.

The problem compounds over time. A company that's three years old and has been growing quickly has probably changed its vendor stack significantly. Tools get replaced, contracts get cancelled, integrations get deprecated. But the credentials and access permissions from those old relationships accumulate unless someone is actively cleaning them up. By the time a penetration test or audit surfaces the issue, there can be years' worth of stale vendor access sitting in your systems.

These aren't theoretical risks. Supply chain attacks via compromised third-party credentials have become one of the most common attack vectors for sophisticated threat actors. The SolarWinds attack, the Kaseya incident, and numerous smaller-scale supply chain compromises all involved attackers gaining access via third-party relationships — in some cases, via former vendor relationships where access had not been properly revoked.

Security risk is the obvious concern with poor vendor offboarding. But the compliance implications are equally significant — and are increasingly the focus of SOC 2, ISO 27001, and financial services audits.

SOC 2 and vendor offboarding

SOC 2 CC9.2 — the vendor management control — includes requirements around how you terminate vendor relationships. Auditors are looking for evidence that when a vendor relationship ends, access is revoked systematically, data is handled per contractual terms, and the termination is documented in your vendor register. The key word is evidence: not a policy that says you do this, but documentation showing that it has been done for specific terminated relationships during the audit period.

ISO 27001 and supplier offboarding

ISO 27001:2022 A.5.19 explicitly covers the termination or change of supplier relationships. Auditors expect to see a documented offboarding process — what happens when a supplier relationship ends, who is responsible for revoking access, how data deletion is confirmed, and how the supplier register is updated. The 2022 revision places greater emphasis on this than the 2013 standard, and it's an area where audit findings have become more common.

GDPR and data processor offboarding

Under GDPR, when you terminate a relationship with a data processor — a vendor that handles personal data on your behalf — you're required to ensure that your personal data is either returned or deleted, as specified in your data processing agreement. Without a systematic offboarding process, you have no evidence that this obligation has been met. In the event of a data subject access request or a regulatory inquiry, this gap becomes very visible.

A proper vendor offboarding process doesn't need to be bureaucratic. It needs to be systematic — a defined set of steps that happen every time a vendor relationship ends, with documentation that proves they happened. Here's what that looks like:

Access revocation

• Revoke all API keys and tokens issued to the vendor
• Remove OAuth connections and application authorisations
• Disable or delete user accounts created for vendor personnel
• Remove webhook endpoints pushing data to vendor systems
• Revoke network access permissions and IP allowlist entries
• Remove vendor personnel from shared systems (Slack, Notion, etc.)

Data handling

• Request data deletion or return per the contractual terms
• Obtain written confirmation of data deletion from the vendor
• Retrieve any company data held by the vendor that you want to retain
• Confirm deletion of personal data per DPA terms and document it
• Check for any data that may have been shared outside the primary system

Documentation and closure

• Mark the vendor as inactive in your vendor register (not deleted)
• Record the termination date and reason
• Document the access revocation steps taken and when
• File the final correspondence and any termination agreement
• Update any business continuity or operational resilience documentation that referenced the vendor

• No process at all. The most common situation: the contract is cancelled, payment stops, and nothing else happens. Nobody owns the offboarding. No access is revoked. No documentation is created. The vendor relationship just goes quiet.
• Partial offboarding — the obvious bits only. The main user account gets disabled, but the API credentials that a developer created eighteen months ago remain active. The commercial relationship is terminated, but the webhook that was set up during integration still fires. Offboarding that covers the visible parts but misses the technical residue is almost as risky as no offboarding at all.
• The former employee problem. The person who managed the vendor relationship — and who knew about all the integrations and credentials they set up — has left the company. Offboarding becomes a forensic exercise: trying to reconstruct what access was granted during an onboarding you weren't part of.
• No data deletion evidence. The vendor is told to delete your data. They say they have. Nobody has it in writing, and nobody has checked. For GDPR purposes, the obligation to ensure your processor has deleted personal data isn't satisfied by a verbal assurance from an account manager.
• The vendor register is cleaned up instead of archived. The vendor is deleted from the register when the relationship ends, destroying the documentation of the relationship and the offboarding process. Auditors need to see a history of vendor relationships — including terminated ones — not just the current active list.

Vendorapp is built around a core principle of offboarding documentation: when a vendor relationship ends, the vendor is paused — not deleted. The full history of the relationship, the assessments, the contract records, and the offboarding documentation are preserved indefinitely and are always accessible to auditors.

1. 1

   Structured offboarding workflow

   When you mark a vendor as inactive, Vendorapp guides you through the offboarding steps: access revocation, data handling, documentation. Nothing is marked as complete until the checklist is done. The workflow is the process — which means the process happens consistently, regardless of who's doing it.

2. 2

   Paused status — preserved, not deleted

   Inactive vendors are paused in Vendorapp, not deleted. Their full history — assessments, contracts, relationships, offboarding record — is preserved and searchable. When an auditor asks for your vendor history including terminated relationships, it's all there. No reconstruction required.

3. 3

   Offboarding documentation in the vendor record

   Notes, confirmations, and evidence from the offboarding process — including data deletion confirmations — are stored in the vendor record alongside the relationship history. The audit trail is complete and self-contained.

4. 4

   Smart alerts for offboarding triggers

   When a contract expires or is cancelled, Vendorapp can trigger an offboarding alert — prompting the process before the relationship has fully wound down, when memories are still fresh and access revocation is easiest to do thoroughly.

5. 5

   Reactivation when needed

   If a vendor relationship is restarted — common with contractors and specialist service providers — a paused vendor can be reactivated rather than rebuilt from scratch. The full history is available, and a new onboarding assessment can be run on the existing profile.