An engineer left a month ago and their production cloud access still worked — which access review failed, and what evidence would prove it now runs?

## Why access outlives the person Offboarding usually starts and stops at the company directory: the directory account is disabled, every federated sign-in path stops, and the checklist is ticked. That is genuinely most of the job, and it is also why the residue is invisible. Anything that authenticates **against the account itself** never consults the directory and is therefore untouched by the disable: a local platform login created before federation arrived, a long-lived static key made by one, a credential handed to an integration on someone's behalf, or an exception granted directly to a person during an incident and never withdrawn. A month later, that is what is still working. Nothing malfunctioned; the process simply never looked in the account. ## Which review this is | Leg | Trigger | What should happen | The usual failure | |---|---|---|---| | Joiner | a person starts | added to the groups their role implies; no account is edited | over-granting on day one by copying someone senior | | Mover | a person changes role | old groups removed as new ones are added | the old access is never removed, so access accretes | | Leaver | a person departs | directory account disabled, then the accounts reconciled | only the first half happens | | Recertification | a calendar date | every principal matched to a current owner | it runs as a rubber stamp, or not at all | The leaver leg is **event-driven** and fast but only reaches what the directory knows about. Periodic recertification is **slow and complete**: it is the only one that looks at what the account holds and asks who owns it. You need both, and this incident is what it looks like when the second one is missing. The mover leg is worth naming too, because it is where access quietly accumulates on people who are still there — a review that only ever looks at leavers will keep finding nothing while the real problem grows. ## The reconciliation that closes it 1. **Enumerate what the account itself holds**: every local login, every static key with its age and last use, every grant made directly to a person rather than through a group, and every credential held by an integration. 2. **Match each one to a current directory person or a named owning system.** Anything that cannot be matched is the finding. 3. **Act on the unmatched** — remove it, or give it a named owner and an expiry date if it genuinely must stay. 4. **Feed the leaver process** with what you learned, so the next departure checks the same places automatically instead of relying on the quarterly sweep. 5. **Keep the output**, because the output is the evidence. Run the same reconciliation in the other direction as a sanity check: for a sample of recently departed people, actively try their old paths. A review that only reads lists will miss a path that is not on any list you thought to pull. ## What counts as evidence The question 'how do you know the review happened' has a specific, checkable answer, and in a regulated business somebody will ask it: - **A dated record** for each account, naming the account and the period it covers. - **The complete list** of principals as they were on that date — not a summary, and not only the ones that changed. - **A named reviewer** who is accountable for the account, and who is not the same person as the one whose access is being reviewed. - **The disposition of every line**: kept, removed, or kept as an exception with an owner and an expiry. - **The removals actually carried out**, traceable to the record of management calls that performed them. A chat message saying 'reviewed, all looked fine' is not evidence of anything except that someone was asked. A review that removed nothing is not automatically wrong, but it is the result that deserves a second look, because on a real estate of any age the first honest reconciliation almost always finds something. ## What an interviewer listens for The weak answer is 'someone forgot to delete the user'. The answer that lands separates the two mechanisms — the event-driven leaver leg against the periodic reconciliation — explains *why* the directory disable was not enough (it only governs the federated path), and then produces the evidence standard without being asked. A candidate who adds 'and I would fix the leaver process so the quarterly review stops being the thing that catches this' is describing the actual repair, since a control that only detects is a control you will be relying on for a month at a time.