The organizations most confident they don’t need formal IT governance are often the ones carrying the most risk. Not because they’re careless — usually the opposite. They’ve invested in an identity provider, configured SSO for their main applications, and put MFA in place. From where they sit, access looks controlled. What they can’t see is everything that exists outside that picture. The applications employees are using that never went through SSO onboarding. The accounts for people who left six months ago that nobody removed because the offboarding checklist only covered the formally integrated tools. The finance manager who, across three role changes, has accumulated permissions that no single role was supposed to have. These aren’t edge cases. They’re the predictable outcome of governance that stops at the SSO perimeter — and the perimeter covers much less than most organizations assume.

What Is the Actual Scope of the Problem? The gap between what organizations think they’re governing and what they’re actually governing is measurable. Estimates for the share of enterprise applications operating outside formal IT oversight consistently run above 60%. That means the majority of the application estate in a typical enterprise — the tools employees are actively using, the data those tools are processing, the access those tools have to company systems — exists outside the visibility of the identity platform the organization believes is providing governance. This isn’t primarily a technology failure. It’s a structural one. SSO platforms like Okta and Entra ID are excellent at governing the applications that have been formally connected to them. They were never designed to discover and govern the applications that weren’t. When employees adopt tools independently — a department buys a SaaS subscription, someone signs up for an AI tool with their work email, a vendor provides portal access with basic authentication — those tools simply don’t appear in the SSO dashboard. You cannot govern what you cannot see. And if you can’t see it, you don’t know it exists until an auditor finds it, or a breach involves it, or a departing employee’s access to it never gets revoked.

What Are the Specific Risks of Governance-Lite Environments? Orphaned Accounts An orphaned account is an active application account linked to a user who no longer works at the organization. They’re one of the most consistent audit findings in enterprise environments, and they exist for a simple reason: offboarding processes that work through the SSO layer reach only the applications connected to SSO. Everything else requires manual notification to application owners, and manual processes reliably produce gaps. The security risk is straightforward: a former employee’s active credentials in an application represent an access vector with no legitimate owner, no one monitoring it, and no business reason for it to exist. The compliance risk is equally clear: evidence of inadequate offboarding controls is a finding that repeats until the process changes. Access Creep and Overprivilege As employees move through roles over their tenure, access accumulates. The permissions granted for a project don’t get removed when the project ends. The elevated access granted during a temporary coverage period stays in place permanently. The entitlements appropriate for a previous role persist through a role change because the mover workflow only provisions new access without reviewing old access. Over time, users end up with a permission set that reflects their entire access history rather than their current role. This is access creep, and it violates the principle of least privilege — the security principle that users should have only the minimum access necessary for their current responsibilities — in ways that are invisible without continuous monitoring. Segregation of Duties Violations Segregation of duties (SoD) violations occur when a single user holds a combination of permissions that creates an internal control risk. The classic example is a user who can both create and approve a financial transaction — a combination that removes the check-and-balance the approval step was designed to provide. These violations don’t typically happen through deliberate policy decisions. They accumulate the same way access creep does: a permission is granted for a legitimate reason, a role changes, and nobody reviews whether the combined permission set now creates a conflict. Without governance tooling that specifically detects toxic permission combinations, SoD violations persist indefinitely and typically surface first during audits or incident investigations.

What Does Proper IT Governance Actually Require? A Single Source of Truth Governance decisions are only as reliable as the data they’re based on. The foundation of a functional governance framework is an authoritative system that knows who your employees are, what their current role is, and whether they’re still with the organization. In practice, this means integrating your HRMS — Workday, BambooHR, HiBob, or similar — with your identity infrastructure so that employee attributes flow automatically into governance decisions. A new hire in the HRMS triggers onboarding. A role change triggers access adjustment. An exit date triggers offboarding. When this integration is in place, identity decisions are driven by organizational reality. When it isn’t, they’re driven by whoever remembered to update the ticket. Discovery Beyond the SSO Perimeter Governing the full application estate requires knowing what the full application estate is. That means pulling signals from sources that surface what SSO logs don’t: browser agents that track application launches and URL access patterns, financial and expense data that identifies subscriptions purchased outside IT oversight, direct API integrations with connected platforms, and HRMS data that correlates user attributes with application access patterns. The output is a unified view of which applications exist in the environment, who is using them, whether that usage is formally sanctioned, and what risk the application carries. This is the starting point for governance decisions — and it’s meaningfully different from the application list that most organizations are working from. Automated Lifecycle Management The Joiner-Mover-Leaver framework is the operational structure through which governance acts on the identity lifecycle. Joiners get birthright access — the standard set of entitlements appropriate for their role — provisioned automatically on day one. Movers get their access adjusted automatically when their role changes, with old entitlements reviewed and removed rather than simply accumulated. Leavers have all access revoked automatically across the full application estate — including the applications outside SSO — at their exit date. The difference between organizations that have orphaned accounts and access creep and those that don’t is almost always whether the Mover and Leaver phases are automated or manual. Manual processes that depend on someone remembering to act produce gaps. Automated processes that trigger from HRMS events produce audit trails. Continuous Posture Assessment Periodic access reviews are necessary but not sufficient. A quarterly review cycle means that problems can exist for up to three months before anyone discovers them. Continuous posture assessment — monitoring the environment in real time for excessive access, flagging entitlements that haven’t been used in 30 or more days, identifying permission combinations that create SoD violations, and surfacing accounts that exist in applications for users who are no longer active — compresses the window between a problem emerging and someone being aware of it. For organizations under compliance frameworks that require timely identification and remediation of access risks, the difference between quarterly reviews and continuous monitoring is the difference between a finding and a control.

What Does IT Governance Deliver Beyond Compliance? Governance is often framed as a compliance requirement — something organizations do because auditors require it. That framing undersells the operational and financial value that governance provides alongside the compliance benefit. Operational Efficiency Access request processes that route through Slack integrations with structured approval workflows and automated provisioning handle requests significantly faster than ticket-based processes that route through IT queues. Organizations that have made this shift report handling access requests up to eight times faster — not because IT got faster, but because the manual steps in the process were eliminated. At scale, that efficiency compounds across hundreds of requests per week. License Cost Recovery Governance surfaces dormant licenses — applications being paid for that employees aren’t actively using — and redundant tools — multiple applications serving the same function that were purchased by different departments independently. Both represent recoverable cost. In larger organizations, the license savings from a governance program can offset its cost within the first year. Reduced Breach Impact The blast radius of a credential compromise is a function of how much access that credential has. Overprivileged accounts, when compromised, give attackers access to everything those accounts can reach. Accounts that comply with least privilege give attackers access to only what that user legitimately needs. Governance that enforces least privilege doesn’t prevent breaches, but it limits their scope — and in breach scenarios, scope is what determines impact.

The Organizations Most at Risk Are the Ones That Feel Most Secure There’s a specific pattern that shows up in organizations that later discover significant governance gaps: they invested in SSO and MFA, believed those investments meant their access was controlled, and stopped looking at what existed outside the perimeter those investments defined. The investment was real and the security it provided was real. The gap was that SSO and MFA govern authentication. They don’t govern the applications that aren’t connected to them, the access that accumulates across role changes, or the accounts that persist after people leave. Governance isn’t a different name for authentication. It’s the layer that sits above authentication and asks the question authentication doesn’t ask: not “is this user who they say they are?” but “should this user have this access, and does the access they have reflect what they actually need?” Those are different questions. And the organizations that have only answered the first one are governing less than they think.