Security Basics: Finding Who Can Approve Changes Before Something Breaks
.jpg){kind=link}
Most security conversations start with passwords and end with software. Yet a surprising share of avoidable trouble comes from a quieter gap: nobody is entirely sure who is allowed to approve a change to a shared tool, a billing setting, a data sharing rule, or an integration. When a request arrives in a chat thread or a hallway conversation, the person who answers it often has no written authority to do so, and the person who asked may assume approval was already settled elsewhere. This article covers a method for mapping approval authority before you need it, so that a routine change does not turn into an incident and an urgent change does not turn into a guessing game.
Why approval authority is a security question
It is easy to treat approval as an administrative detail, separate from the technical work of securing systems. In practice, approval decides who can alter access, enable a feature, connect a new service, or change where data flows. If the approval path is unclear, every one of those actions becomes harder to trace afterward. You cannot tell whether a change was intended, whether it followed a review, or whether someone simply had the password and acted alone.
Small teams are especially prone to this problem. Founders and operators often hold broad administrative rights because it was convenient at the start, and those rights quietly expand as the team grows. A contractor gets added to a shared workspace for a single project and is never removed. A marketing tool is connected to a customer database by someone who never asked whether that connection was permitted. None of these moves required malice. They required only that nobody had written down who decides.
Building a simple approval map
Start with a list of the tools your business uses for anything involving customer information, financial settings, shared credentials, source code, or public-facing content. For each tool, write down the decisions it supports: adding or removing users, changing permissions, connecting third-party apps, exporting data, changing billing details, and altering retention or sharing settings. You do not need an elaborate spreadsheet. A plain table with the tool, the decision type, and the named role responsible is enough to start.
Next, assign roles rather than individuals where possible. A role such as 'operations lead' or 'engineering owner' survives staff changes better than a name does. Under each role, note who is the backup approver, because the primary approver will be unavailable at some point. A map with no backup is a map that fails on the day it matters most. Be honest about overlap: if one person approves everything, that is a fact to record, not to hide, and it is a signal that a second reviewer may be needed for higher-risk changes.
Separating routine changes from emergency changes
Not every change deserves the same process. Adding a read-only user to a document folder carries far less risk than granting administrative rights or connecting a tool to your customer records. A useful approach is to sort changes into at least two tiers. Routine changes follow a standard path, such as a written request and a reviewer's sign-off in your ticket system. Higher-risk changes require a second approver who was not involved in making the request.
Emergencies are where teams most often abandon their own rules. An outage or a suspected compromise creates pressure to act immediately, and the fastest route is usually a single person with full access making changes directly. Decide in advance what counts as an emergency and what the minimum record should be, even if the record is written after the fact. A short note stating what changed, who made the change, why it was urgent, and when the change was reviewed later keeps the audit trail intact without slowing the response.
Questions to ask every tool vendor
When evaluating a new tool, approval structure belongs in the same conversation as features and price. Ask the vendor how administrative roles are defined and whether you can restrict who holds them. Ask whether the product can require a second person to confirm sensitive changes, and if not, what you should do to compensate, such as keeping a manual log. Ask how account ownership transfers when the original administrator leaves, and whether the vendor's process depends on a single named person.
Also ask what the tool records. Can you see a history of permission changes, integration connections, and exports? Can you export that history yourself? If a vendor cannot describe its change history clearly, you should assume you will have difficulty reconstructing events later. Document the answers you receive, because the sales conversation is often the only point where you can ask these questions before signing.
A practical checklist for this month
Work through these steps in order. First, list every tool that touches customer data, money, credentials, or code. Second, for each tool, name the decision types it supports and the role responsible for each. Third, record a backup approver for every role. Fourth, identify the three changes your team makes most often and confirm the approval path for each one. Fifth, define what counts as an emergency change and write the minimum record required afterward. Sixth, review any administrator who no longer works on the relevant project and remove their elevated rights.
Finally, schedule a short recurring review, perhaps once a quarter, to confirm the map still reflects reality. Roles drift, people change jobs, and new tools appear without anyone updating the list. The goal is not a perfect document. It is a shared understanding of who decides, written clearly enough that a new team member or a backup approver could find it in an emergency and act within the rules you set.