Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Access review reporter series ~5 min read

How a review round runs

Access reviews fail in a completely predictable way: somebody is shown a long list, approves all of it, and a control is recorded as having happened. Everything in this post is about the difference between that and a review that changes something.

Key takeaways

  • One owner reviews one service, not one manager reviewing one person’s everything.
  • The default is keep, and removing is one tap. The reverse produces panicked mass-approval.
  • Last-used dates are shown, because they are what actually informs the decision.
  • No reply is recorded as no reply, not as approval.
  • Twice a year. Quarterly produces the rubber stamp and annual is too slow for a leaver.

Per service, not per person

The two ways to slice a review are by person — here is everything Jo can access — and by service — here is everyone who can access the file storage. Both are defensible and the second works much better in a small business.

Per person requires a manager to have an opinion about eleven services they may not use themselves. Per service asks one person who genuinely understands that service about a list of names they recognise, which is a question somebody can answer well in two minutes.

How a twice-yearly access review round is runA vertical chain of five steps entered by a box labelled Review round opens, twice a year. Step one sends one message per service, to its named owner only. Step two shows the list of names, roles and last-used dates. Step three sets the default to keep, so removing is the action. Step four asks whether there are any removals; if so it exits to A task assigned to them, with a link to the service's admin page. Step five records who answered, when and what. A note says default-keep is deliberate, because default-remove produces mass approval out of fear.AWS ACCOUNTReview round openstwice a yearOne message per serviceto its owner onlyService ownersone each, namedThe listnames, roles, last usedDefault is keepremoving is the actionAny removals?A task, to themwith a link to the admin pageyesRecordedwho answered, when, whatDefault-keep is deliberate. Default-remove produces mass approval out of fear.
Fig 1. How a review round is delivered. The default matters more than anything else in the design: it determines whether somebody reads the list or protects themselves from it.
  • App integration
  • Machine learning
  • Management
  • People

Why default-keep

A review where inaction removes access sounds more rigorous and produces worse outcomes. Owners who are busy will approve everything rather than risk breaking somebody’s access, and the review becomes a formality with higher stakes.

With default-keep, doing nothing is honest — it is recorded as no reply rather than as approval — and the only action available is the one that requires a positive decision. In practice that produces more removals, not fewer, because the owner is looking for candidates rather than defending a list.

Last-used dates

The single most useful column and the one many services do not expose. Where it is available, an account that has not been used in five months answers the review question on its own; where it is not, the owner is deciding from memory.

So the collector captures it wherever the API offers it, and the review sorts by it descending so the least-used accounts are at the top of the list. That ordering alone changes the outcome of a review measurably.

What no reply means

How an unanswered access review is escalated and recordedA horizontal row of five boxes. Sent: to the owner. Reminder: at seven days. Their manager: at fourteen days. Recorded as no reply: never as approved. In the summary: three of fourteen not reviewed. A note says a review record that counts silence as approval is worse than no record.SILENCE IS NOT APPROVALSentto the ownerReminderat 7 daysTheir managerat 14 daysRecorded as no replynever as approvedIn the summary'3 of 14 not reviewed'A review record that counts silence as approval is worse than no record.
Fig 2. How an unanswered review is handled. Recording silence honestly is what keeps the review record worth anything.
  • App integration
  • Management
  • Analytics
  • People

This is the one place where an access review system can quietly become dishonest, and it happens by accident: a schema with an approved boolean defaulting to false gets reported as “11 approved, 3 pending” and then, next quarter, as “14 reviewed”. A three-state field — reviewed, removals requested, no reply — makes that impossible.

Twice a year

Quarterly is the common recommendation and it produces the rubber stamp: four rounds a year of the same list generates fatigue quickly, and the second round is already being approved without reading. Annual is too slow to be the only control, but it is not the only control here — the leaver check runs weekly and catches the urgent case.

Twice a year is short enough to remember what the service is for and long enough that the list has genuinely changed since last time, which is what makes reading it worth doing.

Next: the weekly leaver check, which is where most of the value is.

All posts