The contract with your old IT provider ends on a Friday. The new provider starts Monday. In the three days in between, nobody actually verifies that every account, credential, and remote connection your former provider ever touched has been identified, reassigned, or shut off. That gap, the quiet handoff where responsibility changes hands but access doesn't automatically follow, is exactly where switching IT providers turns into a security incident nobody notices until months later.
A security assessment run at the moment of handover isn't a formality, and it isn't about distrusting either provider. It's the only reliable way to document what actually exists in your environment before responsibility for it changes hands, and to establish a dated, independent baseline that both the outgoing and incoming provider can be measured against. Here's what that assessment should actually cover, and why the gap between "the old provider is gone" and "the old provider's access is gone" is wider than most business owners assume.
Why there's no clean handoff by default
A website build has a defined start and end date, and handing it off is a single, bounded event. An IT provider or managed service provider (MSP) relationship isn't like that. It typically runs for years, and over that time it accumulates access across dozens of systems: your firewall, your servers, your Microsoft 365 or Google Workspace admin console, your domain registrar, your DNS records, your backup infrastructure, your VPN, remote monitoring and management (RMM) agents installed on every endpoint, cloud hosting accounts, security tooling, and vendor portals nobody has looked at in two years. No single document tracks all of it, because it was never all created at once. It was added piece by piece, ticket by ticket, over the life of the relationship.
That accumulation is exactly why ending the contract on paper doesn't end the technical access in practice. Terminating a services agreement is a legal and financial event. Removing every account, credential, and remote connection tied to that provider is a technical project, and unless someone treats it as one, with a checklist and independent verification, most of what accumulated over years of the relationship simply stays in place, because nobody on either side has a complete enough picture to know it's still there.
Vendor-owned accounts: the administrator who never technically leaves
Many IT providers and MSPs provision administrative accounts under their own naming convention rather than the client's: an admin account tied to the provider's own email domain, a support technician's personal login used as the recovery contact on your domain registrar, or a service account created under the provider's identity for convenience during setup. These accounts work fine while the relationship is active. The problem surfaces the moment it ends, because unless someone specifically goes looking, an account created and controlled by the outgoing provider doesn't disappear when the invoice stops. It just sits there, with whatever administrative privilege it was granted, answering to an email address that no longer belongs to anyone with a reason to have access.
A vulnerability assessment or audit at the point of transition should include a full inventory of every administrator and owner-level account across every platform: your identity provider, domain registrar, DNS management console, cloud hosting accounts, backup systems, and security tools, verifying that each one is tied to an identity your business actually controls. Any account that traces back to the outgoing provider, its personnel, or its own infrastructure is a finding, regardless of whether it's ever been misused, because the exposure exists the moment the account exists, not the moment someone abuses it.
Lingering remote access: the tool built for convenience is also the tool built for persistence
Remote monitoring and management software is how most IT providers actually do their job: patching, monitoring, and troubleshooting endpoints without a technician physically present. CISA, the NSA, and the Multi-State Information Sharing and Analysis Center jointly warned in a 2023 cybersecurity advisory that RMM software's legitimate capabilities, the ability to monitor and operate devices with elevated permissions, are exactly what makes it attractive to malicious actors seeking to maintain persistence and move laterally once they're inside a network. The same advisory specifically flagged that threat actors can exploit trust relationships in MSP networks to reach a large number of a single provider's customers through one compromised access point.
That risk isn't theoretical. In July 2021, attackers exploited a vulnerability in Kaseya's VSA remote management platform, a tool used by MSPs specifically to administer client systems, and used it to push ransomware downstream through fewer than 60 directly compromised MSP accounts into an estimated 1,500 businesses that had never been targeted individually. Sweden's Coop grocery chain shut down roughly 800 stores because their point-of-sale systems ran through an affected MSP. Over a hundred New Zealand kindergartens lost access to their systems the same weekend. None of those businesses were the target. Their provider's remote access tooling was.
An uninstalled RMM agent left behind by a former IT provider is functionally the same attack surface, without even the justification of an active business relationship requiring it. A vulnerability assessment or audit during a provider transition should enumerate every remote access tool, RMM agent, and VPN profile present across every endpoint and network device, and confirm that each one is either actively required by the new provider or removed entirely. "We'll leave it in case we need it later" is not a security posture. It's an unmonitored door with someone else holding the key.
Forgotten infrastructure: the systems nobody remembers exist
Gartner estimates that shadow IT, technology deployed without formal IT oversight, accounts for 30 to 40 percent of total IT spending at large enterprises, and a widely cited BetterCloud analysis found that the number of SaaS applications actually running on a typical corporate network runs roughly three times higher than what IT departments have on record. Multiply that pattern across a multi-year relationship with an outgoing IT provider and the gap gets worse, not better: staging servers spun up for a project that shipped years ago, test subdomains pointing at infrastructure nobody decommissioned, an old backup target still receiving nightly jobs, a trial SaaS tool from a proof of concept that quietly became permanent, a cloud storage bucket created for a one-time migration and never deleted.
None of this reliably survives a provider transition, because the outgoing provider may remember some of it, the business usually remembers less, and the new provider only inherits what's explicitly pointed out to them during onboarding. An external vulnerability assessment or audit that maps every internet-facing asset tied to the business's actual domains, rather than relying on whatever inventory either provider hands over, is the only reliable way to surface what a standard transition would otherwise silently drop. If nobody independently verifies the asset list, the new provider is securing the environment they were told about, not the one that actually exists.
Transferred credentials: the vault that gets handed over but not rotated
Password managers, shared credential vaults, API keys, SSH keys, and shared administrative logins accumulate the same way access accounts do: quietly, over years, across every system the provider ever touched. A typical handover involves exporting or sharing that vault with the incoming provider. It rarely involves rotating every single credential inside it, because rotating dozens or hundreds of passwords, keys, and service account secrets is tedious, easy to deprioritize against a go-live deadline, and easy to assume someone else already handled.
That assumption is the actual exposure. Every credential the outgoing provider ever held remains fully valid until it's explicitly changed, which means a departed technician at the old provider, or the provider itself well after the contract ends, retains functional access to systems the business believes it has secured. A handover should treat every credential the former provider ever held as compromised by default the day the contract ends, not because anyone assumes bad faith, but because a credential that was never proven to be rotated has to be assumed live. Transferring a vault is a convenience. Rotating what's inside it is the actual security control.
Who's responsible for issues that existed before the handover?
Neither party in a provider transition has a natural incentive to go looking for problems that predate them. The outgoing provider has no reason to audit an environment they're about to lose access to and won't be paid to fix. The incoming provider, without an independent, dated baseline, has no way to prove whether a vulnerability discovered three months into the new engagement existed before they arrived or appeared on their watch, and that distinction matters enormously if something goes wrong and the business needs to know who's actually accountable for it.
Without a documented assessment at the exact point of transition, responsibility for every pre-existing issue defaults to whoever is paying for IT services today, regardless of who actually created the exposure or how long it existed before anyone noticed. A dated, independent vulnerability assessment or audit at the handover is what turns "we're not sure whose fault this was" into a documented fact both providers and the business itself can point back to.
A transition security checklist worth working through line by line
Before treating a provider transition as complete, verify the following: every administrator and owner-level account across your identity provider, domain registrar, DNS console, cloud hosting accounts, backup systems, and security tools is inventoried and confirmed to belong to an identity the business actually controls. Every RMM agent, remote access tool, and VPN profile tied to the outgoing provider has been either transferred and re-authenticated under the new provider or completely removed, not left installed "just in case." Every credential the outgoing provider ever held, not only the ones explicitly handed over, has been rotated rather than assumed secure. Physical access controls, such as building badge credentials or alarm codes issued to the outgoing provider's technicians, have been revoked or reissued. A full external asset inventory has been run against every domain the business owns to surface forgotten subdomains, staging environments, and cloud resources neither provider mentioned. Firewall rules and remote access policies have been reviewed for entries still referencing the old provider's IP ranges or tools. And an independent vulnerability assessment has been completed and dated before the new provider's engagement officially begins, establishing a documented starting point both sides are measured against.
Example language for the transition agreement
Language like the following can be adapted into an offboarding agreement with an outgoing provider or an onboarding agreement with a new one, to make the transition itself a documented, verifiable event rather than an assumed one:
"Outgoing Provider shall, within five (5) business days of contract termination, disable or transfer all administrative accounts, remote access tools, and credentials associated with its personnel and infrastructure, and shall deliver to Client a complete written inventory of all systems, accounts, and access points established or maintained during the engagement. Client reserves the right to commission an independent security assessment following termination to verify the completeness of this transition, at Client's discretion and expense."
This is a starting point for a conversation with an attorney, not a drop-in legal document. Contract language needs to fit your specific vendor relationship, industry, and risk tolerance, and should be reviewed by legal counsel before it goes into any binding agreement.
A handover testing procedure
A structured transition, rather than an informal changeover, protects the business regardless of how the relationship with the outgoing provider ended. Start by requesting a complete written inventory of every system, account, and access point the outgoing provider has touched over the course of the engagement. Run an external vulnerability assessment or audit against the business's full domain and IP footprint independently of what either provider reports, specifically to catch what neither side remembers. Cross-reference the outgoing provider's inventory against the assessment's findings to identify the gaps: systems the provider never disclosed, or assets the assessment surfaced that nobody had listed anywhere. Rotate every credential and disable every account tied to the outgoing provider, then retest remote access paths specifically to confirm nothing still responds to the old provider's tools or credentials. Once the environment is verified clean, document the assessment results as the official baseline the new provider inherits and is measured against from day one.
Why this belongs at the handover, not after
A core vulnerability assessment or audit scoped to the transition can run in parallel with the handover itself, fast enough to complete without delaying the new provider's start date. For businesses with more complex environments, multiple office locations, regulated customer data, or extensive custom infrastructure, an extended audit adds authenticated penetration testing, the deeper pentest work that validates access controls actually hold under real testing, not just that they look correct in a configuration file. And because a provider switch is exactly the kind of change that resets configuration drift (new tools, new access patterns, new assumptions about what's already secured), rolling into a recurring quarterly audit or assessment after the transition catches whatever the switch itself introduced, on top of whatever the new provider's own onboarding changes along the way.
The 1,500 businesses affected by a single compromised MSP tool in 2021 didn't have a direct relationship with the attacker, and most of them had no idea their provider's remote access software was even part of their own attack surface until it was too late to matter. A documented security assessment at the point of switching providers is how a business makes sure it never has to find out the same way.
