Odds are, at least one vendor you’re no longer working with still has some form of access to your environment. Maybe it’s a shared credential that never got rotated, or an integration that’s still running in the background because nobody remembered to turn it off.
It’s the kind of loose end that’s easy to deprioritize until an audit finds it or something worse forces the conversation.
The problem is that when vendor access becomes a breach, it’s a particularly expensive one to clean up. Third-party incidentscost about 40% more to remediate than data breaches that originate internally.
If you’re here, you’re likely trying to close that gap before it becomes a problem, or you may have already had a close call. This checklist breaks down the security, legal, and IT steps you need to offboard vendors without leaving doors open behind them.
Phase 1: Audit and preparation (30–60 days out)
The vendor offboarding process should be well underway before the contract formally ends. Giving yourself a 30–60 day runway creates space to audit what access exists, loop in the right people, and avoid any last-minute scramble.
This phase is about building a clear picture of the vendor relationship – what they can access, what data they’re holding, and what needs to happen for a clean exit.
This phase typically involves three main areas:
Step 1: Access inventory
Before you can revoke access, you need to know what access exists.
That sounds obvious, but vendor access tends to accumulate in ways that aren’t always well-documented. This is especially the case for longer relationships where the scope expanded over time.
Start by building a complete inventory of vendor information across these categories:
Access type | What to look for |
System accounts | Named user accounts in internal tools, admin consoles, and databases |
SSO/directory access | Third-party vendor users provisioned through your identity provider |
API keys and tokens | Credentials issued for integrations, automations, or data syncs |
Shared credentials | Logins shared via password managers, email, or Slack |
Cloud environments | IAM roles, service accounts, or direct console access in AWS, GCP, Azure |
Third-party integrations | OAuth connections, embedded apps, webhooks |
Physical access | Badges, building keys, server room access |
Data repositories | Shared drives, cloud storage folders, code repositories |
And don’t rely solely on what’s documented. The business owner who worked with the vendor directly will often have context on access that was granted outside of normal channels.
If you’re not sure where to start, one Reddit user shared a practical approach: policy requires that vendors request access, and then they set an expiration date for their account for a certain number of days or weeks depending on the project.
Step 2: Contract and risk review
While IT maps out access, legal should be conducting due diligence on the vendor contract itself. The goal is to understand what you’re obligated to do, what the vendor is obligated to do, and what happens to data, IP, and ongoing commitments once the business relationship ends.
There are a few key areas to work through:
- Termination terms: What are the notice requirements? Is there a penalty for early termination, or any fees tied to ending the relationship ahead of schedule?
- Data handling: What happens to your data after the contract ends? Is the vendor obligated to delete it, return it, or certify that it’s been destroyed? What are the retention requirements and timeline?
- Surviving obligations: Which clauses continue after the vendor termination process? NDAs and confidentiality terms often outlive the contract itself.
- Compliance requirements: If the vendor handled regulated data (GDPR, HIPAA, PCI-DSS), what documentation do you need from them to satisfy your own compliance obligations?
- Intellectual property: Who owns what was created during the engagement? Is there anything the vendor retains rights to that you’re currently using?
- Outstanding financials: Are there unpaid invoices, prepaid credits, or refunds owed in either direction?
The point is to avoid surprises once offboarding is underway. A clause you didn’t know about can stall the whole process or create liability down the line.
PRO TIP 💡: ConductorOne’s Unified Identity Graph shows every system and data source a vendor can access in one view. Having this inventory ready makes the contract review faster because legal can map access against data handling clauses and compliance requirements without waiting for IT to manually compile a list.
Step 3: Transition plan
What happens after the vendor exits will shape how you ensure a smooth transition. The planning looks different depending on whether you’re handing off to someone new, absorbing the work internally, or shutting things down entirely.
Here are a few scenarios you need to consider:
Scenario | Focus | Key questions to answer |
Replacing with a new vendor | Handoff and overlap | Can both vendors operate in parallel during the transition? What documentation, credentials, and data need to be transferred? How much ramp-up time does the new vendor need? |
Bringing the function in-house | Knowledge transfer | Are the vendor's processes documented well enough to pick up? What tools or skills gaps need to be filled before cutover? Who internally is taking ownership? |
Consolidating with the existing vendor | Scope expansion | Does your current vendor have the capacity to absorb this work? What's the timeline to expand the engagement? Are there contract or pricing changes needed? |
Sunsetting the service | Controlled shutdown | What needs to be archived before access ends? Are there downstream dependencies, such as reports, integrations, and workflows, that will break? Who needs to be notified? |
Temporary pause | Preservation | How do you maintain documentation and institutional knowledge during the gap? What's the plan if the pause becomes permanent? Who monitors for issues in the meantime? |
Whichever scenario you’re dealing with, set a clear cutover date and work backward from there. Outline dependencies, assign owners for each piece of the transition, and build in buffer time for things that don’t go as planned.
A rushed handoff creates exactly the kind of gaps this whole process is meant to prevent.
Phase 2: Notification and communication
Once you’ve taken inventory and aligned internally, it’s time to start notifying the relevant parties.
The vendor needs formal notice, internal teams need to know what’s changing, and anyone downstream who depends on the relationship needs a heads-up before things start shutting down.
Here’s how to approach each stage:
Step 4: Formal legal notice
This is the part that makes it official. The termination notice needs to be clear, specific, and properly documented. Anything vague or incomplete gives the vendor room to push back or drag their feet.
A good notice should include:
- The termination date
- Reference to the specific termination clause
- Data protection and handling expectations with deadlines
- The access revocation timeline
- Any outstanding obligations on either side
- A designated point of contact for questions
Send it however the contract specifies (usually certified mail or email with read receipt), and keep copies of everything.
That’s the straightforward part. Where things tend to go wrong is:
Common pitfall | What happens | How to avoid it |
Vague termination date | Vendor interprets timeline loosely, delays handoff | Use a specific calendar date, not "end of quarter" or "30 days from receipt." |
Missing contract reference | Vendor disputes the validity of the notice | Cite the exact agreement and termination clause |
No data handling deadline | Data sits on vendor systems indefinitely | Specify what must happen (return, deletion, certification) and by when |
Wrong delivery method | Notice is technically invalid under contract terms | Check the contract for the required notification method before sending |
No confirmation of receipt | No proof that the vendor received the notice | Use certified mail, read receipts, or require written acknowledgment |
Step 5: Internal alignment
With the formal notice sent, the next step is aligning internal stakeholders on what’s happening and when. Vendor offboarding spans multiple departments, and communication gaps only lead to gaps in execution.
Here’s how you can coordinate it:
Team | What they need to know |
IT / Security | Timeline for revoking access, which systems and accounts are affected, and any coordination needed with the vendor before the cutoff |
Finance | When to stop payments, any outstanding invoices or credits to reconcile, and refund expectations |
Procurement | Contract end date, vendor status updates for internal records, and whether a replacement is in progress |
Legal | Confirmation that notice was sent, any outstanding obligations, or potential disputes to monitor |
Business owner | Full timeline, transition responsibilities, who's picking up the work the vendor was handling |
End users | What's changing for them, when it takes effect, and who to contact with questions |
In practice, this coordination looks different at every organization. Most importantly, have one person coordinate the offboarding and make sure everyone knows who that is.
Without a clear owner, you end up with conflicting messages going to the vendor, duplicated work, or worse, someone still sharing sensitive information after the relationship has ended.
Phase 3: Access revocation
At this point, the vendor has been notified, and your teams are aligned. Now, you can start the technical work of revoking access.
This phase needs to be systematic. The goal is to make sure the vendor has no remaining way into your systems by the time the contract officially ends.
There are a few areas to work through:
Step 6: identity de-provisioning
Start with the accounts you already know about from the inventory phase. These are usually the easiest to handle since they’re documented and you know where they exist:
Identity type | What to do |
Named user accounts | Disable or delete from internal systems, apps, and admin consoles |
SSO/directory entries | Remove from your identity provider so access is cut across all connected apps at once |
Guest accounts | Remove from collaboration tools like Slack, Teams, Google Workspace, and Notion |
Service accounts | Disable or reassign ownership if the account supports ongoing processes |
Shared accounts | Change credentials immediately or disable entirely if no longer needed |
Those are the known accounts. But vendor access has a way of accumulating in places that don’t get tracked, and those are the gaps that come back to bite you.
Here are a few things that regularly get overlooked:
- Accounts created outside of IT’s normal provisioning process
- Service accounts tied to integrations that nobody remembers setting up
- Guest access that was granted directly in an app rather than through your identity provider
- Accounts in tools that aren’t connected to SSO and require manual removal
- Test or sandbox accounts that were created during vendor onboarding and never cleaned up
Check with the business owner and anyone who worked closely with the vendor. They’ll often remember access that was granted informally and never made it into any system of record.
PRO TIP 💡: ConductorOne discovers and inventories non-human identities like service accounts, API tokens, and machine credentials alongside user accounts. These are the identities that manual deprovisioning almost always misses, and the ones most likely to stay active after offboarding.
Step 7: Deep clean (APIs and integrations)
Most vendor relationships involve some kind of technical integration, whether it’s an API key, an OAuth connection, or a webhook sending data to an external endpoint. These don’t get disabled automatically when you remove an account.
Pay attention to these things in particular:
Integration type | What to do |
API keys | Revoke any keys issued to the vendor, even if they claim they're no longer in use |
OAuth connections | Disconnect authorized apps from platforms like Google Workspace, Microsoft 365, Salesforce |
Webhooks | Remove any endpoints that send data to vendor-controlled URLs |
Automation workflows | Check tools like Zapier, Workato, or Power Automate for workflows that involve the vendor |
Data syncs | Disable any scheduled exports, imports, or replication jobs tied to the vendor |
Embedded apps | Remove vendor apps or plugins installed in your SaaS platforms |
Direct database connections | Revoke credentials and close any firewall rules that allowed vendor access |
Hardcoded credentials | Search code repositories for API keys or tokens that were committed and rotate them |
The problem with these connections is that they don’t expire when the relationship does. An API key works until someone revokes it, regardless of whether the person who created it still has access.
And these credentials are easy to lose track of. Research shows that up to 77% of machine accounts go unmanaged.
Step 8: Physical and asset recovery
Digital access gets most of the attention, but physical access matters too. A Ponemon study found that 74% of companies have experienced data loss from devices that weren’t properly decommissioned.
If the vendor had any presence in your offices or was issued company equipment, that needs to be handled before offboarding is complete.
You should pay attention to these company asset types:
Asset type | What to do |
Access badges | Deactivate immediately, even if the badge hasn't been returned yet |
Building keys | Collect them, and consider rekeying if keys were issued to sensitive areas |
Company-issued devices | Retrieve laptops, phones, tablets, or other hardware and wipe them before reuse |
Hardware tokens | Recover MFA tokens, data security keys, or RSA fobs and deactivate them in your system |
Parking passes | Revoke system access and collect physical passes if applicable |
Physical documents | Request the return of any printed materials, contracts, or sensitive paperwork |
Prototypes or samples | Retrieve any physical products, equipment, or materials shared during the engagement |
Don’t assume everything will come back voluntarily. Set a clear deadline for returns, follow up if items are missing, and document what was and wasn’t recovered.
And if something can’t be recovered, deactivate the corresponding access so a lost badge or missing token doesn’t leave a door open.
Phase 4: Data recovery and sanitization
At this point, the vendor can no longer access your environment. But that doesn’t mean your data is gone from theirs. This phase covers data retrieval, deletion, and the documentation you’ll need to prove it was handled correctly.
Here’s what to focus on:
Step 9: Knowledge transfer
Before the vendor loses access, make sure you’ve documented everything you’ll need to operate without them.
Knowledge transfer is easy to skip when timelines get tight, but the cost of missing it shows up later when nobody knows how something works or why it was set up a certain way.
Make sure you’ve covered each of these before the cutoff date:
Knowledge type | How to capture it |
Process documentation | Have the service provider write up or update any workflows they managed, step by step |
System configurations | Document settings, parameters, and dependencies for anything the vendor built or maintained |
Credentials and access | Transfer ownership of any shared accounts, passwords, or keys that need to stay active |
Historical context | Record why certain decisions were made, what was tried and didn't work, and any known issues |
Tribal knowledge | Schedule live walkthroughs or recorded sessions for anything that isn't written down |
Pending or in-progress work | Get status updates on anything unfinished, including next steps and blockers |
One piece of advice from an IT professional on Reddit: test all passwords needed to access systems/reset other credentials while on the phone with the outgoing MSP. That way, you can be certain you have what you need.
Assume the documentation is incomplete, because it usually is. A live session with the outgoing vendor and whoever is taking over creates space for questions, clarifications, and the kind of context that doesn’t fit neatly into a wiki page.
Step 10: Data destruction
The contract may say the vendor will delete your data after termination, but that doesn’t mean it happens automatically. You need to request it, specify what should be destroyed, and get confirmation that it was done.
Work through each of these with the vendor:
Data type | Why it matters |
Customer data | PII, payment information, or other personal data creates liability if it's retained beyond the relationship |
Proprietary information | Trade secrets, product roadmaps, internal strategies—anything you wouldn't want a competitor to see |
Credentials and keys | Passwords, tokens, or certificates that the vendor stored should be deleted, not just deactivated on your end |
Communications | Emails, Slack messages, and meeting recordings may contain sensitive context that shouldn't linger |
Logs and analytics | Access logs, usage data, and reports derived from your data can still reveal sensitive patterns |
Backups | Production data might be deleted while backup copies quietly persist for months |
Subprocessor copies | If the vendor used third parties for storage or processing, your company data may exist in places you didn't directly control |
A verbal “yes, it’s deleted” isn’t enough. Get a written certificate of destruction that specifies what was removed, when, and from which systems. If subprocessors were involved, make sure the confirmation covers their environments too.
PRO TIP 💡: When you request data destruction, you need to know what the vendor could access in the first place. ConductorOne maintains a record of all vendor permissions and access changes over time, so you have a clear baseline to work from
Phase 5: Financial closure and post-mortem
At this point, the security and data risks have been addressed. Now it’s time to tie up the financial and administrative side of things.
This phase covers final payments, contract closure, and the kind of retrospective that helps you do this better next time.
Here’s what’s left:
Step 11: Final settlement
The financial side of offboarding is easy to rush through, but cleaning it up later is a headache. Before the relationship officially ends, make sure everything is reconciled – what you owe, what they owe, and anything still in dispute.
Run through each of these before signing off:
Financial item | What to check |
Outstanding invoices | Review any unpaid bills and confirm the charges are accurate before paying |
Prepaid credits | Identify any unused credits or prepayments and request a refund or credit note |
Refunds owed | Follow up on deposits, overpayments, or any amounts the vendor agreed to return |
Early termination fees | Confirm whether any penalties apply and whether they're being calculated correctly |
Disputed charges | Resolve any billing disagreements before the relationship ends, and leverage disappears |
Unused licenses or seats | Check for subscriptions you paid for but didn't fully use, and negotiate a refund if possible |
Auto-renewals | Confirm that recurring billing is cancelled and no future charges will be processed |
Loop in your finance team early and give them a clear cut-off date for vendor-related charges. Anything that shows up after that date should be flagged and questioned, not paid automatically.
Step 12: The “quiet period” monitoring
Offboarding doesn’t end the moment access is revoked. Research shows that 89% of former employees still have access to at least one application from their former job
For the first few weeks, it’s worth keeping an eye on your environment to make sure nothing was missed, and no one is trying to get back in.
Set up a quiet period, typically 30 to 90 days, where you actively monitor for signs that the offboarding wasn’t as complete as you thought.
A few things to watch for:
- Failed login attempts from vendor-associated accounts or email domains
- Unexpected API activity from keys or tokens that should have been revoked
- Integration errors that could mean that someone is still trying to sync data
- Billing charges from the vendor that arrive after the termination date
- Data flows to external endpoints that should no longer be receiving anything
- Badge or entry logs showing physical access attempts at your facilities
If something triggers during this window, treat it as a sign that part of the offboarding was incomplete rather than assuming malicious intent.
Investigate, close the gap, and document what was missed so the next offboarding doesn’t have the same problem.
PRO TIP 💡: ConductorOne continuously monitors for access anomalies (like orphaned accounts, unrotated credentials, or unexpected activity), so you don’t have to manually watch for signs that something was missed. If a revoked vendor account is still active somewhere, the platform will flag it.
Step 13: Audit documentation
This step is easy to skip when the hard work feels finished, but documentation is what you’ll need later. Audits, legal questions, and future offboardings all go smoother when there’s a clear record of what happened and when.
Keep these on file, and you’ll be covered for most scenarios:
Document | Why you'll need it |
Termination notice | Proves the vendor was formally notified and when, critical if there's a dispute over contract terms |
Data destruction certificate | Demonstrates compliance with data handling requirements during audits or regulatory reviews |
Access revocation logs | Shows exactly when credentials were disabled, useful if questions arise about unauthorized access |
Financial settlement records | Confirms what was paid, refunded, or written off, protects you if billing disputes resurface |
Contract and amendments | Preserves the full agreement in case you need to reference contractual obligations that survived termination |
Communication records | Documents key decisions and approvals, helpful when memories fade or personnel change |
Asset return confirmation | Proves company property was recovered or reported missing, covers you if devices surface later |
Knowledge transfer documentation | Gives future teams a reference point without having to reconstruct what the vendor knew |
Make sure to store everything in a centralized location with clear naming conventions. If you can’t find it two years from now, it might as well not exist.
Automate vendor offboarding with ConductorOne
The checklist above works, but it depends on people remembering every step, coordinating across teams, and following through manually.
That’s where most offboarding processes break down. The more vendors you manage, the harder it becomes to keep track of who has access to what, and the easier it is for credentials to slip through the cracks.
That’s where automation comes in.
ConductorOne is a modern identity governance platform that centralizes visibility and control over every identity in your environment, whether that’s employees, vendors, or non-human identities.
When it comes to vendor offboarding, it takes the manual work out of the equation and automates access revocation across your entire stack.
Here’s what you can expect:
- Unified Identity Graph: Get a single source of truth for all identity and access data across cloud, on-prem, and SaaS systems. When it’s time to offboard a vendor, you can see exactly what they have access to in one place.
- 300+ pre-built connectors: Integrate with the tools you already use in as little as a few days. Vendors get governed access across your entire stack, not just the apps your identity provider happens to cover.
- Automated lifecycle management: Handle onboarding and offboarding with automated provisioning and deprovisioning across all connected apps. No more chasing down permissions system by system.
- Just-in-time access: Grant vendor access with built-in expiration dates so credentials don’t linger indefinitely. Access ends automatically when it’s supposed to, without manual intervention.
- Non-human identity management: Discover and govern service accounts, API keys, tokens, and certificates that manual processes typically miss. These are the credentials that tend to outlive vendor relationships.
- Policy-aware AI agents: AI agents can handle routine access decisions based on your security policies. It processes requests, assesses potential risks, and escalates only what needs human judgment.
- Audit-ready documentation: Track all access changes with a full audit trail. When compliance asks for proof that offboarding was done correctly, the evidence is already there.
Vendor offboarding doesn’t have to be a manual, error-prone process. ConductorOne gives you the visibility to know what access exists and the automation to revoke it completely.
Book a demo to see how it works.
Vendor offboarding FAQs
How does vendor offboarding impact regulatory compliance?
Improper vendor offboarding can put you out of compliance with regulations like GDPR, HIPAA, and PCI-DSS.
These frameworks require you to control how personal and sensitive data is handled throughout its lifecycle, including when a third-party relationship ends.
If a former vendor retains data, they shouldn’t, or if you can’t prove it was properly deleted, that’s your liability. Auditors will ask for documentation, and gaps in the paper trail can result in findings or fines.
What are the security risks of manual offboarding?
Manual processes introduce human error at every stage. Without a standardized checklist template or automated workflow, it’s easy to miss accounts, forget about integrations, or skip documentation entirely.
Some common risks include:
- Credentials that stay active because they weren’t tracked centrally
- Integrations that keep running because nobody remembered to disconnect it
- Incomplete records that create problems during audits
- Inconsistent execution depending on who handles the offboarding
The more manual the process, the more room there is for vulnerabilities to develop unnoticed.
Who should be involved in the offboarding process?
Offboarding works best when it’s treated as a cross-functional process rather than a task that gets handed to one team. The key players typically include:
- IT / Security for access control revocation and monitoring
- Legal for contract review and termination notices
- Finance for final payments, refunds, and billing cutoffs
- Procurement for vendor management records and contract termination
- Business owner for knowledge transfer and relationship context
Someone should also own the process end-to-end to make sure nothing falls between departments.
Why is access inventory essential before offboarding vendors?
Access inventory is the foundation on which everything else is built. If you don’t know what systems the vendor touches, what credentials they hold, and what integrations are connected, there’s no way to verify the offboarding was complete.
