Asking a Cloud Provider Who Holds Data Keys When Staff Turn Over
Most small teams discover their key ownership problems at the worst possible moment, usually when a developer leaves or an administrator's laptop is lost. A cloud account, a code repository, a billing portal, and a third-party analytics tool can each hold a different kind of control over your data, and those controls often sit with whoever set the system up. This article offers a method for finding out where that control really lives, what questions to put to each vendor, and how to write the answers down so they survive staff changes. It does not assume any particular vendor behaves in a specific way; instead, it gives you a framework for checking what each one actually documents.
Start by Listing What Counts as a Key
Before you can map ownership, you need a shared definition of what you are mapping. In a small business, a key is any credential or secret that grants meaningful access: an API token, a service account, a database password, a signing certificate, a recovery code, or the primary email address that controls a vendor account. Many teams forget that the email address on a vendor account is itself a key, because it is the route through which password resets flow.
Build a simple inventory with four columns: the tool, the type of credential, where it is stored, and who can currently use it. Do this from the tools themselves rather than from memory. Open each admin console and note the owner or admin accounts listed, the API tokens that appear under settings, and any shared logins. You will usually find more entries than anyone expected, especially tokens created for a one-time integration that nobody revisited.
Separating Personal Accounts From Organizational Control
The most common gap is the difference between an account a person created and an account the organization owns. If a cloud project was started on a developer's personal login and later billed to the company, the company may hold the invoice but not the administrative authority. Ask each vendor, in writing if possible, how an organization account is established, whether it can be separated from an individual user, and which role is the top administrator.
Check whether your vendor offers any documented way to have more than one administrator. If the documentation only describes a single owner, record that fact. A single-owner setup is not automatically wrong for a very small business, but it means a departure or an unreachable person can block recovery. Treat that as a risk to plan around, not a detail to forget.
Questions to Put to Every Vendor
Vendor documentation varies widely, so rather than assuming answers, send a short written list of questions and file the responses. Useful questions include: Who is the top administrator, and how is that role transferred? What happens to shared credentials when the account holder's user record is deleted? Can an administrator rotate API tokens without the original creator's involvement? Is there a documented process for regaining access if all admin users are unreachable? How long do deleted-user records and their associated tokens remain active?
Also ask about data export. If you need to leave a platform, can you retrieve your data and your configuration without the person who set it up? Note the answers and the date you received them. If a vendor cannot answer clearly, that is useful information in itself, and it should factor into your decision about how much to depend on that tool.
A Practical Checklist for Your Next Review
Work through this list once per quarter, and again whenever someone leaves or joins the team. First, confirm that at least two people in the organization can reach each critical admin console, and that neither depends solely on a personal device. Second, identify every API token and service credential, record its creator and its last-used date, and remove any that no current system relies on. Third, verify that the email address tied to each vendor account is an organizational mailbox that more than one trusted person can access. Fourth, record where recovery codes are stored, and confirm that the location is shared with the right people and is not a single personal note. Fifth, confirm that departing staff are removed from every tool listed in your inventory, not only the main workspace.
Keep the inventory in a document your business controls, not in any single tool it describes. Date each entry, and note who reviewed it. The purpose is not to produce a perfect map on day one. It is to make sure that when a key holder leaves, your team already knows where the keys are, who can use them, and what questions to ask the vendor before the situation becomes urgent.