Why permissions need a second look
Access that was sensible when it was granted can become inappropriate later. People change jobs, projects end, contractors finish, systems gain new features and temporary permissions are never withdrawn. None of this requires carelessness; it is simply what happens when many small decisions accumulate over time.
An access review is a scheduled check where someone looks at who has access to a system or resource and confirms whether each person still needs it. It is a straightforward control, and it catches the sort of drift that day-to-day processes miss.
Decide the scope first
Reviewing everything at once is unrealistic for most teams. Instead, choose a scope you can complete well.
- By system. Start with the most sensitive ones: finance, HR, customer data, email administration, backups and anything with administrator rights.
- By privilege level. Administrator and powerful accounts deserve more frequent checks than ordinary users.
- By population. Contractors, temporary staff and service accounts are often under-managed and can be reviewed separately.
Use a risk assessment to decide priorities: the more harm that misuse could cause, the more often the review should happen. A common pattern is reviewing high-risk access more frequently, such as every few months, and lower-risk access less often, such as once a year. The right rhythm depends on your organization, so choose one you will actually keep.
Gather accurate information
A review is only as good as its input. For each system in scope, produce a list that shows:
- the account name and the real person or owner behind it
- the role or group memberships and specific permissions
- when the account was created and when it last signed in
- any special conditions, such as an expiry date
Exporting this from the system itself is more reliable than relying on memory. Compare the list of accounts against a current list of employees and contractors from HR. Accounts that match nobody, such as old leavers and shared logins, are the first things to flag. Ownership problems with service accounts and shared accounts frequently show up here.
Sign-in history is useful. An account that has not been used for many months may no longer be needed, although seasonal or emergency-only accounts can look dormant for legitimate reasons, so ask before removing.
Choose the right reviewers
The best reviewer is someone who understands both the people and the work. Usually that is the person’s line manager for team access, and the system or data owner for access to a particular application. Asking IT alone to decide is weaker, since IT often cannot tell whether an accountant really needs a given report.
Where possible, avoid having people approve their own access. And for administrators, a second person, such as a senior manager or security lead, should review their permissions.
Ask clear questions
Rubber-stamping is the main way reviews fail. A reviewer handed a spreadsheet of five hundred rows and asked to approve it will often click through. Make the task easier:
- show the minimum needed: name, role, permissions and last sign-in
- state the decision options plainly: keep, remove, or change
- ask a concrete question, such as “Does this person still need to approve invoices?”
- group by role, so that unusual individuals stand out
- highlight changes since the last review, such as new administrators
- set a reasonable deadline and send reminders
Questions worth asking include whether the person still works here, whether they still hold this job, whether they need every permission or only part of it, and whether the access was meant to be temporary.
This links directly to the idea of least privilege: a review is a chance to trim back to what the work requires. If roles are well designed, the review can focus on exceptions, which is one benefit of role-based access.
Record decisions and act on them
A review that changes nothing is a cost without a benefit. Once decisions come back:
- Record them. Keep a simple log of what was reviewed, who reviewed it, the date and the decisions.
- Make the changes. Remove or reduce access promptly, and note when each change was completed.
- Verify. Confirm that the changes took effect. It is surprisingly common for a “removed” permission to persist through an overlooked group.
- Handle non-responses. Decide in advance what happens if a reviewer does not reply. Some organizations escalate to a senior manager; others suspend the unconfirmed access after a warning. Choose a policy and apply it consistently.
- Track exceptions. If access is intentionally kept despite looking unusual, write down why and when it will be reconsidered.
These records are valuable if someone later asks who approved an access decision, and they feed into broader IT governance and audit needs.
Learn from what you find
Patterns reveal where processes are weak. If you keep finding accounts of people who left, the leaver process needs attention. If many people have permissions from earlier jobs, mover steps are not removing access. If reviewers constantly cannot tell what a permission means, the names and descriptions need improving. Feed those lessons back into onboarding and offboarding and into the IT policies.
Review accounts that show unexpected activity separately; if a check turns up something that looks like misuse, treat it according to your incident response procedure, not as a routine cleanup.
Keep it small and regular
A modest review done on schedule is better than an ambitious one that never finishes. Start with your most sensitive system, run it end to end, note what was awkward, and improve the next round. Over time, expand the scope and consider tools that gather data and send reminders automatically. The goal is steady, evidence-based confirmation that access still matches need.