Inside an access review
A small access-review exercise. Look at the five records, choose what you’d follow up and compare your reasoning with mine.
The useful question is what each record tells us and what evidence is still missing. You’ll see an enabled privileged account, a late removal and a current employee who belongs outside this test.
Which records would you investigate?
Compare the departure dates with account status and the recorded disable dates. Select the records you'd want to understand better, then open my review. There is no score, and you can read the explanation without selecting anything.
- Snapshot date
- 2 October 2026
- Sample policy
- Revoke access by the end of the departure date.
- Evidence limit
- These exports have not yet been reconciled to source systems.
How I would review this evidence
I'd use this comparison to decide what to investigate first. Before calling anything a finding, I need to know that the identifiers match, the extracts cover the right period and the removal deadline applies to the person in question.
For each candidate, I'd trace the HR notification and the account-removal event, check for an approved extension and ask the owner to explain any gap. I would keep the confirmed facts separate from the questions still open.
DEMO-C: start with privileged access
The account is enabled after departure, and the snapshot includes activity dated 2 October. I'd prioritise this record because it also has privileged access. First I'd validate the identity and activity, confirm current access with the owner and use the agreed escalation process if the risk is confirmed.
The activity date raises another question: what actually happened? It might describe a human session, a scheduled process or a different account context. I'd request the underlying event before making any statement about misuse.
DEMO-A: an enabled account after departure
The departure date is 28 September, while the account remains enabled in the 2 October snapshot. That needs follow-up. I'd check the HR effective date, directory identity, extraction time and any approved extension before deciding whether the control failed.
I'd also establish which access depends on this account. The directory status is useful evidence, but the review needs to cover the systems and access routes within its agreed scope.
DEMO-E: disabled now, but apparently late
The current status is disabled. The dates still show an eight-day gap between departure and removal. I'd validate those dates against the source events and compare them with the sample policy.
Disabling the account resolves its current status; it doesn't explain the delay. I'd follow the notification and removal workflow to understand where the hand-off broke down before recommending a process change.
DEMO-B: no exception in this sample
The recorded disable date matches the departure date, so this comparison doesn't identify a timeliness exception. I'd retain the supporting event and the basis for the conclusion.
If the review also covers separate application accounts, those need their own evidence. Two matching directory dates only answer the question they actually cover.
DEMO-D: outside the leaver population
This person is still employed. An enabled account is expected, and the record falls outside this departure review.
A periodic access review might ask whether the permissions are appropriate for the current role. That's a different question, with a different population and evidence requirement.
How I'd document the finding
I would record the removal requirement, the confirmed condition and the evidence that supports it. The workpaper should also explain the population, period and any limitations, so someone else can follow the test.
The finding then needs a clear risk and an action that addresses the confirmed issue. I'd agree the owner and due date, distinguish immediate access removal from fixing the process, and verify the closure evidence. The sample finding shows that structure without inventing a management response.
Read the fictional finding