How to Run an MSP Client Access Review

An MSP client access review checks whether each account still needs the permissions it holds. The useful output is a documented decision, followed by a verified change where access should be reduced or removed. An exported user list alone does not establish either outcome.

Permissions can outlive the reason they were granted. Employees change roles, contractors finish projects, applications acquire new owners, and temporary administrative access becomes permanent. A repeatable review helps the MSP and client identify those gaps without treating every unfamiliar account as safe to delete.

Build the process around four questions: who or what has access, what can that identity do, who can justify the access, and what evidence shows the final decision was implemented?

Agree on scope and decision authority

Define the systems and access types covered by the review. Include the identity platform, important business applications, file repositories, remote access, administrative consoles, and relevant supplier access. Record systems outside the MSP's control and identify who will review them.

Put this responsibility in the MSP service catalogue. State whether the service includes gathering evidence, coordinating client approvals, changing permissions, and verifying the result. Those are separate activities, and a reporting service should not silently become authority to revoke access.

Name the client owner who understands each resource's business use. The MSP can explain technical permissions and identify concerns; the finance manager or application owner may be better placed to judge whether a particular task remains necessary.

Agree on a review period, response deadline, escalation contact, and treatment of unanswered requests. Silence should produce an unresolved item and the agreed escalation. Automatic removal is appropriate only where a specific policy, scope, and recovery process have already been authorized.

Build a dated inventory of effective access

Collect evidence from each system rather than assuming the central directory contains every account. Applications can have local users, separate administrators, guest identities, and integrations that remain active independently of an employee's main login.

For each access entry, record:

1. The client, system, and stable account identifier.
2. Whether the identity belongs to an employee, guest, administrator, supplier, or automated service.
3. The resource and permission being reviewed.
4. How access is granted, including direct assignments and relevant group membership.
5. The business owner, current purpose, and any agreed expiry.
6. The evidence source, collection time, and available activity history.

Follow inherited permissions where the platform supports them. Removing a direct assignment may leave the same access available through a group or another role. Record any limitation that prevents a complete view.

Treat activity as context. A missing interactive sign-in does not prove a service account is unused, and recent activity does not establish business authorization. Protect the inventory itself: it describes the client's security structure and should contain no passwords, recovery codes, or secret token values.

Give reviewers enough context to decide

Send each owner a focused list of the access they can assess. Translate technical role names into practical capabilities: reading payroll records, changing payment details, administering accounts, or downloading a shared project folder.

Ask whether the identity still represents the expected person or service, whether its purpose remains valid, and whether its permissions exceed that purpose. Offer clear decisions: retain, reduce, remove, or investigate. Require a reason for retained sensitive access and a specific target permission when access should be reduced.

Separate the business decision from technical execution. A manager may confirm that an employee needs to prepare invoices without knowing which application role provides that capability. The MSP should map the requirement to an appropriate permission and confirm any ambiguity before changing it.

For a hypothetical employee moving from finance to sales, the review might retain customer-management access while removing payroll access. This is an illustrative decision pattern, not a claim about a real client. Review the old role's permissions explicitly; adding the new role does not resolve them.

Review service accounts and MSP access separately

Automated identities need an owner who understands the workload. Record the application, scheduled job, integration, or device that uses each service account, the resources it reaches, and the permissions needed for that function.

An account with no known owner requires investigation. Check configuration references, job schedules, relevant authentication records, and supplier documentation before proposing retirement. A rarely used recovery or reporting workflow may not appear in a short activity window.

Separate routine administrative identities from ordinary employee accounts. Review emergency access against the client's recovery procedure, including who can use it and how its use is observed. Low activity may be expected for an emergency account; its purpose and safeguards still need confirmation.

Include the MSP's own delegated access, technician roles, remote-management permissions, and integration identities. Confirm that each assignment still serves the client and that former staff cannot retain access through an overlooked account or credential. Keep tenant boundaries explicit when the MSP uses a shared management platform.

Turn decisions into controlled changes

Create a remediation record for every approved reduction or removal. Capture the identity, resource, current permission, requested final state, approver, implementer, planned timing, and verification method. Record dependencies that must move before the old access can end.

Use the existing MSP change management process for changes that could interrupt service. Reducing an integration's permissions or retiring a service identity needs appropriate testing and recovery planning, even when the business decision is straightforward.

For routine user changes, confirm the correct client and account before execution and communicate any expected effect. Follow the platform's supported approach to disabling access, handling sessions, and preserving data. Account deletion, license removal, and loss of access can have different consequences; choose the action that matches the approved outcome.

Keep urgent security cases on the incident path. An indication of compromise or unauthorized access should not wait for the next scheduled review or ordinary response deadline. Preserve relevant evidence and involve the authorized responders.

Verify both removal and continued work

A completed ticket proves that someone recorded an action. Verification should establish the resulting permissions and, where relevant, whether existing sessions or other access paths remain usable.

Recheck the affected role assignments, group memberships, delegated permissions, and application access using suitable platform evidence. Where a controlled access check is appropriate, use an authorized test method without collecting a user's password or assuming their identity informally.

For a permission reduction, verify that the approved business task still works and that the removed capability is unavailable. For an automated account, check the relevant job or integration through a representative operating cycle. A successful immediate test may not cover a scheduled overnight process.

Record the time, evidence, tester, and limits of the checks. If a platform has a documented propagation delay, verify again after the appropriate interval. Mark incomplete verification as pending rather than closing the item because the administration screen accepted the change.

Keep exceptions and unanswered items visible

Some access may need to remain temporarily while a supplier adjusts an integration or a client transfers responsibility. Record the reason, accountable owner, relevant risk, temporary controls, next action, and review date. Obtain approval from the person authorized to accept that arrangement.

Use distinct states for awaiting decision, approved change, implemented, verified, and time-limited exception. Those states prevent a signed review from being mistaken for completed remediation.

Report the defined review population alongside missing evidence, outstanding responses, unverified changes, and expiring exceptions. A completion percentage should explain its denominator and should not hide a critical unresolved administrator account among ordinary users.

Feed the findings into everyday access management

Look for repeated causes: missing leaver notices, unclear resource ownership, permissions copied from another employee, or temporary roles without an expiry. Correct the request and approval process responsible for the pattern.

Establish owners and access boundaries during MSP client onboarding. Then connect ongoing reviews to role changes, project completion, supplier changes, and application transitions. Scheduled reviews provide a backstop; they should not replace timely action when an access need ends.

Close each review with a dated decision record, verified changes, and named owners for remaining work. The MSP should be able to explain what was reviewed, why access remains, what changed, and which uncertainties still need a decision.