What share of access grants are reviewed on schedule?

Question and scope

This review asks what share of access grants are reviewed by their scheduled date. The unit is one grant of access to one person for one client or system. The scope covers named accounts and shared links used by an assistant team. The review does not estimate a universal rate, because the review cycle and the risk level vary by client.

The question matters because an access review that happens late is not the same as one that happens on time. A grant may be appropriate at the scheduled date and inappropriate a month later when the task ends. The delay is a window of unnecessary access. Counting the window makes the risk visible.

The review separates a late review from a missing decision. A late review may still produce a keep or remove decision. A missing decision leaves the grant in place with no owner. The first is a scheduling problem, while the second is a governance problem. Report both so the fix is not just a reminder.

Build the list from the systems

Start with the access list from each system rather than a list of people. Export the named accounts, the roles, the shared links, and the last sign-in date. Match the accounts to the client and the role. A list built only from the org chart will miss the service accounts and the shared mailboxes. Compare the export with the client contact list before counting the reviews.

Record the grant date, the scheduled review date, the last review date, and the owner. Add the business reason and the task the access supports. A grant without a reason is a candidate for removal even when the person is active. The reason should be specific enough to test.

Include the accounts that were created outside the normal request path. A tool may have invited a user directly, or a client may have shared a link without a ticket. Those grants are the easiest to miss and the most likely to outlive the work. Add them to the list before counting.

Define on-schedule

Choose the scheduled date from the access policy or the client agreement. A quarterly review means the grant should be reviewed within the quarter, not on the last day. Write the rule and the grace period at the top of the report. A definition with no grace period may count a one-day delay the same as a year.

Record the date the review was completed, not the date the ticket was opened. A ticket can sit open for weeks while the access remains unchanged. The completion date is when the decision was recorded and the change was made. Use the same definition for every row.

Treat a review with no evidence as late. A note that says reviewed without a decision or a source is not a completed review. The report should show the missing evidence separately from a late review. That difference tells the team whether it needs a calendar or a better record.

Analyze the gaps

Report the share reviewed on schedule, the share late, and the share with no review. Add the median delay and the oldest unreviewed grant. A high on-schedule rate with a few very old grants may be more dangerous than a moderate rate spread evenly. The tail matters because old access is often the least justified.

Group the results by client, system, and owner. A client with many late reviews may have a different process or a missing contact. A system with many late reviews may not support a proper review export. An owner with many late reviews may have too many grants to manage.

Compare the access list with the task list. A grant that supports a task that ended should be removed regardless of the review date. A grant that supports a current task should have a reason that matches the work. The comparison often finds access that is current in the calendar but obsolete in practice.

Interpret the result carefully

A late review does not prove that the access was misused. It shows that the control was not applied on time. The team should look at the grants that were late and sensitive before drawing a conclusion. A late review of a read-only dashboard is different from a late review of an administrative account.

A high on-schedule rate does not prove that the permissions are correct. The reviewer may have approved every grant without checking the work. Pair the timing with a sample of decisions. The sample should ask whether the permission still matches the task, not only whether the review happened.

Look at the grants that were removed during the review. A high removal rate may mean the access was not maintained during the cycle. A low removal rate may mean the review is not challenging the status quo. Neither is automatically good. The pattern should be read with the task changes during the period.

Controls that help

Put the review date on the same calendar as the role review and the client check-in. A date that lives only in a spreadsheet is easy to postpone. Give the review a named owner and a backup. The owner should see the list before the date, not on the date.

Make the decision easy to record. Use a short keep, reduce, remove, or repair choice with a reason and an evidence link. A reviewer who has to write a paragraph for every grant will delay the review. A simple form with a clear standard is more likely to be completed.

Remove access when the task ends rather than waiting for the next cycle. The review is a backstop, not the only control. Add an offboarding step to the task closure. Test the removal with a sample of closed tasks. The best review is the one that finds less unnecessary access.

Method and limitations

This review describes a local measurement method rather than a study of access review rates across providers. The sources define access control and identity good practice, not a benchmark. The actual rate depends on the client systems, the review cycle, and the records available. A team should measure its own list before setting a target.

The access list may be incomplete. A direct invitation or an unmanaged link can create access that never appears in the export. The review should say which systems were included and which were not. A result based on a partial list is a floor, not a full census.

Decision checklist

Build the list from each system, including shared links and direct invitations. Record the grant, scheduled review, last review, owner, reason, and task. Define on-schedule with a grace period and require evidence. Check the list against the client contact list before counting.

Report the on-schedule share, the late share, and the unreviewed share. Group by client, system, and owner. Pair timing with a sample of decisions. Add an offboarding step and test removals after task closure.