Firing an IT vendor is awkward. Firing one who has admin access to your systems, knows your infrastructure, and might be resentful? That’s a security event.

Most vendor termination guidance focuses on contractual and operational concerns. This guide focuses on security—what access to revoke, what knowledge to capture, and how to ensure the transition doesn’t create vulnerabilities.

The stakes are real. Disgruntled vendors have sabotaged systems. Forgotten access has persisted for years. Knowledge gaps have caused outages. Plan the offboarding as carefully as you planned the onboarding.

Before You Notify the Vendor

The period between your decision to terminate and the vendor’s awareness is your window to prepare. Use it.

Access Inventory

Before the vendor knows they’re being terminated, inventory their access:

System accounts:

• All accounts the vendor uses (named accounts, shared accounts, service accounts)
• Admin access to any systems
• Access to security tools (SIEM, EDR, backup systems)
• VPN or remote access credentials

Cloud and SaaS:

• Cloud console access (AWS, Azure, GCP)
• SaaS application admin access
• OAuth integrations they’ve configured
• API keys and tokens they’ve created or use

Physical access:

• Building access badges or credentials
• Physical keys
• Access to secure areas

Communication:

• Accounts on your communication platforms (Slack, Teams, email)
• Distribution lists they’re on
• External accounts tied to your domain (vendor email like vendor@yourcompany.com)

Document everything. You’ll revoke access quickly once termination is announced—you don’t want to be discovering accounts during a tense transition.

Knowledge Inventory

Identify what institutional knowledge the vendor holds:

Documentation:

• System documentation they’ve created
• Network diagrams
• Configuration documentation
• Runbooks and procedures
• Password/credential documentation

Undocumented knowledge:

• Systems only they understand
• Processes that exist in their heads
• Relationships with other vendors (software support contacts, etc.)
• Recurring tasks they perform
• Historical context about why things are configured certain ways

Credential knowledge:

• Passwords they know (that you’ll need to rotate)
• Where credentials are stored
• Service account passwords

Dependency Mapping

Understand how dependent you are:

Operational dependencies:

• What critical functions do they perform?
• What would break if they disappeared tomorrow?
• What’s the minimum transition period needed?

Contractual dependencies:

• What are your termination notice requirements?
• Are there transition assistance obligations?
• What data/artifacts must they return?

Technical dependencies:

• What tools do they own licenses for that you use?
• What integrations do they manage?
• What do they have that you need (keys, certificates, documentation)?

The Notification Conversation

When you notify the vendor of termination, security considerations matter:

Timing

Ideally, notify on a schedule that gives you control:

• Early in the week (not Friday—gives you business days to respond to issues)
• Morning (gives you the full day to execute access changes)
• Coordinate internally so everyone is ready to act

What to Communicate

Be clear about:

• Effective termination date
• Transition period expectations
• Immediate changes to access (if any)
• Knowledge transfer requirements
• Data and artifact return requirements
• Ongoing obligations (confidentiality, non-disclosure)

Be cautious about:

• Over-explaining your reasons (creates negotiation opportunity)
• Assuming goodwill (prepare for hostility even from historically good vendors)
• Making threats (professional termination, not confrontation)

Immediate Access Changes

Depending on risk assessment, you may take immediate access actions at notification:

High-risk terminations (adversarial, cause for termination, security concerns):

• Revoke all access immediately upon notification
• Have a plan for same-day knowledge transfer or accept knowledge loss
• Monitor for suspicious activity from vendor IP ranges/accounts

Normal terminations (end of contract, budget change, consolidation):

• May allow continued access during transition period
• Still revoke admin/elevated access immediately
• Limit to read-only or supervised access
• Shorten active session timeouts

Access Revocation Checklist

Execute systematically. Missed accounts are security vulnerabilities.

Identity Provider

• [ ] Disable/remove vendor accounts from identity provider (Okta, Entra, etc.)
• [ ] Remove from all groups and roles
• [ ] Terminate active sessions
• [ ] Disable SSO access (propagates to connected applications)

Network Access

• [ ] Revoke VPN credentials
• [ ] Remove from network access control lists
• [ ] Remove from any IP allowlists
• [ ] Disable any direct connections (site-to-site VPN, dedicated links)
• [ ] Review firewall rules for vendor-specific access

System Accounts

• [ ] Disable local accounts on servers and workstations
• [ ] Reset passwords on shared accounts they accessed
• [ ] Disable service accounts they created
• [ ] Review scheduled tasks/cron jobs running as their accounts

Cloud Environments

• [ ] Remove IAM users and roles
• [ ] Delete or rotate access keys
• [ ] Remove from cloud console access
• [ ] Review and remove vendor-created resources if appropriate
• [ ] Check for cross-account access configurations

SaaS Applications

• [ ] Remove from each SaaS application (don’t rely on SSO removal—some have persistent sessions)
• [ ] Revoke OAuth grants for vendor-authorized applications
• [ ] Remove from admin groups
• [ ] Check for API keys/tokens they may have created

Security Tools

• [ ] Remove from SIEM/security monitoring tools
• [ ] Remove from EDR consoles
• [ ] Remove from backup administration
• [ ] Remove from patch management
• [ ] Update any shared security credentials

Communication Platforms

• [ ] Remove from Slack/Teams/email
• [ ] Remove from distribution lists
• [ ] Disable email aliases (@yourcompany.com addresses)
• [ ] Review shared channels or external collaboration

Physical Access

• [ ] Deactivate building access badges
• [ ] Collect physical keys
• [ ] Update alarm codes they knew
• [ ] Notify security/reception staff

Credentials to Rotate

• [ ] All shared passwords the vendor knew
• [ ] Break-glass account credentials
• [ ] Service account passwords
• [ ] API keys they had access to
• [ ] Any credentials stored in systems they accessed

Knowledge Transfer

Rushed knowledge transfer creates knowledge gaps. Gaps become vulnerabilities and operational issues.

Documentation Requirements

Request/create:

• [ ] Complete network diagrams
• [ ] System configuration documentation
• [ ] Application architecture documentation
• [ ] Integration documentation
• [ ] Runbooks for recurring tasks
• [ ] Incident history and lessons learned
• [ ] Vendor/software support contact information

Transition Sessions

Schedule working sessions to transfer:

• System walkthroughs for complex environments
• Demonstration of recurring tasks
• Explanation of non-obvious configurations
• Handover of monitoring and alerting
• Introduction to any sub-contractors or vendors they managed

Data Return

Require return of:

• [ ] All company data in their possession
• [ ] Documentation and artifacts
• [ ] Backups they maintain
• [ ] Any customer data they processed
• [ ] Access credentials still in their possession

Require destruction of:

• [ ] Copies of company data
• [ ] Test environments with real data
• [ ] Credentials in their password managers

Monitoring During and After Transition

The transition period and months after are high-risk. Monitor accordingly.

During Transition

• Increase monitoring on systems vendor can still access
• Alert on any access from vendor IP ranges
• Alert on any activity from accounts being phased out
• Review all changes made during transition period
• Consider separation of duties (vendor can’t make changes alone)

Post-Termination

• Monitor for access attempts from terminated accounts
• Watch for access from vendor’s known IP ranges
• Review for dormant accounts that might be vendor-related
• Check for scheduled tasks or cron jobs that might still run
• Monitor for password reuse (attacker using old vendor credentials)

Special Considerations

Hostile Terminations

If you’re terminating for cause (security incident, breach of contract, serious problems):

• Revoke all access before notification if possible
• Have legal counsel review the termination
• Consider forensic preservation of relevant systems
• Be prepared for vendor to be uncooperative with knowledge transfer
• Consider external assistance to fill knowledge gaps
• Increase monitoring intensity significantly

Vendors with Deep Access

Some vendors have extensive access—managed IT providers, outsourced security teams. Terminating them is more complex:

• Longer transition periods are necessary
• Consider parallel operation with new provider
• May need to rebuild rather than transfer some systems
• Budget for significant transition effort
• Plan for potential service disruption

Software or Licensing Ownership

If the vendor owns licenses you depend on:

• Clarify license ownership in termination
• Arrange license transfer if possible
• Plan for replacement if licenses leave with vendor
• Don’t let licensing dependencies hold you hostage—address early

Sub-Contractors

If the vendor used sub-contractors to serve you:

• Those sub-contractors may have access too
• The vendor may not be thorough in revoking sub-contractor access
• You may not know who all the sub-contractors are
• Treat sub-contractor access as suspect until verified terminated

The Transition Security Checklist

Consolidated checklist for secure vendor offboarding:

Preparation (before notification):

• [ ] Inventory all vendor access
• [ ] Inventory knowledge and dependencies
• [ ] Plan access revocation sequence
• [ ] Prepare transition timeline
• [ ] Coordinate internal teams

At notification:

• [ ] Communicate termination terms clearly
• [ ] Execute immediate access changes per plan
• [ ] Begin knowledge transfer process
• [ ] Set expectations for data return

During transition:

• [ ] Systematic access revocation per checklist
• [ ] Knowledge transfer sessions
• [ ] Documentation handover
• [ ] Credential rotation
• [ ] Increased monitoring

At termination:

• [ ] Final access revocation verification
• [ ] Data return confirmation
• [ ] Destruction certification (if applicable)
• [ ] Settle any outstanding contractual matters

Post-termination:

• [ ] Continued monitoring for access attempts
• [ ] Access audit for any missed revocations
• [ ] Address any knowledge gaps discovered
• [ ] Update vendor management records

Learning From the Experience

After the dust settles:

What access did you miss in the inventory? Update your access tracking.

What knowledge was harder to transfer than expected? Improve documentation requirements for current vendors.

What would you do differently? Document lessons learned for next termination.

Are your current vendors similarly risky? Apply what you learned to current vendor management.

Vendor terminations are inevitable. Handling them securely is a capability you’ll use repeatedly.