Who has access to your critical systems?
At first glance, that sounds like a question your team can answer in a few clicks. Pull a user list. Check group memberships. Export application entitlements or cloud roles. Done.
Except that only answers part of it. The real test starts with what comes next: Why does that person or account have access? Is it still needed? Who approved it? What risk does it create?
Most organizations already own a full stack of identity technology: directories, SSO, MFA, PAM, HR systems, ticketing tools, application-level controls. And yet, ask five simple questions about access, and the confident answers start to run out, especially once you look across SaaS applications, cloud platforms, privileged systems, contractors, and service accounts.
These five questions are simple to ask. Answering them consistently is a fair test of whether IAM is functioning as a real security program, or just a collection of tools that happen to sit next to each other.
Question 1: Who Has Access?
The first problem is basic visibility. And visibility is harder than it sounds.
A complete answer needs to account for employees, contractors and third parties, administrators, service accounts, API and automation identities, cloud roles, SaaS applications, and shared or emergency accounts. Each of those lives in a different system with its own permission model. A directory shows one slice. Cloud platforms, business applications, VPN and ZTNA tools, and privileged access systems each show another. All too often, these various security tools become siloed off from each other.
There's also an important distinction between knowing an identity exists and understanding everything it can reach. A user account is easy to find. What that account can actually access and do is a much harder question to answer with confidence.
A reliable identity inventory is the starting point, but the real goal is a connected view of identities, permissions, and access paths that bridges the disconnect between views that each tell part of the story.
Question 2: Why Do They Have It?
Knowing that access exists doesn't explain why it was granted in the first place.
Access accumulates for all kinds of reasons: someone changed roles, joined a temporary project, needed emergency access during an incident, supported a migration, inherited a group membership, or was simply given broad permissions to avoid holding up a project. In the moment, most of these reasons are perfectly legitimate.
The problem is what happens afterward. The context fades while the permission stays. The approval might live in a closed ticket, an email thread, a spreadsheet nobody opens anymore, or the memory of someone who left the company two years ago.
This is where identity data needs business context to mean anything. Role, department, application ownership, original justification, approval history, and expected duration are all factors that need to be considered in the provisioning process. Without that context, access is an entitlement with no explanation attached; and there’s no way to recognize when permissions are excessive.
Access without context is difficult to govern. A mature IAM program should make it possible to explain not just what access exists, but why.
Question 3: Is That Access Still Needed?
This is where identity sprawl quietly takes hold.
Access gets granted fast because there's an urgent business need behind it. Removing that same access almost never carries the same urgency.
The pattern shows up everywhere: an employee moves to a new department but keeps the old application access. A project wraps up and the elevated permissions stay behind. A contractor's account stays active long after the engagement ends. A service account outlives the integration it was built for. Temporary administrative rights become permanent simply because no one circled back.
None of this triggers an outage or a visible failure, which is exactly why it goes unnoticed. Access frequently fails to keep pace with how fast the business actually changes. That's why reviews need to be continuous and contextual, tied to real remediation rather than a checkbox exercise once a year.
The fact that access was appropriate once doesn't mean it's appropriate now.
Question 4: Who Approved It?
Access governance breaks down fastest when ownership is unclear.
IAM responsibility rarely sits with one team. It crosses IT, security, HR, application owners, compliance, and business managers. One team requests access, another approves it, another provisions it, and a fourth reviews it months later, if anyone reviews it at all.
The critical question is simple to ask and often hard to answer: who is ultimately accountable for deciding whether this person should have this access?
Getting there requires clear application and access owners, defined approval authority, documented exceptions, time limits on temporary access, and review processes that actually repeat on schedule. Security teams shouldn't be expected to make every business access decision on their own: the people who understand the role, the application, and the actual business need have to be part of that process too.
Access without clear ownership becomes difficult to challenge, review, or remove.
Question 5: What Risk Does It Create?
Not every access issue deserves the same amount of urgency.
A stale account with access to a low-risk internal tool is a very different problem than an unused privileged administrator account, a service account with broad cloud permissions, a contractor with access to sensitive data, an account with no MFA, a user holding conflicting roles, or standing privilege into a critical production environment.
Evaluating access well means looking at it in context: privilege level, account activity, the sensitivity of the system or data involved, MFA coverage, whether the access is exposed externally, business ownership, whether the account is shared, and how recently it was reviewed.
The goal isn't to inventory every identity for its own sake but to evaluate access based on context, so routine cleanup can be told apart from the exposures that actually matter.
The goal of IAM is not to eliminate every imperfection at once. It is to identify and address the access that creates the greatest risk.
What the Answers Reveal About Your IAM Program
Put the five questions back together, and they map to what a healthy IAM program actually needs to provide: visibility into identities and permissions, context for why access exists, lifecycle control that keeps permissions aligned with change, governance over approvals and ownership, and risk prioritization that focuses attention where it matters most.
No single product delivers all of that automatically. It takes connected tools, defined processes, clear ownership, and ongoing review working together.
The goal is not a perfect identity environment. The goal is an environment where access can be seen, explained, challenged, adjusted, and improved.
Conclusion: How Confidently Could You Answer?
Pick one critical application, one privileged system, or one sensitive data environment in your organization, and run it through the five questions: Who has access? Why? Is it still needed? Who approved it? What risk does it create?
The point isn't that every answer needs to be instant. The real question is whether your organization has the visibility, ownership, and processes in place to find reliable answers—and act on them—when it matters.
IAM maturity doesn't come from a one-time cleanup effort. It comes from building the discipline to keep answering these five questions, over and over, as your environment keeps changing.
Ready to See Where You Stand?
Not sure how clearly your organization can answer these questions? An [IAM visibility and risk assessment] can help identify where access risk, ownership gaps, and governance challenges are building across your environment. Talk to Atlantic Data Security about taking a closer look at your identity program.