Learn
Guide
When the person who signed your company up for Figma, Notion, or your payment processor leaves, the tool doesn’t stop working, but nobody may be able to change a setting, add a payment method, or remove a departed user from it. This is the sole-admin risk: a single person holding the only keys to a SaaS account, often without anyone else in the company realizing it. The fix runs deeper than a better offboarding checklist: treat admin ownership as a role that always has a backup, checked at the moment a tool is purchased, not the day someone resigns.
TL;DR
Sole-admin risk happens because someone has to click “sign up” first, and in small teams that person rarely thinks to add a second admin.
Billing owner, technical admin, and end user are three separate roles. Handing off one does not hand off the others.
Some vendors let you self-serve an ownership transfer. Others require a support ticket and proof you’re authorized to make the change.
The only real fix is inventorying who administers what before you need the answer, and requiring at least two admins on every SaaS account that matters to the business.
This is a distinct problem from offboarding a departing employee’s own user account, which is a separate operational process.
About the Author: ShiftControl is built by Dan and Julien, who ran IT operations at ExpressVPN as the company scaled from 100 to over 700 core employees across seven global offices. That experience, provisioning and de-provisioning access across dozens of SaaS tools at speed, is what led them to build software for companies that don’t have an IT team to catch these gaps manually.
Why Does Sole-Admin Ownership Happen in Small Teams?
Sole-admin ownership happens because every SaaS account needs exactly one person to create it, and in a company of ten or twenty people, that’s usually whoever needed the tool fastest. A designer signs up for Figma with their work email. The founder puts the company card on file for the payment processor. An ops lead spins up a Notion workspace on a Tuesday afternoon to organize a project. None of them are thinking about succession. They’re thinking about getting unblocked.
The problem is invisible until someone leaves, because a working SaaS account gives no warning signal. Nothing breaks. The team keeps using Figma normally, the invoices keep processing, the Notion docs stay editable. The only thing missing is the ability to administer the account, and that gap only becomes visible the day someone needs to add a seat, change a payment method, or remove a former employee’s login from that specific tool.
This is structurally different from the employee offboarding problem most companies already have a checklist for. Offboarding an employee’s Google Workspace account is about revoking that person’s access to company systems, and that process is well understood. Sole-admin risk is about a company losing its own ability to administer a system it depends on, because the only person who could do so is no longer there. One is about a departing employee’s access. The other is about the company’s control over a tool it pays for and relies on.
Small companies are more exposed to this than larger ones, and not because they’re careless. It’s a direct function of headcount: a 15-person company might run 20 to 30 SaaS tools with no one whose job is to track who administers each one. A 500-person company has the same sprawl but usually has an IT or ops function whose job includes exactly this kind of tracking.
What’s the Difference Between a Billing Owner, a Technical Admin, and a User?
These are three separate roles, and confusing them is the reason companies get surprised. A billing owner controls the payment method, invoices, and subscription plan. A technical admin controls settings, integrations, user permissions, and security configuration inside the tool itself. A user is someone with a login who does their day-to-day work in the product but has no administrative control over it.
In a small company, these three roles often collapse into the same person, which feels efficient right up until that person leaves. Here’s why the collapse matters: transferring one role does not automatically transfer the others.
Role | Controls | What happens if this person leaves and nothing was transferred |
|---|---|---|
Billing owner | Payment method, invoices, plan tier, cancellation | Card expires, subscription lapses, or nobody can downgrade/upgrade seats |
Technical admin | User permissions, integrations, security settings, SSO config | Nobody can add or remove users, change permissions, or configure the tool |
End user | Their own work inside the product | Their individual account can usually be deactivated by HR or IT as normal, but this has no bearing on who administers the account |
A concrete example: your ops lead sets up your payment processor account, adds herself as the primary contact, and connects the company bank account. She’s the billing owner. Separately, your engineering lead configures the API keys and webhook permissions. He’s the technical admin. If the ops lead leaves and nobody transfers billing ownership, the company might lose the ability to update the card on file or respond to a billing dispute, even though the engineering lead can still manage every technical setting. Fixing one gap does nothing for the other.
This is also why “we removed her from Google Workspace” doesn’t solve the problem. Deactivating someone’s Google Workspace account controls their access to Google Workspace and any app using it for single sign-on. It does nothing to reassign the billing or admin role they held inside a third-party SaaS tool that was set up with a personal or work email but isn’t tied to your SSO. This is precisely the gap that sole-admin risk lives in, and it’s a different failure mode from the orphaned-account problem inside Google Workspace itself.
Which SaaS Apps Won’t Let You Self-Serve an Admin Transfer?
Some platforms let you reassign ownership in a few clicks. Others require a support ticket, and the difference matters because you find out which category a tool falls into only when you’re under time pressure.
Self-serve transfer is common in tools built around workspace or organization-level admin consoles, where an existing owner can promote another member to owner status directly in settings, with no vendor involvement required.
Vendor-assisted transfer is common where ownership carries financial or legal weight, such as billing accounts, payment processors, or single-purpose tools that were never designed around multi-admin teams. In these cases, if there’s no other admin already in the account, the standard advice is to contact support directly, because only an existing account owner can typically promote a new one, and if there are no active owners left at all, an internal admin transfer isn’t possible without vendor intervention.
This shows up in workflow and automation tools too. Platforms like Power Automate can end up with “orphaned flows” when the person who built and owned an automation leaves the company, and admins have to actively identify these and assign new co-owners rather than have it happen automatically. The same shape of problem appears in project and workflow tools more broadly: ownership of a workspace, board, or automation doesn’t transfer just because the person’s employment ends, and someone has to notice and manually intervene, sometimes company-wide rather than tool-by-tool.
When a vendor-assisted transfer is required, expect to provide evidence you’re authorized to make the request. Commonly requested evidence includes:
Proof of employment or role at the company (a work email domain match, an offer letter, or a company registration document)
Confirmation from a company officer or existing admin, if one exists
Access to the departed admin’s email, if the vendor uses email-based verification for the original account
In some cases, a formal request routed through the vendor’s account or billing team rather than general support
For accounts tied to shared drives and file permissions, similar issues show up when a departing employee owned folders or files that others depend on; those permissions have to be reassigned deliberately rather than assumed to transfer. The common thread across every one of these tools: nothing transfers by default. Someone has to act, and the vendor decides how much friction that action requires.
How Do You Inventory Who Administers What Before You Need To?
An admin inventory is a simple list: every SaaS tool the company depends on, who the billing owner is, who the technical admin is, and whether a second admin exists. Building on the distinctions above, the point of the inventory is to answer, in advance, the question you’d otherwise be scrambling to answer the day someone resigns.
A practical inventory covers, per tool:
Tool name and what it’s used for (so anyone reading the list understands the stakes if access is lost)
Billing owner and whether payment details are tied to a personal or company card
Technical admin(s) and whether there’s more than one
Whether the tool supports SSO through your identity provider, since SSO-connected tools are far easier to secure and reassign than standalone logins
Vendor’s transfer process: self-serve, or support ticket with evidence required
This kind of visibility is exactly what’s missing in most small companies, not because founders don’t care, but because nobody owns SaaS operations as a job. Discovering every tool in use in the first place, including ones IT or ops never formally approved, is its own challenge; a shadow IT discovery tool can surface subscriptions and logins that exist outside any spreadsheet, which is often the first step before an inventory is even possible. Pairing that discovery with a centralized SaaS spend management tool gives a single view of what the company is paying for, who’s using it, and who administers it, rather than reconstructing that picture from expense reports after the fact.
Should Admin Ownership Be a Role, Not a Person?
Yes, and this is the structural fix, not a policy reminder. Treating admin ownership as a role means every SaaS account that matters to business continuity has a minimum of two people with administrative or ownership rights at all times, by default, not as an exception someone remembers to set up.
Practically, this means checking three things the moment a tool is first purchased, not months later:
Add a second admin immediately. Most platforms support this natively, and it costs nothing to do at signup versus a support ticket after someone’s already gone.
Use a company email and, where possible, SSO for the billing contact, not a personal email address, so the account is tied to the organization rather than an individual’s inbox.
Record the tool in the inventory the day it’s purchased, not when it’s audited.
Centralizing credentials also closes a related gap: a password manager for teams means logins for non-SSO tools live somewhere the company controls, rather than in one person’s browser autofill. This matters specifically for the tools that can’t be put behind SSO for small business setups, which is where a surprising amount of sole-admin risk concentrates, since those tools tend to be smaller, single-purpose products signed up for quickly and administered by whoever happened to need them first.
For companies running Google Workspace as their core platform, this is easier to enforce than it sounds. Good Google Workspace user management practices, paired with a SaaS license management software layer that tracks admin roles across connected apps, turns “who administers what” from a question you answer under pressure into one you can answer from a dashboard. This is the same operating principle ShiftControl is built around for small teams without a dedicated IT function: built for operators, not IT teams, giving companies the control a big company has, minus the complexity and cost. Provisioning and access, SaaS spend, app permissions, and incident response, purpose-built for Google Workspace, rather than four disconnected tools and a spreadsheet someone forgot to update.
Frequently Asked Questions
What is sole-admin risk in SaaS management?
Sole-admin risk is when only one person in a company has administrative or billing control over a SaaS tool the business depends on. If that person leaves without the role being transferred, the company can lose the ability to manage the account even though the account itself keeps working normally.
Is transferring SaaS account ownership the same as offboarding an employee?
No. Offboarding revokes a departing employee’s access to company systems. Transferring account ownership reassigns who can administer a specific SaaS tool, which is a separate action that often gets missed because it isn’t part of a standard offboarding checklist.
Can I always transfer admin rights myself, without contacting the vendor?
Not always. Some platforms let an existing admin promote a new one directly in settings. Others, especially billing or payment-related accounts, require a support ticket and proof of authorization, particularly if there’s no remaining active admin to make the request.
What happens if a SaaS account has no active admin left?
You’ll typically need to contact the vendor’s support team directly and provide evidence that you’re authorized to take over the account, such as proof of company affiliation or documentation confirming your role.
How is a billing owner different from a technical admin?
A billing owner controls payment and subscription details. A technical admin controls settings, permissions, and integrations inside the tool. Transferring one role does not transfer the other, so both need to be checked independently when someone leaves.
Do SSO and identity providers reduce sole-admin risk?
Yes, for tools connected through SSO. Centralizing authentication through an identity provider makes it easier to see who has access and to revoke it consistently, though it doesn’t automatically solve billing-level ownership gaps in tools that aren’t SSO-connected.
What’s the first step to reducing this risk this week?
Build a short list of every SaaS tool the company depends on, note who the billing owner and technical admin are for each, and add a second admin to any tool that currently has only one.
About ShiftControl
ShiftControl is built for operators, not IT teams. It’s an IT operations and SaaS management platform purpose-built for Google Workspace that gives companies the control a big company has, minus the complexity and cost. One platform for provisioning and access, SaaS spend, app permissions, and incident response, with no dedicated IT team required. Setup takes about 10 minutes via a single Google Workspace login, and cyber incident response (IR-1, via Blackpanda) is included in the subscription. ShiftControl was founded by former ExpressVPN operators who scaled IT operations from 100 to over 700 employees across seven global offices, and the platform is SOC 2 compliant, ISO-compliant, and has signed the CISA Secure by Design Pledge.
If your company’s SaaS accounts all trace back to one person’s login, that’s worth fixing before it becomes a problem. Take a look at how ShiftControl helps small teams manage access, spend, and admin ownership in one place.
