A practical way to connect people, service identities and integrations to the business information they can reach.
Start with one business service
Choose an activity such as customer support or order processing. List the cloud applications it depends on and the identities used by employees, administrators, workloads and external providers. A server inventory alone will not show these relationships.
For each identity, record its business purpose and owner. If ownership is unclear, make that an explicit follow-up rather than assuming that an old account is safe to remove.
Separate human access from machine access
Employee permissions and application permissions need different review methods. A person may have a manager who can confirm their role; a workload needs a technical owner who understands its dependencies. Review both the permissions granted and how the identity authenticates.
Check whether broad access was granted for setup and then left in place. Confirm what is still required before changing it, particularly where an integration supports production activity.
Review the route to sensitive information
Trace what the identity can read, change, share or delete. Look beyond its display name: an apparently routine integration may have access across a workspace or storage account. Prioritize administrative and data export capabilities.
Document the intended audience for shared information. External links and guest access should have an owner and a reason to remain active.
Make the review actionable
Record the decision, supporting evidence, implementation owner and due date. Keep exceptions visible, with an expiry or reassessment date. Validate important changes with the service owner so security improvements do not silently break the business workflow.
A useful access review ends with decisions that can be implemented and checked. Discuss the wider environment on our Cloud Security page.
Put the guidance into practice
Discuss the scope, responsibilities and evidence that would help your team make progress.
Follow the permissions behind an automated job
A reporting job uses an application identity to read data from several cloud services. Its original developer has changed roles, while the job still holds broad permissions and a long-lived secret. A workforce access review will not necessarily find it. Identify the application owner, the resources it needs and the reason for each permission. Review how credentials are managed and how a change would affect the job before narrowing or replacing access.
Evidence to collect
- Include workforce users, guests, service principals, workload identities and privileged roles.
- Check direct permissions, inherited groups and the scope at which each role is assigned.
- Identify credential owners, expiry or rotation arrangements and unattended dependencies.
- Record the evidence used to validate that required tasks still work after an authorised change.
What a useful result looks like
Review effective access rather than relying on a role name. A narrowly named role assigned at a broad scope may still expose more resources than intended. Separate dormant access from access that is rarely used but operationally necessary. Where a purpose cannot be established, agree a controlled investigation and decision rather than removing a dependency without an owner.
Does deleting a user account remove all of their former access paths?
Not necessarily. Applications, shared secrets, delegated permissions and external accounts may persist independently. The review should follow the identities and credentials used by the service, with a safe plan for replacing or revoking them.