The contract ends Friday. On Monday, the former vendor’s named account is disabled. The organization assumes the transition is complete, but nobody has checked its remote support agent, application credentials, shared vault items, or ownership of the backup console.
Vendor offboarding is an access and ownership project. Its completion test is whether the organization controls the service and the former provider no longer has authorized access paths, subject to documented exceptions.
NIST Zero Trust Architecture supports explicit access decisions rather than trust based on location or ownership. The checklist below applies that principle to a practical handover. It should be adapted to your systems and contract, not treated as a universal removal script.
Establish Authority Before Changing Anything
Name the internal transition owner and confirm the exact vendor, systems, termination time, and approved successor. Separate company-owned infrastructure from vendor-owned services. Check the contract for data return, retention, support, and transition requirements with the appropriate business owner.
Confirm that your organization has working administrative access independent of the departing provider. Test recovery contacts and emergency access through an approved procedure. A screenshot of an administrator account is weaker evidence than a controlled successful sign-in.
If the transition involves a dispute or suspected compromise, use the incident and legal process. Routine offboarding should not destroy evidence needed for an investigation.
Inventory People and Nonhuman Access
Ask system owners for an export or verified inventory. Do not depend entirely on the outgoing vendor’s list.
| Access surface | Questions to answer | Completion evidence |
|---|---|---|
| Named and guest identities | Which accounts and groups belong to the vendor? | Reviewed identity list and removal result |
| Partner or delegated administration | Is another organization authorized to administer services? | Verified relationship status |
| Applications and integrations | Which service accounts, certificates, or grants were created? | Owner and approved disposition for each |
| Remote support | Which agents, gateways, VPNs, or appliances permit entry? | Connection path reviewed and closed or transferred |
| Shared credentials | Which secrets did vendor personnel know? | Controlled rotation with dependency checks |
| Business ownership | Who controls domains, billing, backups, and recovery? | Internal owner and tested access |
Include dormant paths. A tool used only during emergencies can still grant meaningful access. Look at monitoring, backup, endpoint management, cloud administration, code hosting, and network equipment where those systems are in scope.
Transfer Responsibility Before Revoking Dependencies
For each integration, identify what breaks if its credential stops working. A vendor-created account may run a scheduled export or backup. Replace that dependency with an approved organization-controlled identity, test the workflow, and then retire the old access.
Do not rename a vendor account and assume ownership has transferred. Review its recovery methods, credentials, privileges, historical grants, and any external administrative relationship.
Microsoft’s revocation guidance explains that application-issued sessions require application-side handling. An identity-provider change alone may not close every connected service. Ask each system owner what ends existing access and how they will verify it.
Use a Copyable Handover Record
Create one row per access path using this structure:
System and business owner:
Vendor identity or access path:
Current privileges:
Service dependency and replacement:
Approved termination time:
Transfer or removal action:
Verification method and result:
Evidence location:
Exception, expiration, and approving owner:
Follow-up owner and date:Keep secrets in the approved vault. The handover record should identify credentials by reference, never contain their values. Preserve logs and configuration evidence according to policy before making changes that could remove them.
Verify the Result With the Successor
Ask the incoming team to demonstrate the routine work: review a security alert, restore a test item, receive a service notification, and locate the escalation contact. Choose tests proportionate to the services being transferred and avoid production disruption.
Then verify revoked paths through authorized administrative state and controlled tests where appropriate. Record unresolved items honestly. “Vendor confirmed removal” and “organization independently verified removal” are different evidence levels.
Time-box any remaining access with a named sponsor, narrow purpose, monitoring, and expiration. Schedule a final review after the transition window so an exception does not become permanent by neglect.
Use Z7 Cyber for broader access planning and our managed IT recovery drill guide to test the operational handover.
Book a vendor transition conversation. Bring the systems list and the date when your organization needs independent control.