Access tends to accumulate quietly. An employee changes roles, a contractor finishes a project, or a vendor needs temporary access to troubleshoot a system. If nobody revisits those permissions, an account can keep more access than its owner needs long after the original reason is gone.
An access review is a structured check of who or what can reach a system, what they can do there, and whether that access still has a business reason. It is not a demand that a small company build a large identity-governance program. A focused review of important systems can reveal stale accounts and unclear ownership before they become operational or security problems.
Start with a manageable scope
Do not begin by trying to review every permission in every application. Choose a small set of systems where inappropriate access would matter: email and file storage, financial or customer records, cloud administration, production software, backups, and tools that connect systems together.
For each system, record the account name, account type, owner, role or group, last known business reason, privileged actions, and review date. Include more than employee accounts. Shared logins, service accounts, API credentials, guest users, and vendor accounts can all create access that is difficult to attribute or remove.
The first inventory does not need to be perfect. A spreadsheet or export from an identity provider can be enough to identify unknown entries and prioritize the accounts that can change data, access sensitive information, or administer other users.
Assign a real reviewer
An access review needs an accountable person who understands the business responsibility behind the permission. That may be a department lead for a team account, a system owner for an application, or a business owner for a small company. An administrator can provide the report and apply changes, but technical access alone does not answer whether someone still needs it.
For sensitive systems, use two people for important decisions when practical. One person can confirm the work need, while another can apply or verify the change. This separation of duties helps reduce mistakes and makes the decision easier to explain later.
Give the reviewer useful context rather than a raw list of names. Show the system, current role, notable privileges, last sign-in if available, and the person or process that requested access. Avoid putting passwords, tokens, or sensitive business data into the review record.
Compare access with current responsibilities
For each entry, choose a clear outcome: keep, reduce, suspend, remove, or investigate. “Keep” should mean the access is still needed for a documented responsibility, not simply that nobody recognized the account. “Reduce” is often the most useful outcome when someone needs a system but no longer needs administrative rights.
Ask four practical questions:
- Does the person or process still work with this system?
- Does the assigned role match the work they need to perform?
- Is the access broader or more permanent than necessary?
- Who would notice if the access were removed or changed?
Least privilege is a useful design principle here: provide the minimum access required for the task. It does not mean making every permission temporary or forcing people through an approval process for routine work. It means challenging broad, inherited, or permanent access when a narrower role would work.
Handle former staff and vendors deliberately
Former employees and completed vendor engagements deserve a specific check because their business relationship may have ended even though their account remains active. Confirm the end date, identify any files or workflows that need an owner, and disable or remove access according to the system’s recovery and retention rules.
Vendor access should have an owner, a stated purpose, and an end or review date. If a vendor needs elevated access for a short task, use a named account where possible, require multi-factor authentication when the system supports it, and record who approved the access. Do not treat a vendor’s request as proof that permanent administrator access is necessary.
Service accounts require a different question. They may not have a human sign-in, but they should still have an owner, a narrow purpose, documented credentials or key rotation process, and a plan for what happens when the connected workflow changes. Removing an unknown service account immediately can interrupt a business process, so investigate first and make the change with a recovery plan.
Make the decision trail useful
A review record should help someone understand what changed and why. For each decision, capture the reviewer, date, system, account, previous access, new access, reason, and follow-up owner. Keep evidence of the request or business responsibility when it is appropriate, but avoid copying sensitive data into a general-purpose document.
When access is removed, verify the result in the system and note any related changes, such as group membership, delegated mailbox access, application assignment, or API permission. A successful ticket does not prove that every path to the resource is closed. Verification should match the way the system actually grants access.
Choose a review rhythm and improve it
There is no universal schedule that fits every small business. Review high-impact and privileged access more often than low-risk tools, and trigger an extra review when someone changes roles, leaves, or completes a vendor engagement. The right interval depends on the system’s sensitivity, how quickly responsibilities change, and how difficult a mistaken removal would be to recover.
After the first cycle, look for repeated findings. If the same stale group appears every time, improve onboarding and offboarding. If reviewers cannot tell who owns a system, document that ownership. If an integration depends on a broad service account, plan a narrower role or a safer boundary as a development task.
An access review is a practical maintenance habit, not a paperwork exercise. Start with the systems that matter most, give decisions a responsible owner, remove or reduce access with care, and keep a concise record of the reasoning. Next step: Schedule a short consultation to identify the next useful improvement.