What Is an Access Review?
An access review is often treated as a routine administrative task, but the decision behind it is a security decision. The common mistake is to ask only whether an account still exists or whether a manager recognizes a person’s name. The real question is whether each user or system account still requires every permission it currently holds, based on present responsibilities and present business need. That distinction affects whether unnecessary access is removed, whether privileged permissions remain exposed, and whether the organization can show that access is being governed rather than merely recorded. In this episode, we will examine what an access review is, who should participate, what evidence reviewers need, and why sending a spreadsheet to a manager is not enough. By the end, you should be able to explain what makes a review meaningful and what separates a genuine security control from a paperwork exercise. An access review is a structured examination of existing permissions to determine whether they should be retained, changed, or removed. A permission is an approved ability to view information, use a function, change a setting, administer a system, or perform another protected action. Those permissions may be assigned directly to an account, inherited through a role, granted through a group, or obtained through another connected system. User accounts represent people, while system accounts support applications, services, automated processes, devices, or integrations. The review connects identity, responsibility, resource sensitivity, and actual authorization so that someone accountable can decide whether the current access remains justified. Access reviews are often confused with account inventories because both may begin with a list of identities and permissions. An inventory shows what exists. A review evaluates whether what exists is still appropriate and produces an accountable decision. Access reviews are necessary because access rarely remains perfectly aligned with responsibility over time. People change jobs, join projects, leave temporary assignments, move between departments, and accumulate permissions that were once useful but are no longer needed. Applications also change, groups are repurposed, roles expand, and old integrations remain active after the original business requirement disappears. This gradual accumulation is often called access creep. It does not require anyone to act maliciously. It happens when granting access is easier and more visible than removing it, especially when organizations lack clear ownership or reliable offboarding processes. A review interrupts that drift by comparing current access with current need. The purpose is not to prove that every permission was originally approved. The purpose is to determine whether each permission is still appropriate now, because a valid approval from the past does not automatically justify continued access in the present. A meaningful review requires more than one kind of knowledge, so participation should match the decision being made. A manager may understand a person’s current duties, but the manager may not know what a technical group name allows or which systems contain sensitive data. A system owner or application owner can explain what a role or permission enables. A data owner can judge whether access to particular information is appropriate. Identity and Access Management (I A M), security, compliance, or governance personnel may prepare the access data, identify higher-risk permissions, coordinate the process, and verify that decisions are completed. Human resources records may help confirm employment status, organizational placement, or contract end dates, but they do not determine technical need by themselves. System accounts also require a named owner who understands their function. The best reviewer is therefore the person who can evaluate need with enough business and technical context, not merely the person who received the spreadsheet. Reviewers should examine the complete path by which an account receives access, not only the most visible permission. Direct assignments matter, but so do group memberships, nested groups, inherited roles, shared accounts, delegated administration, cloud permissions, and entitlements granted through connected applications. A reviewer should understand what resource is affected, what actions the permission allows, whether the access is privileged, why it was granted, and whether the account still performs the function that justified it. Temporary access should have a clear end point. Dormant accounts, unused privileges, orphaned accounts, duplicate identities, and permissions connected to departed personnel require special attention. Recent use can provide useful evidence, but lack of use does not automatically prove that access is unnecessary, and recent use does not prove that it is appropriate. The review must connect technical access data to an authorized purpose rather than relying on one indicator. User accounts and system accounts need different questions even though both are part of the same review. For a user account, the reviewer should compare permissions with the person’s current role, assigned duties, employment status, location when relevant, and need to access the protected resource. For a system or service account, the review should identify the accountable owner, the application or process that uses the account, the resources it can reach, and whether its permissions are limited to that function. An account that runs an automated task should not remain active merely because disabling it might cause uncertainty. The organization should be able to explain what depends on it and what access it truly needs. Shared accounts deserve additional scrutiny because individual accountability may be weak. System accounts can hold powerful, long-lived access, so treating them as technical exceptions rather than governed identities creates a serious gap. Good access review data must be understandable, complete, and current enough to support a decision. A technical export may contain role identifiers, group names, application codes, or permission labels that mean little to the person asked to approve them. Reviewers need plain-language descriptions of what the access permits, the sensitivity of the resource, whether the access is administrative, and how the permission was obtained. They may also need the account owner, manager, department, last review decision, creation date, expiration date, and reason for access. No single field decides the outcome, but together they help the reviewer distinguish normal access from unexplained or excessive access. The source data also needs validation because missing groups or stale account records can create false confidence. A review based on incomplete information may produce clean approvals while leaving important access outside the scope. Before we continue, this episode is brought to you by the Bare Metal Cyber Academy. The Academy is a place for people who want to continue developing practical cybersecurity knowledge through clear, structured education. Topics such as identity, permissions, governance, risk, and security operations become more useful when they are explained in a way that connects the technical details to real decisions. You can visit Bare Metal Cyber dot com and explore the Academy to see the learning opportunities currently available. The goal is steady professional development without exaggerated promises or unnecessary complexity. Now, let’s return to access reviews and examine why a completed approval request may still fail to provide meaningful assurance. Simply sending a spreadsheet to a manager is not enough because the act of distributing a list does not create informed review. The spreadsheet may be incomplete, filled with technical labels, missing indirect access, or based on data that was already stale when it was exported. The manager may know the employee but not the system, the data, or the effect of each permission. Large lists encourage rapid approval, especially when every row appears equally important and the reviewer receives little time or guidance. Some organizations also treat silence as approval or accept a blanket response for hundreds of entitlements. That process measures completion rather than judgment. A defensible review gives the reviewer enough context to challenge access, highlights high-risk items, allows specific decisions, records the reason for exceptions, and confirms that removals actually occurred. Without those elements, the spreadsheet becomes evidence that a request was sent, not evidence that access was properly evaluated. An access review should produce explicit decisions and completed actions. Common outcomes include retaining access because it remains necessary, modifying access because the current permission is broader than needed, or removing access because the need has ended. A reviewer may also identify an ownership problem, an unclear role, a duplicate account, or a permission that requires further investigation. Uncertainty should not be converted automatically into approval. The decision can be escalated to the appropriate owner, but it still needs resolution. When access is marked for removal, a ticket or workflow entry is only the beginning. The change must be implemented in the authoritative system and then verified. Failed removals, inaccessible target systems, and manual dependencies can leave access active after the review is recorded as complete. The control is effective only when the decision changes the real permission state and the organization can demonstrate that result. Higher-risk access deserves greater scrutiny than ordinary access. Administrative roles, security configuration privileges, access to sensitive records, the ability to create accounts, and permissions that can approve or execute important transactions can produce greater harm if misused or compromised. Reviewers should also look for combinations of access that defeat separation of duties, even when each permission appears reasonable by itself. Emergency or break-glass accounts need clear ownership, restricted use, strong monitoring, and regular confirmation that they remain necessary. Privileged access may require review by both a manager and a system or resource owner because neither perspective alone is sufficient. Risk-based review does not mean ignoring lower-risk access. It means directing more attention, stronger evidence, and more frequent validation toward permissions with greater potential consequence. A long list should not make a powerful privilege look routine simply because it appears beside many ordinary entries. Access reviews should occur on a cadence that reflects risk, but periodic schedules are not the only trigger. Highly privileged access, sensitive systems, and regulated information may require more frequent review than low-impact resources. Job changes, transfers, contractor end dates, extended leave, system migrations, organizational restructuring, and changes in application ownership can also create immediate reasons to review access. A security incident may reveal that a specific account or permission set needs examination before the next scheduled cycle. Event-driven reviews are important because access can become inappropriate the moment responsibilities change, not only when a quarterly or annual calendar date arrives. The review program should therefore combine regular recertification with timely triggers from identity lifecycle processes. A calendar provides consistency, while lifecycle events reduce the period during which outdated access remains active. Neither approach is sufficient when used alone. Access review evidence should show what was reviewed, who made the decision, what information was available, when the decision occurred, and what happened afterward. The organization should preserve the source of the access data, the scope of accounts and systems, the reviewer assignment, the decision for each item, the reason for exceptions, and proof that required changes were completed. This record supports audits, but audit readiness is not the only purpose. Clear evidence helps security teams identify repeated problems, such as roles that are consistently overbroad, managers who cannot interpret technical access, or systems that cannot reliably remove permissions. Access review is also different from access provisioning and activity monitoring. Provisioning controls how access is granted or changed. Monitoring observes how accounts are used. Review evaluates whether the existing authorization remains justified. A mature program connects all three so that approvals, actual permissions, and observed use can be compared. A practical way to test an access review is to follow one permission from source data to final verification. First, determine how the account receives the permission and whether the review captures that path. Then ask whether the assigned reviewer understands the account’s current purpose, the resource being protected, and the actions the permission allows. Confirm that the reviewer can choose a specific outcome rather than approving an entire list without examination. Check whether higher-risk access is clearly identified and whether temporary or exceptional access includes an owner and an end condition. Finally, trace a removal decision into the target system and verify that the permission is no longer active. This test exposes common gaps in data quality, reviewer context, accountability, and remediation. If the process cannot explain one permission from discovery through decision and completed action, the larger review may be producing records without producing reliable access control. An access review is a controlled decision process that checks whether users and system accounts still need the permissions they currently possess. Managers contribute knowledge of responsibilities, while system owners, data owners, security personnel, identity teams, and account owners provide the technical and risk context needed for an informed judgment. Reviewers should examine direct and indirect access, privilege level, current purpose, ownership, temporary grants, dormant identities, conflicting permissions, and the actual effect of each entitlement. A spreadsheet can support the process, but sending it to a manager does not complete the control. The review becomes meaningful only when the data is complete, the reviewer understands what is being approved, each decision is recorded, unnecessary access is changed, and the final system state is verified. The practice to carry forward is simple and specific: every retained permission should have a current owner, a current purpose, and evidence that someone qualified deliberately confirmed both.
