User access management: an auditor's controls walkthrough

Auditor: Thanks for sitting down with me. I'm documenting the user access management process this year, so I'd like to walk it end to end and understand the controls as we go. Can we start with how someone first gets access? Walk me through a new joiner.

InfoSec: Sure. So when someone's hired, or they change roles, a request gets raised in our identity tool. It's tied to a defined role, so a lot of what we call birthright access, the baseline things everyone in that role needs, email, the network, the standard apps, that's provisioned automatically off the role. Anything beyond the baseline, the person or their manager requests specifically.

Auditor: And who approves it? I want to understand the approval control.

InfoSec: The manager approves every request. And for sensitive systems, or anything touching financial or customer data, the system owner or data owner has to approve as well. So there's a second set of eyes on the access that actually matters. For the routine baseline stuff, it's the manager. For privileged or sensitive access, it's manager plus owner.

Auditor: When you say it's approved, how is that evidenced? If I pull a sample, what would I see?

InfoSec: You'd see the ticket in the identity tool, with the approver, the timestamp, and what was approved. Every grant traces back to an approved request. We don't provision off an email or a hallway conversation. If it's not in the tool with an approval, it shouldn't exist, and that's exactly the kind of thing a review would catch.

Auditor: Good. So once it's approved, how does the access actually get granted?

InfoSec: Provisioning. Where we've got automated connectors between the identity tool and the target system, it's hands-off, the approval flows through and the access is granted directly. For systems we haven't integrated yet, and there are still some, it routes a task to IT to grant it manually. I'll be honest that the manual ones are where we have more risk, because there's a human in the loop who could fat-finger it or do it slightly differently than requested. Then the account gets set up with single sign-on and multi-factor enrollment.

Auditor: Let me ask about least privilege. How do you ensure someone only gets what they need, and how do you handle conflicting access?

InfoSec: Two things. Access is built around roles, so people get the role's standard entitlements rather than a pile of one-off grants, which keeps it close to least privilege. And we run segregation-of-duties rules that flag toxic combinations, the classic example being someone who can both create a vendor and approve a payment. If a request would create an SoD conflict, it gets blocked, and to proceed we need a documented mitigating control and a sign-off. We don't just wave it through.

Auditor: What about administrator accounts? Those are usually where I focus.

InfoSec: As you should. Privileged accounts are handled separately. They go into a privileged access management vault. So an admin doesn't just hold standing god-rights, they check the access out when they need it, often with approval, and the session is recorded. That way privileged use is deliberate and there's a trail.

Auditor: Now the part I find is usually weaker at most organizations. What happens when someone changes roles, and when someone leaves?

InfoSec: Yeah, and you're right to push there, because that's the hard part. On a role change, a mover, the new access gets granted, and the old access is supposed to be removed. I'll be candid that removal is where access creep happens, because adding access has an eager requester behind it and removing it doesn't. Someone moves from finance to operations and nobody's incentivized to claw back the finance access. We rely on the access reviews to catch that, which we'll get to.

Auditor: And terminations?

InfoSec: Terminations are triggered from HR. When HR processes a termination, it feeds our system and revocation kicks off across the connected systems within a defined SLA. For a normal departure that's same-day. For an involuntary termination, it's immediate, and security is looped in to cut access right at the moment so there's no window. Contractors and third parties run on the same idea, though honestly they're trickier because their end dates aren't always as clean in the HR system as an employee's.

Auditor: So the control depends on HR triggering it. What's the risk if HR is late or misses someone?

InfoSec: Then you get an orphaned account, access that's still live for someone who's gone. That's one of the things we specifically hunt for. Which brings us to the access reviews, which are really the backstop for everything we've talked about.

Auditor: Walk me through the review. Frequency, who does it, and what they actually do.

InfoSec: On a set cycle, quarterly for the sensitive systems, at least annually for the rest, we generate the list of who has access to what, and the managers and system owners recertify it. They confirm each person still needs their access, and they flag anything to be removed. Removals then get actioned. For privileged accounts we review more often, because the stakes are higher.

Auditor: Here's my concern with reviews generally. How do you know the reviewers are actually looking, and not just approving the whole list to clear it?

InfoSec: That's the honest weak point of any access review, and I won't pretend otherwise. The rubber-stamp risk is real. What we do to counter it: we track removal rates, because a reviewer who never removes anyone is a flag in itself. We require a real disposition on each line rather than one bulk approve. And we keep the completed reviews as evidence, with who reviewed, when, and what they changed. But ultimately a review is only as good as the person doing it, and that's a thing we manage rather than something we've fully solved.

Auditor: I appreciate the candor. What about emergency access, the break-glass situations?

InfoSec: We have break-glass accounts for genuine emergencies, when someone needs elevated access right now and the normal request path is too slow. Those are time-boxed, every use is logged, and critically, every use is reviewed after the fact to confirm it was legitimate. The control isn't preventing the emergency access, it's making sure it's rare, visible, and accounted for afterward.

Auditor: And from a monitoring standpoint, are these access events captured anywhere I could test?

InfoSec: Yes, access and authentication events feed our SIEM, and anomalies, like impossible travel or a burst of failed logins, generate alerts. So beyond the point-in-time reviews, there's continuous monitoring of how access is actually used.

Auditor: Last area. How does this all get reported, and what happens with the findings?

InfoSec: We report metrics up to security leadership and the risk committee, orphaned accounts, stale access, our revocation SLA performance, and review completion rates. And findings, whether they come from your audits or from our own reviews, drive remediation and feed back into the policy and the role design. So it's meant to be a loop, not a once-a-year scramble.

Auditor: That's really helpful for the documentation. Last question, and it's the one I always ask. From your seat, what do people most often get wrong about access management?

InfoSec: They over-focus on provisioning, on getting people in. That's the visible, satisfying part, and it's where the tooling and the attention usually go. But the real risk lives on the other side, in deprovisioning and in the reviews. Removing access when someone leaves or changes roles, and making the periodic review actually meaningful instead of a rubber stamp. That's where breaches and audit findings come from, the access that should have been gone and wasn't. Granting access is easy because someone's actively asking for it. Taking it away has no champion, so it quietly piles up. So if you're testing the design, that's where I'd point you, and frankly it's the part we work hardest to keep honest. A lot of the deprovisioning and review tracking is still pretty manual, so it's an area where better tooling would genuinely reduce risk.

Auditor: That's exactly what I needed. Thank you, this gives me a clear map of the process and the control points.

InfoSec: Glad it's useful. Happy to pull evidence samples for any of the steps when you get to testing.