Founder Tool Access Reviews: Who Can Still Log In After Their Role Changes
Most founder tool conversations focus on what a product does. Far fewer focus on who can still do it. Over time, a small company accumulates logins from former contractors, departed staff, trial accounts that were never closed and shared admin credentials that everyone forgot about. None of these feel dangerous on their own. Together they form an access map that nobody has drawn. This article offers a method for building that map, reviewing it on a schedule and asking the right questions of each tool. It makes no claims about any specific vendor's controls, and it assumes you will check what each of your tools actually provides rather than assuming.
Start With an Inventory of Accounts, Not Tools
A tool list tells you what you pay for. An account list tells you who can get in. For a founder, the two lists diverge quickly. One subscription may have five named users, two shared logins, a read-only analyst seat and an integration account that runs under a former developer's email address.
Begin by collecting the sign-in identities for every system that holds company data: email, file storage, accounting, customer relationship records, code repositories, design files, payroll and any AI assistants that connect to internal documents. Export user lists where the tool allows it. Where it does not, record what you can see from the admin screen and note what you cannot see. That gap is itself useful information, and it belongs in your notes.
Classify Each Account by Role and Owner
For every account, write down three things: the person or team it belongs to, the role it holds and the date it was last used. Shared and service accounts need an owner too, even if that owner is simply the person who knows the password recovery route.
Look for the patterns that cause trouble. Accounts with admin rights but no active user. Accounts tied to personal email addresses rather than company domains. Integration tokens whose creator has left. Seats purchased for a project that ended months ago. Each of these is a candidate for removal or reassignment, but do not delete anything yet. First confirm that nothing depends on it, because a quiet integration may be the only thing moving invoices between two systems.
Ask Each Vendor the Questions That Matter
Once you have your inventory, ask each vendor a short set of questions and record the answers. Check the documentation or admin pages first, and where the answer is not clear, put the question to their support team in writing. Useful questions include:
Can I see a complete list of users and their roles, and can I export it? Can I remove a user without deleting their data? Is there a way to enforce company-managed sign-in, and is multi-factor authentication configurable or mandatory? What happens to shared content and integrations when the account owner leaves? How long are deleted records retained, and how do I request an export of my data? Who is the named administrator for my account, and what is the process if that person is unavailable?
Write the answers down next to each tool. If a vendor cannot answer a question clearly, treat that as information, not as a reason to assume the feature exists.
Run a Quarterly Access Review Routine
A one-off audit goes stale within months. Set a recurring review, perhaps every quarter, with a fixed agenda: refresh the account inventory, flag accounts with no recent activity, confirm the owner of every shared login, check that departed staff have been removed, and review admin rights. Keep the review short enough that it actually happens, roughly an hour for a team of ten or fewer.
Record each review in a simple log with the date, who attended, what changed and what remains open. The log matters more than the review itself, because it shows you whether access is shrinking or quietly growing over time.
A Practical Checklist for Your First Review
Work through these steps in order. First, list every system holding company data and its sign-in method. Second, export or transcribe user lists and mark each account's owner and role. Third, identify shared, service and orphaned accounts and find their owners. Fourth, remove access that is clearly unused, after confirming no integration depends on it. Fifth, send the vendor questions above and file the answers. Sixth, reduce admin rights to the smallest group that needs them. Seventh, put the next review date in the calendar before you finish.
Access reviews are unglamorous, but they reveal the operational reality behind your stack. A founder who knows who can still log in has a far clearer picture of risk than one who only knows what the subscriptions cost.