Identity governance & access
Who gets access, when it changes, and when it is taken away, mapped so it is provable
For IT Business Analysis / Identity Governance roles
Identity governance across a portfolio of SOX-scoped applications. Access is granted, changed, and removed through a mix of manual and automated paths, and an auditor wants to see that it is controlled end to end. Here is how I model it so the answer is on paper.
Access is only as good as the record behind it
Every grant tied to an approved request. Every change re-checked for segregation of duties. Every departure closed the same day and swept a week later. And a recurring review that actually removes what is not needed, instead of rubber-stamping it.
- 3 eventsjoiner · mover · leaver
- 1 HR triggerthe system of record for every change
- Recurring reviewwith teeth: revoke means revoke
The approach
Current state, future state, requirements and control points, then the recurring access review.
- 01 Current stateHow access actually flows today: the manual paths, the automated ones, reconciliation, and the exceptions.
- 02 Future stateThe target joiner–mover–leaver flow: provisioning, role transfers, terminations, certifications.
- 03 Requirements & control pointsTurned into requirements, roles, handoffs, control points, and documented risk.
- 04 Access reviewsThe recurring certification: who reviews, what they see, and what a "revoke" actually triggers.
The future-state flow
Pick a lifecycle event to see the trigger, what happens, the control point, and how the loop gets closed.
- Trigger
- New hire record in the HR system, with a start date and a role
- Birthright access
- Provisioned automatically from the role: email, directory, core apps
- Role-based access
- Manager requests from a catalog; approval routed by sensitivity; SoD check before grant
- Control point
- No access without an approved request tied to an active HR record
- Close the loop
- First access certification at 30 days confirms only what was intended is live
- Trigger
- Role, department, or manager change in the HR system
- What happens
- Old entitlements flagged for review; new birthright roles applied
- The decision
- Manager confirms what carries over; anything not confirmed is removed, not left
- Control point
- Segregation-of-duties re-checked against the new role before provisioning
- Close the loop
- Recertification triggered so the change is evidenced, not assumed
- Trigger
- Termination or last-day record in the HR system
- Same day
- Accounts disabled automatically; interactive access cut
- Then
- Entitlements revoked, shared-account credentials rotated, tokens invalidated
- Control point
- Security receives a confirmation; a 7-day sweep checks nothing lingers
- Close the loop
- Orphaned-account report to catch anything the automation missed
The access review, in practice
A certification is only worth running if it changes something. Four entitlements a reviewer would actually see, and the call on each.
- Entitlement
- Administrator on a business-reporting platform
- Signal
- Last used 90+ days ago; the role only needs read access
- Risk
- Standing elevated access with no active need
- Decision
- Revoke admin, grant read; note for the app owner
- Outcome
- Revoke
- Entitlement
- Standard access to two in-scope applications
- Signal
- Contract end date is set and still in the future; access is used weekly
- Risk
- Low. In scope, time-bound, and active
- Decision
- Keep; confirm the end date will auto-expire the access
- Outcome
- Keep
- Entitlement
- Approval authority on a system their team no longer uses
- Signal
- No approvals actioned in two review cycles; team moved under a different function
- Risk
- Orphaned authority; approvals could route to someone with no context
- Decision
- Revoke; reassign the approver role to the current owning manager
- Outcome
- Revoke
- Entitlement
- Broad read/write across several applications
- Signal
- No named owner; last credential rotation unknown
- Risk
- High. Powerful, unattributed, and unmonitored
- Decision
- Investigate: assign an owner, document the purpose, rotate and monitor before the next review
- Outcome
- Investigate
The result
A model where every access change has a trigger, an approval, a control point, and a record, plus a review that removes what is stale instead of confirming it. The kind of thing an auditor signs off in one pass.
A generic identity-governance scenario. The lifecycle flows, the control points, and the access-review decisions are how I actually model this work.
Open to a senior full-time role. Hiring brief →