Security Basics: Sorting Out Who Holds Which Keys Across Your Tools
Most security incidents at small organizations do not start with a sophisticated attack. They start with a forgotten credential: an API key pasted into a shared document, a service account nobody remembers creating, or an integration that still has access months after the project it served has ended. Before you can protect your tools, you need an accurate picture of what credentials exist, where they live, and what each one can reach. This article walks through a method for building that picture and the questions to ask vendors before you trust them with access.
Start with an inventory, not a policy
Writing a security policy before you know what you are protecting tends to produce documents nobody follows. A better starting point is a plain inventory. List every tool your team uses that accepts a login, token, or key. Include the obvious ones such as email, file storage, and code repositories, and the less obvious ones such as analytics dashboards, payment consoles, scheduling apps, and browser extensions that request access to company accounts.
For each entry, record four things: who created the account, who currently administers it, what kind of credential it uses (password, single sign-on, API key, or service token), and what data or systems it can reach. You will likely find accounts that belong to people who have left, credentials created for one-time migrations, and shared logins that several people use. Those findings are the real work of this exercise, and they are more useful than any template.
Separate personal, shared, and service credentials
Credentials fail in different ways depending on how they are used. Personal credentials tied to an individual should be easy to revoke when that person changes roles or leaves. Shared logins, such as a single account used by a support team, are harder to audit because no one can say who did what with them. Service credentials, such as API keys used by scripts or integrations, often outlive their purpose because nobody owns the decision to remove them.
Label each credential in your inventory with one of these three categories. Shared logins and service credentials deserve closer attention, because they usually lack a clear owner. Where a shared login is unavoidable, record who has the password, how it is stored, and when it was last changed. Where possible, replace shared access with individual accounts, since that gives you a trail you can actually read.
Questions to ask a vendor before you trust them
Vendors often describe their security in general terms, and marketing language rarely answers the questions that matter for your situation. Before granting a tool access to company accounts, ask the vendor directly. Does the product support single sign-on or multi-factor authentication, and can you enforce it for all users? Can you see a list of active sessions and revoke them? Can administrators remove a departing employee's access without depending on that employee's cooperation?
Ask what data the vendor stores, how long it keeps logs, and whether you can export or delete your data when you stop using the service. Ask how they notify customers about security problems and what their process is for doing so. Write down the answers. If a vendor cannot answer clearly, treat that as information about the product, and weigh it accordingly against your need for the tool.
A practical checklist for your next review
Use this sequence as a recurring routine rather than a one-time project. First, update the inventory with any new tools added since the last review. Second, remove or disable credentials for people who no longer need them, and for integrations whose projects have ended. Third, identify every shared login and decide whether each can be replaced with individual access. Fourth, rotate any API key or service token that has been exposed in a shared document, chat channel, or code repository, even if you have no evidence of misuse. Fifth, confirm that at least two people can administer each critical account, so that one departure does not lock the team out.
Repeat this review on a fixed schedule, such as every quarter, and record the date and what changed. The value of the exercise comes from consistency. A short review that happens reliably will catch far more problems than a detailed audit that happens once and is then forgotten.