Mapping Who Holds the Keys: Admin Access Audits for UK Founders

TechBlast UK editorial ·

An ~1890 Reliance Printing Press.
Illustrative image. Mbrickn · CC BY-SA 4.0 · Cropped and resized. Image source

Most small teams can name the software they pay for. Far fewer can say, without checking, who holds the administrator role in each tool, what happens to an account when its owner leaves, and whether anyone besides one person can reset a password or change billing. An admin access audit is a short exercise that closes that gap. It does not require specialist tooling. It requires a spreadsheet, an hour of honest answers, and a habit of repeating the exercise each quarter. The aim is simple: know, for every tool your business depends on, who can change it, who can recover it and who can remove it.

Start With the Inventory, Not the Login Page

Begin by listing every service that stores company data, sends messages on your behalf, or controls money or customer records. Include obvious platforms such as email, file storage, accounting and customer relationship tools, but also the less visible ones: domain registrars, payment processors, marketing sends, analytics properties, code repositories and social accounts. Founders often discover tools that a former contractor set up years earlier and that still hold a live integration.

For each entry, record the vendor, the business purpose, the company email address used to sign up, and the approximate number of people who log in. Do not yet try to judge whether the setup is good. The point of this first pass is completeness. A list built from memory will miss things, so cross-check against your bank statements, expense claims and the sender domains in your inbox over the last twelve months.

Record Owners, Admins and Recovery Routes Separately

Three roles are often collapsed into one, and that is where trouble begins. The account owner is the person who holds the billing relationship or the root credential. Administrators are people who can configure users, permissions and integrations. Recovery routes are the mechanisms that let someone regain access when a password or device is lost: a backup email, a phone number, recovery codes, or a second administrator.

Add three columns to your sheet for these roles. For each tool, write the name of the owner, the named administrators, and the recovery method. If the recovery method is a personal mobile number or a mailbox belonging to a single individual, flag it. If the owner account is a generic address such as an info or admin mailbox, check who can read that mailbox and whether it is monitored. Many organisations discover that a critical recovery path depends on an inbox that nobody has opened in a year.

Test Whether Recovery Actually Works

Documenting a recovery route is not the same as proving it functions. Pick two or three of the most important tools and run a controlled test. Can the named administrator sign in from a fresh browser without help? Are recovery codes stored somewhere the current team can reach, and do they match the account? Does the backup email still receive messages? Record the result of each test with a date.

Be careful with the test itself. Use a non-production or designated test user where the vendor offers one, avoid changing live billing details, and do not share credentials in chat or email to complete the exercise. If a test reveals that recovery depends on a departed employee, treat that as the finding it is and move the route to a company-controlled address before anything else.

Questions to Ask Each Vendor Before the Next Renewal

Your audit will surface questions the vendor's documentation may not answer clearly. Ask them in writing and keep the replies in your decision log. Useful questions include: Can we assign more than one owner or billing administrator? How are administrator roles removed when an employee leaves, and is there an audit trail of those changes? What recovery options exist if the primary administrator is locked out, and who at the vendor can help and through which channel? Can we export our configuration and data, and in what format? What happens to our account and data if we stop paying?

Write down the answers as the vendor gives them, not as you hope they are. Where a vendor cannot answer clearly, that is useful information for your renewal decision. Do not assume a feature exists because a competitor offers it, and do not treat a sales call as a substitute for the contract terms.

A Quarterly Checklist for Lean Teams

Keep the exercise small enough to repeat. Each quarter, work through these steps: confirm the tool inventory against recent invoices and sender domains; check that every tool has at least two people who can administer it; confirm that no recovery route depends solely on a departed or unreachable person; remove access for anyone who no longer needs it; verify that shared or generic logins have a named owner; and date-stamp the sheet and store it where the leadership team can find it.

A spreadsheet reviewed on a fixed date beats a detailed document nobody opens. The goal is not perfect security posture. It is a dependable answer to the question every founder eventually faces: who can get us back in, and who can make this change, when the person we usually rely on is unavailable.