Skip to content
allanninal.dev/build
Collaborate

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

How leavers get caught

Everything in the previous three posts is groundwork for a query that takes about eleven lines: which accounts belong to people who are not on the staff list any more. It is worth more than the entire twice-yearly review and it costs nobody any time at all.

Key takeaways

  • The check is a weekly join between the account snapshots and the staff list.
  • A leaver produces one message listing every service they still have access to.
  • The same list is produced proactively on somebody’s last day, as a checklist.
  • Days-to-removal is the number worth watching, and it should trend towards zero.
  • A service that never appears on a leaver list is probably not being collected at all.

The weekly join

How the weekly leaver check finds accounts that should have been removedA vertical chain of five steps entered by a box labelled This week's snapshots, from every service. Step one matches each account against current staff, using a staff list that holds both current people and leavers with their dates. Step two asks whether the person is on the leaver list with a leaving date; if so it exits to Still has access, which is the finding. Step three asks whether the account matches nobody at all, not even a leaver; if so it exits to Unknown account and asks the owner. Step four groups by person so one message covers all services. Step five sends it with the dates: when they left and what they are still in. A note says grouping by person is what makes it one task rather than six separate ones.AWS ACCOUNTThis week's snapshotsevery serviceMatch each accountagainst current staffStaff listcurrent, and leaverswith datesOn the leaver list?with a leaving dateStill has accessthe findingyesMatches nobody at all?not even a leaverUnknown accountask the owneryesGroup by personone message, all servicesSend with the datesleft when, still in whatGrouping by person is what makes it one task rather than six separate ones.
Fig 1. The weekly leaver check. Grouping by person rather than by service is what turns six findings into one afternoon’s task with a clear owner.
  • Database
  • App integration
  • Management
  • Analytics
  • People

One message per person

A leaver with access to six services is one problem, not six. Six separate findings routed to six service owners produces six small tasks with no coordination and a good chance that two of them are done and four are not.

So the message goes to whoever handles offboarding, lists every service the person still has access to, and includes a link to each service’s user administration page. That is a single ten-minute task with an obvious completion condition, which is a far better shape than six two-minute ones.

The proactive checklist

The same query, run in the other direction, produces something more useful than any detection: a list of everything a specific person has access to, generated on the day they hand in their notice.

How the access data produces an offboarding checklistA horizontal row of five boxes. Notice given: with a leaving date. Query their access: from this week's snapshots. A checklist: nine services, each with a link. Last day: worked through. Verified next week: the collector confirms. A note says detection is the backstop and the checklist is what stops there being anything to detect.THE SAME QUERY, USED FORWARDSNotice givena leaving dateQuery their accessfrom this week's snapshotsA checklist9 services, with linksLast dayworked throughVerified next weekthe collector confirmsDetection is the backstop. The checklist is what stops there being anything to detect.
Fig 2. The same data used proactively. The checklist prevents the finding; the weekly check exists to catch what the checklist missed.
  • Machine learning
  • Management
  • Analytics

The verification step is what makes the checklist trustworthy. Somebody ticking nine boxes on a Friday afternoon is not evidence that nine accounts were removed; next Monday’s collection is. A checklist item ticked but still showing in the following week’s snapshot is reported specifically, and it is usually a service where removal requires a step somebody did not realise.

The number to watch

One quarter of offboarding summarised in five numbersA horizontal row of five boxes. Leavers: four this quarter. Accounts: thirty-one between them. Removed on the day: twenty-six. Median days to removal: zero. Worst case: eleven days, on one service. A note says the last two numbers matter, and a median of zero with a worst case of eleven names a service.ONE QUARTER OF OFFBOARDINGLeavers4 this quarterAccounts31 between themRemoved on the day26Median days0Worst case11 days, one serviceThe last two numbers matter. A median of zero with a worst case of 11 names a service.
Fig 3. A quarter of offboarding in five numbers. The gap between the median and the worst case is what identifies the specific service that keeps being missed.
  • Machine learning
  • Management
  • Analytics
  • People

Median days to removal is the headline and it should be zero in a business with a working checklist. The worst case is the more useful number, because it is almost always the same service every quarter — the one whose admin panel is awkward, or whose owner is part-time, or which nobody remembers is a service at all.

The service that never appears

One quiet finding worth mentioning: a service that has never once appeared on a leaver list, across several quarters, in a business with turnover. That usually means its collection is broken rather than that its offboarding is perfect, and it is worth checking specifically because a silently broken collector is indistinguishable from a well-run service.

Next: what all of this costs to run.

All posts