Answer an auditor from your tenant's records, and measure whether governance works

Setup

This lab produces its own leaver, so it does not depend on records older than the tenant's 30-day retention. It also reads review.json and reconciliation.json from the review labs if you kept them.

1. Open a bash shell and set the variables and helpers from the directory lab.

2. Press Start on the lab page.

3. In the HR Simulator, start a Full lifecycle run: 8 people, leavers 25 percent, movers 0, 15 minutes, initial passwords on. Before any leaver's lock event runs, use View password for one leaver and keep it in your password manager.

Walkthrough

1. "Show that the leaver's access ended when HR said so." When the leaver's "Leaver: lock (active false)" event has succeeded, note its planned time and Correlation ID in the run. Follow its Audit link: scim.user.lock with a time, actor lab-hr-feed, the subject's ID and the same correlation ID. Then sign in at $ISSUER/login as the leaver with the password you kept: refused, and Audit (Source Protocol activity) records account.sign_in rejected with account_locked. Write the answer: HR's time, the removal time, the gap, the actor, and the refused attempt.

Why it matters: this is "An auditor asks". The account's state today says nothing about when it changed; only records made at the time do. The refused attempt shows the control took effect, not just that a change was sent.

2. Read the record field by field. Open the scim.user.lock event's detail and fill the lesson's table from it:

The reason row stays empty: a SCIM change carries no reason field, so "the contract ended" lives only in the HR Simulator's run.

Why it matters: this is "What good evidence contains". The correlation ID is what joins the HR event, the lock and the refused sign-in into one story.

3. "Show who approved Ava's access to Photo moderation." Search Audit for the group's ID. The tenant.groups.members event that added Ava shows who made the change and when. No approval exists anywhere in the tenant. Write the honest answer: the change and its actor are evidenced; the decision behind it is not.

Why it matters: an approval kept in an email or a note cannot be linked to the change it authorized, which is the gap G23 would close.

4. Can you trust it? Check the three properties against your tenant.

   • Recorded with the change: Audit events commit in the same operation as the change, so a refused change leaves a rejected record, as step 1's sign-in did.

   • Protected from the people it describes: look for an edit or delete control on any Audit record. There is none, for you or for Ben.

   • Kept for a defined period: open Collection and retention in Audit. Records are kept for 30 days.

Then turn on Include routine access and find your own Audit reads from this lab, recorded as tenant.directory.audit.list (Directory audit viewed).

Why it matters: this is "Evidence you can trust". Reading the evidence is itself recorded, and a 30-day period is shorter than most audits look back, which is why G41 matters.

5. Attribution. Find an action by a shared or service actor: Front Desk's sign-in from the orphaned accounts lab, if it is still within retention, or any change by lab-provisioning. Each is attributed to an account with no named owner.

Why it matters: a record whose actor is a shared login or an unowned client attributes the action to nobody in particular.

6. Compute four measures.

   • Time to remove a leaver: for each leaver in this run, the scim.user.lock time minus the event's planned time in the run. Report the median and the longest.

   • Orphaned accounts over time: the count from filter=active eq true and not (externalId pr) now, against the starting count in reconciliation.json.

   • Review items that changed access: the share of items in review.json whose decision was remove or change.

   • Leavers still holding groups: locked simulated people whose groups list is not empty.

scim -G "$SCIM/Users" --data-urlencode 'filter=active eq false and externalId sw "HRSIM-"' --data-urlencode count=200 \
  --data-urlencode 'attributes=userName,groups' | jq '[.Resources[] | select((.groups // []) | length > 0)] | length'

Why it matters: this is "Measuring whether it works". The same records that answer single questions can be counted to show whether the process works in general.

7. When the numbers mislead. Create [email protected] in the portal, rerun the orphan count, then delete the account without investigating it and count again. The measure improves. Audit holds an unexplained tenant.users.delete with no reason, which shows why that improvement should not count. Next to each of your four measures, write the record that explains it.

Why it matters: completion and counts measure activity, not outcomes. Pairing each number with the evidence behind it shows which explanation is true.

Planned walkthrough

Once G23, G41 and G52 exist, the second audit request has a complete answer and the evidence outlives the default retention.

1. Ava's access request, both approvals, the grant and the read-back confirmation share one correlation ID, and searching it returns the whole decision trail.

2. Export the leaver evidence from step 1 as a signed, time-stamped file, or place the records on a legal hold, so they are still available after 30 days.

3. SCIM and portal changes accept a reason from a fixed list, so step 2's reason row is filled by the record itself.

4. Clients and shared accounts carry an owner, so step 5's actors lead to a person.

Break it

1. Try to answer step 1 from today's state alone. If the run has deleted the leaver, reading their ID returns 404 and Users no longer lists them; even if not, a locked account cannot say when it was locked or why. Only the records made at the time can answer.

Check your work

Press Check my progress. The checks look for, in order:

• tenant.hr.run succeeded (Setup step 3)

• scim.user.lock succeeded by lab-hr-feed (step 1)

• account.sign_in rejected with account_locked (step 1)

• tenant.directory.audit.list succeeded (step 4)

• tenant.users.delete succeeded (step 7)

Your one-page evidence pack has two answers, each line citing an Audit event ID or an HR correlation ID, with gaps marked, and four measures with the queries or files that produced them.

Cleanup

1. Let the lifecycle run finish.

2. This is the end of the Identity governance track. Delete any lab-tmp- users, groups, roles and clients you still have, and decide whether to keep the governance groups and the Help desk role. Audit keeps their history for 30 days.

Missing infrastructure

• G23: there are no request, approval or review records, so step 3 cannot be answered from the tenant, and decisions cannot share a correlation ID with the changes they authorized.

• G41: Audit and Logs cannot be exported or held beyond the 30-day retention, so evidence for an audit that looks back a year must be collected by hand as it happens.

• G52: SCIM and portal changes carry no reason, and clients and shared accounts have no owner, so some records attribute actions to nobody in particular.