Least Privilege Begins With Business Functions, Not Groups
Identity systems are excellent sources of evidence. They can show users, groups, role assignments, applications, authentication events, devices, and administrative privileges. That visibility is essential, but it does not contain the complete rule set needed to decide whether access is appropriate.
A group records an assignment. Least privilege requires a reason.
The target model is more granular than a department
"This employee belongs to Finance" is not enough. The person occupies a position, reports through a management hierarchy, and may perform several business functions at different allocation percentages. Each allocation can require different systems, privileges, data, locations, hours, approval paths, and separation-of-duties constraints.
The required access for treasury, accounts payable, financial reporting, payroll accounting, procurement analysis, and audit support should not be inferred from one broad department group.
Business systems and identity systems answer different questions
Okta or Microsoft Entra ID may be authoritative for accounts, groups, and sign-in state. A workforce, ERP, procurement, or finance system may provide position, manager, cost center, subsidiary, vendor, role, or budget context. Host and application evidence shows what the account can actually reach and do.
Reconciliation is the work. If sources disagree on manager, department, employment status, device, system role, or owner, the difference should become a finding for an accountable reviewer.
Function allocation makes access explainable
A defensible access statement connects the person to the position, the position to one or more approved functions, and each function to required systems, permissions, data flows, and control obligations. It also carries evidence of who approved the relationship and when it must be reviewed.
This structure supports people who legitimately wear several hats without granting an entire department's access. It also shows where one person performs conflicting duties because the organization lacks sufficient headcount.
Nonhuman identities need the same discipline
Service accounts, integration identities, scheduled jobs, managed identities, and emergency accounts do not occupy employee positions, but they still support business functions. Record the business purpose, technical owner, privileges, credential custodian, source and destination systems, allowed communication path, rotation rule, monitoring, and retirement trigger.
An account with no responsible owner or approved function is not automatically malicious, but it is unresolved risk.
Review the difference between actual and required access
The access review should compare observed entitlements and use with the owner-approved role model. Excess, missing, inherited, dormant, conflicting, or unexplained access becomes a remediation item. Closure requires new evidence, not only a ticket status.
After acceptance, sign-in patterns, privilege changes, new devices, new network origins, and role-function mismatches can be monitored as variations from the approved model. The objective is not to freeze the environment. It is to make change visible and accountable.
See how the platform connects identity and business context or request a guided assessment.