Matching leavers to directory accounts

The comparison behind the control

An HR list describes people and departure dates. A directory export describes accounts and their status. To test whether access was removed on time, the two sets of records have to line up.

I wrote a PowerShell automation script to extract and reconcile the Active Directory user list against the HR termination list. It supported operating-effectiveness testing for user access reviews.

My contribution

The script made the comparison easier to review. It reduced the repetitive work of matching records and helped identify the accounts that needed an explanation. I kept the reconciliation separate from the audit conclusion: a difference between exports is a starting point for follow-up.

Before trusting a reconciliation

In a review like this, I’d first establish what each extract covers and when it was taken. I’d check the matching identifier, look for duplicate or missing identifiers and understand how the review handles people with more than one account.

A display name can be a useful clue, but I wouldn’t use a similar-looking name as the only evidence that two records belong together. Where the match is uncertain, I’d keep that uncertainty visible and resolve it with the source owner.

The timing also matters. A current snapshot answers a current-status question. A test of timely removal needs the effective departure date, the required deadline and evidence of when the account was disabled.

The records I’d follow up

The fictional walkthrough includes three candidates. Two accounts remain enabled after departure. One account is disabled now but was apparently removed eight days late. The sample policy requires removal by the end of the departure date.

There are also two records that don’t identify an exception in this comparison: one account was disabled on the departure date, and one belongs to a current employee outside the leaver population. They help show why the scope matters.

I’d give the enabled privileged account earlier attention, validate the evidence and follow the agreed escalation process if the exposure is confirmed. A recorded activity date would prompt another evidence request; it wouldn’t justify an unsupported claim about misuse.

Where the directory evidence ends

Disabling an AD account tells us about that account. A review covering separate application accounts, privileged identities or other access routes needs evidence for those routes as well.

I’d agree the scope before testing, then follow the requirement through to the evidence for removal. That avoids treating a directory status as proof of an organisation-wide outcome it cannot establish on its own.

What I’d put in the workpaper

The sources and extraction dates, the population, the matching rule, the required deadline, any unresolved matches and the evidence behind each disposition. Someone reviewing the work should be able to follow the comparison and understand why a record was treated as an exception.

The automation reduced manual effort. Its value was in making the reconciliation easier to inspect, while the follow-up still established the condition, risk and appropriate next action.