In this guide 6 sections
Audit roles by listing every account in every system, matching each one to a current employee, and comparing granted permissions with what that job needs today. Route fixes through an approver. Book the next review. Access drifts by default. Quarterly checks suit risky systems.
Inventory of accounts, including privileged ones
Start with the list. Pull every account from every system in scope: named user logins, service accounts, shared logins and anything holding admin rights, exported straight from each admin console.
Privileged accounts come first. They are few in number, yet one admin login created for a data migration years ago and never closed can reach every customer record in the system.
Then match every account to a person. Contractors from finished projects, a vendor’s temporary login and an account under a name nobody recognises will fail the match and need an owner or a deletion date. Note the system, the owner, the creation date and the last login, so dormant accounts stand out when you sort the sheet by that final column.
Mapping access rights to what each role needs today
List what each account can actually do. Use the permission names granted inside the system, such as approve payments, export customer lists or edit price books, instead of trusting what the job title seems to imply. Compare each list with current duties.
Access piles up when people change roles or cover a temporary project, and it is rarely removed once the reason has passed, so the oldest accounts hold the most. Excess access shows up here. Someone who moved from finance to operations two years ago may still approve supplier payments, and a manager may hold admin rights for one weekly report.
Write the finding next to the account. A line such as ‘reads payroll, needs only the sales dashboard’ gives the approver something to sign off, where a note about too much access invites an argument.
Joiners, movers and leavers
Test the real process. Ask who grants access on a new hire’s first day, who removes it when a role changes, and what triggers that removal when nobody remembers to email IT. Informal handovers fail quietly.
Suppose a branch manager at a salon group leaves in January and the login to the till and customer database stays live through the summer. Nobody did anything wrong. Deactivation depended on someone remembering to flag it by hand, which is the pattern this check is built to catch before it becomes an incident.
Logs, exceptions and segregation-of-duty risks
Read the logs you have. An account that has been provisioned but never used is a strong sign the access was unnecessary, and unusual activity deserves a direct conversation rather than an accusation.
Then look for conflicts of duty. The same person should not be able to both create a vendor and approve payment to that vendor, or to process a refund and also approve it. These are rarely signs of wrongdoing. They are a structural weakness, and an external auditor or a customer’s due diligence team will list them as a finding, so close them before anyone else finds them.
Approved corrections and a recurring review
Every correction needs a named approver. Revoking access, downgrading it or splitting a shared login into named accounts should each be logged with the approver’s name and the date, so the change stays reversible.
Book the next review today. A one-time cleanup fixes today’s drift, while a recurring review stops the same problems rebuilding, so check higher risk systems every quarter and the rest twice a year.
If a compliance certification is on your roadmap, a dated, recurring access review is a control auditors typically ask to see, so raise it with your adviser.
Role-permission review matrix
A matrix with one row per account and columns for current role, systems accessed, permission level, last login date and a privileged or shared flag. Over-provisioned and dormant accounts become visible at a glance, so nobody has to compare each system by hand before the approver meeting begins.
Open a blank worksheet to printQuestions owners ask
Who should approve access changes?
A named person with authority over that system or department should approve new access and every correction the audit recommends, usually the relevant manager. IT implements the change, but the decision about who may see payroll or customer data belongs with the person accountable for that area.
How do we handle shared logins?
Split them into individually named accounts wherever the system allows it, because a shared login makes it impossible to know who did what. That defeats the point of an access review and leaves nothing to trace when something goes wrong and a person must be identified.
How often should we repeat the audit?
Quarterly suits systems holding money, payroll or customer records, and twice a year suits the rest, such as internal wikis and design tools. Add an extra check after any restructure, acquisition or large round of hiring, since those events create more drift in a month than normal trading does in a year.