# Make access reviews explainable and actionable > Turn raw permissions into grants with source, scope, owner, use, expiry, and removal impact so reviewers can make safe decisions. Canonical URL: https://www.devobs.io/articles/explainable-access-reviews/ By: Ines Costa Published: 2025-07-26T03:49:21.518Z Updated: 2026-09-06T10:18:15.722Z Section: Authorization An access review should answer three questions for every grant: why does this person have access, what exactly can they do, and what breaks if it is removed? A dump of users, groups, and permissions shifts the graph-analysis work onto reviewers and produces rubber-stamping. ## Review grants, not rows Normalize each effective grant into subject, action set, resource scope, source path, granting owner, creation time, expiry, last observed use, and sensitivity. “Maya can administer Project Phoenix through Employees → Engineering → Phoenix Maintainers” is reviewable. Three unrelated membership rows are not. The [Zanzibar paper](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) shows how relationship-based systems derive decisions from stored relations and policy configuration. For review purposes, retain the path that produced the answer. If several paths grant the same action, show them together because removing one path may not remove effective access. Nested groups need cycle detection, depth limits, and provenance. Expand them for computation but keep the human explanation compact. A reviewer should be able to open the path and see each parent group and owner. ## Attach useful context Prioritize grants by resource sensitivity, privilege, unusual scope, inactivity, missing owner, and imminent expiry. “Last used” is helpful evidence, not a decision by itself: absence may mean missing telemetry, seasonal work, or an emergency role. NIST [SP 800-53 Revision 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) provides a broad catalog of access-control and audit controls, including account management, least privilege, review, and logging concerns. Translate those control goals into evidence a product reviewer can understand rather than displaying control identifiers. Show the granting event and its owner. A direct grant from a departed administrator is more suspicious than membership in a team owned by a current manager. Attach the ticket or approval when available, but keep the review functional if an external system is unavailable. ## Calculate removal impact Before applying a revocation, recompute effective access without the selected edge. Report whether the subject loses the permission, retains it through another path, or affects other people because a group or role is changing. For service accounts, identify workloads, last authentication, token locations, and owning team. For human access, show expected workflows or recent resource use. Do not claim that inactivity proves a grant is safe to remove. Apply review decisions with optimistic concurrency. The reviewer acts on graph version 42; if membership changes before commit, reject or recalculate rather than applying a decision to a different graph. Batch changes need individual results and a reversible window for mistaken business decisions, while security revocations may require immediate effect. ## Preserve what the reviewer saw Historical reproducibility requires the policy version, relationship snapshot or change sequence, identity status, and explanation algorithm version. A later audit should answer why the review UI said “allowed” on that date even though today’s graph differs. Record reviewer, decision, justification, time, affected grant, execution result, and any retained alternate path. Keep access-review data under appropriate retention and privacy controls; explanations can reveal organization structure and sensitive resource names. ## Design the review queue Route grants to someone who understands both the subject’s job and the resource’s risk. Resource owners review access to their resources; managers can validate employment need; security teams handle high-risk exceptions. Avoid asking one person to attest to facts they cannot know. Give each row clear actions: retain with reason and optional expiry, revoke, reduce scope, transfer ownership, or request context. Make “cannot determine” a valid routed outcome rather than forcing approval. Take one high-privilege role and build an explanation for ten users. If an engineer cannot reproduce each path and predict the result of removing it, improve the authorization query and audit data before launching the review campaign. ## Source references - -