Grant the access that was actually approved

What this means for your practice

Use the organisation's approved access process and keep approval scope explicit. Automation should carry out authorised decisions, not infer broader permissions from a general onboarding request.

A practical conversation with your supplier

Ask to request a limited fictional role, then compare approved and actual permissions. The supplier should show the approval reference without relying on an ambiguous email summary. Your organisation's access process defines the decision; automation carries out that decision and makes discrepancies visible.

Plan the first improvement

Prepare a role-specific access request that names the systems and level of access needed. The manager should be able to understand the request without learning each product's internal terminology; the authorised administrator can translate it into the relevant roles. Keep the approval connected to that specific request so a later change does not appear covered by an earlier broad consent. Ask the supplier how exceptions are handled when a standard role does not fit the job. The exception should receive the organisation's normal review rather than prompt a broad default grant.

Once setup is complete, compare actual permissions with the approved scope and record unresolved differences. Include systems that require manual administration in the same completion view. This prevents a central automation reporting success while a separate tool was missed or granted more access than approved. Review recurring mismatches with the people defining roles, since they may indicate an unclear request form as much as a technical setup problem.

How to check the result

Track access grants that differ from the approved request.