You can design a perfect role model on day one and still end up with a CRM full of over-privileged users within two years. People change teams, take on temporary projects, get a special permission “just for this quarter,” and nobody takes it back. An access review is the routine that pulls the system back toward what you intended.

What an access review is, and what it isn’t

It is a scheduled check that each person’s access is still appropriate for their current job. It is not the same as offboarding, which handles people who leave, and it is not a redesign of your roles. Think of it as a tidy-up cycle: confirm, adjust, remove.

The risk with any review is that it turns into a rubber stamp. A manager receives a spreadsheet with four hundred rows, ticks “approve” down the column, and the control produces a nice record and no protection. Most of the design work is about avoiding that.

Decide the scope

Not everything needs the same frequency. A reasonable pattern is to review in tiers:

• Administrators and anyone who can change configuration, manage users or export in bulk: review most often.
• Users with broad data visibility or sensitive modules: review regularly.
• Standard users within a well-defined role: review less often, focusing on exceptions.
• Service accounts, API users and connected apps: include them. They are often forgotten and rarely have a manager.

Pick a rhythm you will sustain. A review that’s planned quarterly and happens once a year is worse than an honest twice-yearly one.

Make it easy for the reviewer

The person signing off is usually the user’s manager, because they know what the person does. Help them:

1. Show the role or profile, not just the username. “Regional sales rep, standard” is meaningful; a technical permission name isn’t.
2. Highlight the exceptions: extra permissions beyond the standard role, admin rights, access granted by request.
3. Show last sign-in. A user who hasn’t logged in for months is a strong candidate for removal.
4. Give a clear action: keep, change, or remove, with a deadline.
5. Keep each reviewer’s list short by splitting the review among managers.

Reviewing exceptions only, with the standard role pre-approved, shrinks the workload and focuses attention where risk sits.

What to look for

When you scan the results, certain patterns deserve a closer look:

• Users with rights from a previous role as well as the current one
• Admin permissions held by people who rarely use them
• Dormant accounts that still count against licences
• Shared or generic accounts
• Accounts with a mismatch between role and department
• Contractors past their agreed end date
• Integration accounts with broader access than their function needs

A common trap is accepting “they might need it” as a reason to keep access. Make the default removal unless someone can state the need, because access that’s removed can be restored in minutes.

Close the loop

Collecting decisions isn’t the finish line. Track the changes through to completion, because a “remove” decision that nobody actions is the worst outcome of all. Record who reviewed, what they decided, when the change was made, and keep the evidence for audit. If a reviewer doesn’t respond by the deadline, escalate in a defined way, for example to their own manager, rather than silently approving.

Review cycle at a glance

Stage	What happens	Typical owner
Prepare	Export users, roles, exceptions and last sign-in	CRM admin
Distribute	Send each manager their team’s list with a deadline	Security or admin
Decide	Keep, change or remove for each exception	Line manager
Action	Apply changes and log completion	CRM admin
Escalate	Chase non-responses through a defined route	Security
Report	Summarise results and retain evidence	Governance lead

A hypothetical example

A growing company runs its first review. The admin exports the user list and finds two surprises: a former marketing manager now in sales who still holds marketing admin rights, and a set of integration accounts with full administrator profiles because that was the quickest way to get them working. The line managers handle their staff in a week, and the admin spends a few days on the service accounts, replacing the all-powerful profile with narrower ones and recording an owner for each. Nobody loses access they actually need, and the next review is faster because the exceptions list is now short and documented.

Frequently Asked Questions

How often should we review CRM access? Base it on risk and capacity. Higher-risk groups such as administrators merit more frequent checks, and a rhythm you can keep is better than an ambitious one you abandon.

Who should approve access, the manager or the data owner? Often both play a part. Managers know whether the person still needs it for their job; the owner of sensitive data decides whether the access level is acceptable. Define which decision belongs to whom.

What if a manager approves everything without looking? Reduce the review to exceptions, require a short reason for retained elevated access, and sample a few approvals yourself. Where it keeps happening, treat it as a process problem.

Do we review read-only users? Yes, though possibly less often. Read-only access to a full customer database is still significant.

Should service accounts be in scope? Absolutely. They commonly have wide permissions, no human watching them and credentials that rarely change. Give each an owner and review its scope.

Next Step

Export your CRM administrators and anyone with bulk export rights today, and send that short list to their managers with a one-week deadline for keep or remove. That small first cycle builds the habit before you scale it.