Someone from sales asks in the team chat: "Can I get into the accounting system for a day? I need to check an invoice." An administrator says yes and adds the account. The invoice is checked. The account stays, with full rights, for the next two years.
Nothing dramatic happens. That is why the habit survives. But every such account is a door nobody is watching, and the person who granted it often cannot say later why it exists. This article is for the owner or operations manager of a small company who wants a simple, repeatable way to say yes, no or "for two weeks".
Why chat requests go wrong
A request in a chat message is fast, but it leaves gaps:
- Nobody wrote down which level of access was needed, so the default (often the highest) is given.
- The person who agrees may not be the person responsible for the system or its data.
- There is no end date, so temporary access becomes permanent by neglect.
- Months later there is no record of who asked, who approved and why.
The fix is not a ticketing platform. It is one page and a few rules.
The one-page form
The form can be a shared document, a spreadsheet row or a short message template. It needs five facts:
- Who needs access. Name and role, not just "the new person".
- Which system. One system per request, so that each can be approved by its own owner.
- What level. View only, edit, or administrator. Ask for the lowest level that lets the person do the task. Describe the task in words ("check and download invoices") and let the approver pick the level.
- Why. One sentence about the work, ideally with a project or customer name.
- Until when. A date. For employees whose role needs the access permanently, the date is the next quarterly check. For a contractor or a one-off task it is the end of the work.
If any of the five is missing, the request goes back. This takes ten seconds and removes most of the later confusion.
One approver per system
Every system gets one named approver, and one deputy for holidays. The approver is the person who is accountable for what is stored in the system, usually a team lead or the owner of the data, not whoever happens to have administrator rights.
Two rules keep it honest:
- Nobody approves their own request. If the approver needs access, their manager or the owner approves.
- The approver decides, the administrator executes. The administrator makes the change only when the approval is on the form. If your company is small and one person plays both roles, write down the approval anyway; the record is the point.
A short list of "system, approver, deputy" fits on one page and can sit next to the form. If you already keep a list of who owns each system, reuse it. The article Access in an internal tool: who may do what and how to review it every quarter describes how to define levels so that the approver has clear choices.
The time limit
The end date is the most useful field on the form. It changes the default. Without it, access continues until someone remembers to remove it, which in practice means never. With it, access ends unless someone decides otherwise.
Practical settings that work for small companies:
- One-off task: the day the task is due, plus a day.
- Project or contractor: the planned end of the work.
- Permanent role: the date of the next quarterly check, then renewed with a short confirmation from the approver.
When the date arrives, the administrator removes the access or the approver extends it with a new date. Extending is a deliberate yes, not a silent default. A calendar reminder or a "valid until" column that you sort by date is enough.
The quarterly check
Once every three months, the administrator sends each approver the list of open grants for their system. The approver marks each line keep, reduce or remove. A thirty-minute meeting is usually enough for a company of up to fifty people.
Look especially for:
- accounts of people who changed role or left,
- accounts of contractors whose project has finished,
- administrator rights given "temporarily",
- shared accounts that several people use, which cannot be tied to one person.
Record the date of the check and what changed. The same check pairs well with the leaving-day steps in the new employee access checklist, which covers the opposite end of the same process: access that should be removed when someone leaves.
Common mistakes
- Too many fields. Five facts are enough. A form that takes a quarter of an hour will be bypassed with a chat message.
- Approval by the wrong person. A colleague who is friendly with the requester is not the owner of the data.
- "Same as my colleague". Copying another person's rights copies everything they have collected over the years. Ask for the task, not the profile.
- Exceptions without a date. Urgent requests are fine, but they still get an end date and are written down afterwards.
- No one runs the check. Give the quarterly check to a named person and put it in the calendar for the year.
A short plan for this month
- Write the five-field form and agree it with the owner.
- List your ten most important systems and name an approver and deputy for each.
- Ask each approver for a list of current accounts, and mark anything nobody can explain.
- Start using the form for every new request from the next Monday.
- Put the first quarterly check in the calendar, with a named person.
After the first quarter, count three things: how many requests came through the form, how many accounts you removed or reduced at the check, and how many you could not explain. Those numbers tell you whether the routine is working and where to look next. You do not need to cover every system on day one; start with the ones that hold money, customer data or staff data.
Sources
- Practical guidance based on common small-business access management practice, offered as a planning aid. The form fields, time limits and review rhythm are illustrations to adapt to your own company. No client results or performance figures are claimed in this article.
