Internal tools tend to begin with a small group of people who trust each other. Everyone gets the same access because it is quick. A year later the group has doubled, two people have changed teams, one has left, and nobody can say who is allowed to delete a record or export the customer list.
This article is for a head of technology or operations who owns an internal tool and wants a simple, repeatable way to control who can do what. It covers one tool and one page of rules. It is not a general guide to security.
Start with four kinds of action
Most internal tools can be described with four kinds of action:
- View: read records and reports.
- Edit: create and change records.
- Approve: confirm something that has consequences, such as a payment, a price change or a deletion.
- Administer: add users, change roles and change settings.
Write these four words at the top of a page. For each kind, list the concrete things in your tool that belong to it. "Export all customers" is usually closer to administer than to view, because of what can be done with the file. Deciding this once, in plain words, saves many arguments later.
Build a roles table
A role is a named bundle of the four actions. Keep the number small. Three to five roles are enough for most tools; more usually means roles have been invented for single people.
| Role | View | Edit | Approve | Administer |
|---|---|---|---|---|
| Reader | Yes | No | No | No |
| Team member | Yes | Own area | No | No |
| Team lead | Yes | Yes | Own area | No |
| Owner | Yes | Yes | Yes | Yes |
The table above is an example, not a standard. Replace the columns with the actions that matter in your tool and the rows with the roles you really have. Give every role a name that describes the job, not a person.
Apply the least-privilege rule
The rule is short: each person gets the smallest set of rights that lets them do their work. Extra rights are added when someone asks for them and the owner agrees, with the reason written down.
This is easier to follow in the beginning than to repair later. Taking rights away from someone who has had them for a year feels like a punishment, even when it is routine. Starting low and adding on request avoids that.
Two practical points help. First, avoid shared logins. If three people use one account, you cannot tell who did what, and you cannot remove one of them without changing the password for all. Second, keep powerful rights away from daily work. A person who administers the tool should use a normal role for ordinary tasks and the administrator role only when needed, if the tool allows it.
Name an owner and a deputy
Someone must be able to say yes or no to an access request. Name one owner of the tool and one deputy. Both can administer; nobody else needs to. If only one person holds the administrator rights, their holiday or departure stops every change. If everyone holds them, the roles mean nothing.
If the original author of the tool has left or is about to, see who owns an internal tool after its author leaves for the handover side of this question.
Review access every quarter
Put a fixed review in the calendar, four times a year, thirty minutes. The owner and a manager of the people who use the tool take part. The steps are:
- Export the list of users with their role and, if the tool records it, the last time they signed in.
- For each user, ask: do they still work here, still in this team, and still need this role?
- Mark anyone who has not signed in for the whole quarter and ask their manager whether they need access at all.
- Check the administrators: are there two, and are they the right two?
- Write down what was removed or changed and the date. A few lines in a shared note are enough.
Most reviews find a handful of small things: a contractor whose project ended, a person who moved to another department, a role that was granted temporarily and never withdrawn. Finding them is the point of the review, not a sign that something went badly.
When someone leaves or changes role
Do not wait for the quarterly review. Add the tool to the standard leaver checklist that your HR or operations team already uses, with the owner named as the person who removes access. The same day the person leaves:
- Remove their user or disable it, rather than only changing the password.
- Check whether they held any shared secrets for the tool, such as an integration key, and replace them.
- Reassign records or tasks that were assigned to them, so nothing waits on a person who is no longer there.
- Note the date in the access log.
A change of role works the same way, in two steps: add what the new job needs, and remove what the old job needed. People who move often keep the old rights as well as the new ones, and over time end up with far more access than any single job needs.
Keep a simple record
You do not need a separate system. A single page or sheet with the roles table, the names of the owner and deputy, and a list of review dates is enough. When someone asks "who approved this person's access?", you should be able to find the answer in a minute.
If your tool keeps a log of who changed what, look at it during the review for unusual actions, such as many deletions or exports by one person. If it does not, consider asking whoever maintains the tool to add basic logging; what to record is covered in what to log in a small internal tool.
A short checklist
- List the view, edit, approve and administer actions of your tool in plain words
- Define three to five roles and write them in one table
- Give new users the lowest role that fits and add rights only on request
- Avoid shared logins
- Name an owner and a deputy as the only administrators
- Hold a thirty-minute access review every quarter and write down the changes
- Remove access on the day someone leaves and adjust it when someone changes role
Related reading
For a similar approach applied to automated assistants, see least-privilege access for AI agents: read, write and credentials review. If you are planning a new tool, picking the first user of a new internal tool is a good moment to agree the first roles.
Sources
- Our related articles linked above.
- The approach described is a general working practice, not a standard; adapt it to your organisation. No figures or client results are claimed in this article.