Why access drifts
When a person joins a company, they are usually given the access their role needs. Over time that picture changes. They help on a project and get extra permissions. They move teams and keep the old ones. A system is added and a broad group is granted access for convenience. Few people go back and remove anything, because removing access feels risky and nobody is asked to do it.
The result is often called access creep or permission drift. An access review, sometimes called recertification, is a scheduled check that pulls this back into line. Someone with knowledge of the person or system looks at the current access and confirms that it is still needed, or asks for it to be removed.
This article covers the purpose of reviews and how to run them so reviewers do the job properly rather than clicking through. It is general information and not compliance advice; requirements differ by industry and country, so check with compliance professionals.
What a review actually asks
At its simplest, a review asks: should this person still have this access? There are two common ways to organize it.
- By user. A manager reviews everything their team members can reach. This suits questions like whether a person still needs their permissions after a change in duties.
- By system or resource. The owner of an application or data set reviews everyone who can reach it. This suits questions about whether a sensitive system has more users than it should.
Many organizations use both: managers confirm that access matches the job, and system owners confirm that access to their systems makes sense. Clarity about who counts as the owner is important, and it connects to the idea of system ownership roles.
What to include in scope
Not everything needs the same attention. A sensible scope often starts with higher-risk areas:
- Privileged and administrator accounts.
- Systems holding financial, personal or otherwise sensitive data.
- Access for contractors and other external parties.
- Shared or generic accounts.
- Service accounts, which are easy to forget because no person logs in with them.
Lower-risk systems can be reviewed less often. Frequency is a judgment call; some organizations review sensitive access more often than routine access. There is no universal right interval, and the policy should state what the business has chosen and why.
Why reviews fail in practice
Reviews are easy to describe and surprisingly hard to do well. Common problems include:
- Too much to read. A reviewer given a spreadsheet with thousands of rows tends to approve all of it.
- Cryptic permission names. If an entry reads like a code, the reviewer cannot judge whether it is appropriate.
- No consequence. If unreviewed access simply stays in place, there is little reason to respond.
- Wrong reviewer. A manager who does not know what a system does cannot say whether a person needs it.
- Rubber-stamping. When every item is routine, people approve without looking, and the review becomes a formality.
Making reviews practical
Several habits tend to help.
- Show access in plain language. Describe what each permission lets the person do, not just its technical name.
- Keep each review small. Split large reviews by team or by system so one person sees a manageable list.
- Highlight what changed. Showing new access since the last review, or access unused for a long time, directs attention to the items most worth questioning.
- Make the default safe. A policy that says unconfirmed access is removed after a defined period gives reviews weight. Because that can disrupt work, many organizations first send reminders and escalate to a more senior person.
- Give clear deadlines and reminders. Reviews that run indefinitely rarely finish.
- Keep a record. Note who reviewed, when, and what was decided. That record is often what an auditor wants to see.
- Make removal easy and reversible. If restoring access is quick, reviewers are more willing to remove it when unsure.
Reviews and the rest of the access process
Reviews catch problems that other processes miss. They complement, rather than replace, good handling of people starting, moving and leaving, since a leaver whose access was not removed on time may show up in a review. They are also a way of checking whether the least privilege principle is being kept up over time, and whether role definitions still match how people work.
If reviews keep finding the same issue, treat that as a signal about the upstream process. Repeatedly finding movers with old permissions, for example, suggests the move process needs work.
Costs and limits
Reviews take time from busy people, and a central team that coordinates them adds overhead. A highly centralized review program can produce consistent evidence, but it may also push reviews onto managers who lack context. A hybrid arrangement, where the central team sets the schedule, tools and format while local owners make the judgments, often works better than either extreme.
Reviews also look backward. They check what exists now, not what happened between reviews, so they work best alongside logging and sensible approval processes. And a completed review does not prove that access is correct, only that someone looked.
A starting point
A small business can begin simply: list the important systems, name an owner for each, and ask those owners twice a year or so to confirm the user list. As the organization grows, add tooling, more frequent checks for sensitive access, and clearer reporting. Because the expectations of auditors and regulators vary, ask qualified compliance advisers what applies to your situation.