Identity Governance Staffing Costs: How Many FTEs Should CIOs Budget

If you want a defensible estimate of IGA FTE requirements, start by separating central team effort from distributed business effort. Then convert both into hours, apply your finance-approved productive-hours assumption, and stress-test the model for audits, acquisitions, legacy systems, and review campaigns. That approach gives you a practical view of identity governance operating costs without pretending there is a universal users-per-FTE ratio.

Why identity governance staffing is not a users-per-FTE calculation

The short answer is that identity count alone does not determine staffing. Two organizations with the same number of identities can need very different teams depending on application complexity, entitlement quality, review cadence, compliance scope, and how much work is pushed to managers and application owners.

There is no independent public standard that says one correct IGA FTE count exists. What you do have are calibration points. A published heuristic suggests 1 to 2 dedicated IAM professionals below 2,000 identities, 3 to 6 for 2,000 to 10,000, 8 to 15 for 10,000 to 50,000, and 15 to 30 plus above 50,000, assuming a reasonably automated environment. A vendor-sponsored composite for Okta Identity Governance describes 5,000 identities supported by 10 core IAM FTEs plus 2 audit and compliance FTEs. Those numbers are useful only as anchors, because the operating model and control burden are different.

The CIO should treat those figures as signals, not targets. A smaller enterprise with legacy systems, custom connectors, weak ownership data, and frequent audits can consume more effort than a larger company with standardized SaaS and strong automation. That is why identity governance operating costs should be sized by workload, not by headcount folklore.

Which roles keep an IGA program running after go-live?

The answer is more than “the IAM team.” Central platform staff handle the technical and governance machinery, but distributed business owners still consume real operating capacity. If you do not model both, the budget will be incomplete.

Here is the practical role split:

Role or capacity	Ongoing responsibilities after go-live	Budget treatment
IGA platform owner / administrator	Configure catalogs, workflows, policies, campaigns, notifications, dashboards, and admin permissions; monitor health; investigate failures; coordinate releases.	Central IT, IAM, security engineering, or platform team.
Identity integration / application-onboarding engineer	Build or maintain connectors, mappings, validation, reconciliation, and testing when target systems change.	Central technical capacity, often under-budgeted.
Governance operations / certification coordinator	Define campaign scope, reminders, fallbacks, escalation, no-response behavior, and remediation tracking.	Central governance or security operations.
Policy, role, and SoD governance owner	Maintain RBAC and ABAC models, access templates, conflict rules, exceptions, and remediation policies.	Central security, risk, compliance, or IAM governance.
Audit and compliance liaison	Produce evidence, assemble reports, respond to sample requests, and support control testing.	Central compliance or security capacity.
Service desk / identity support	Handle access questions, routing, escalation, and identity-related incidents.	Existing service-desk capacity.
Application / source owner	Verify business purpose and entitlement meaning, approve or revoke access, keep owner data current.	Distributed business capacity.
Entitlement or role owner	Review roles and permissions, approve, revoke, delegate, or comment.	Distributed business or application capacity.
Manager / access reviewer	Certify direct reports’ access and respond to escalations.	Distributed manager time.
HR, ITSM, and authoritative-data owners	Maintain joiner, mover, leaver, employment, and termination data.	Shared operational capacity.
Executive sponsor / governance board	Resolve disputes, set risk appetite, and prioritize policy direction.	Fractional leadership time.

The hidden cost is often the distributed part. A certification campaign may be centrally automated, but it still consumes manager and application-owner time across the business. That work belongs in identity governance operating costs even if no new IAM requisition is opened.

How should CIOs calculate IGA FTE requirements?

Use an activity-based model. Do not start with a users-per-FTE shortcut and work backward. Start with the work the program actually performs, then divide by productive hours.

A clean formula looks like this:

Annual hours required =
joiner, mover, and leaver events × handling time

• access requests, approvals, denials, and escalations × handling time

• certification items, exceptions, reminders, and remediation × handling time

• applications onboarded × onboarding and testing time

• connector incidents and reconciliation defects × resolution time

• role, policy, and SoD changes × analysis and approval time

• audit cycles and evidence requests × preparation time

• identity-related service-desk tickets × handling time

• governance meetings, training, documentation, reporting, and peak-period allowance

Then:

FTE required = annual hours required ÷ finance-approved productive hours per FTE

That denominator matters. Do not silently use paid hours if your finance team uses productive hours. Vacation, holidays, training, meetings, leave, on-call time, and non-project work all need a consistent treatment.

For the first budget, collect at least 12 months of actual data for:

• active human, contractor, partner, privileged, service, machine, cloud-workload, and AI-agent identities

• joiner, mover, and leaver events

• access requests and approval decisions

• provisioning success, failure, retries, and manual interventions

• applications, sources, connectors, entitlement counts, roles, and custom integrations

• access-review campaigns, overdue items, denials, revocations, delegations, and exceptions

• SoD conflicts, violations, compensating controls, and remediations

• audit requests, evidence packages, and recurring reporting

• identity-related service-desk tickets and resolution time

• application changes, connector incidents, and data-quality defects

• loaded labor rates by role and geography

If you do not have that history, instrument the first review and onboarding cycles. Label modeled volumes as assumptions, not observations. That is the only reliable way to size IGA FTE requirements with any credibility.

How much effort do access reviews and application onboarding add?

A lot more than most budgets admit. Access reviews are not just a campaign launch. They create reviewer work, follow-up work, remediation work, and evidence work. Application onboarding is not a one-time catalog entry. It is an ongoing integration and maintenance process.

Modern review workflows can be automated, but the settings themselves drive workload. Recurring campaigns can run weekly, monthly, quarterly, or annually. They can include one or more stages, reminders, automatic result application, fallback reviewers, no-response behavior, and inactive-user thresholds. Each of those choices affects staffing. Short review windows create escalation work. Multi-stage reviews create coordination work. Auto-apply may reduce manual remediation, but it increases the need for policy testing, exception handling, and monitoring.

The human work is distributed. Managers review direct reports. Application owners review the systems they own. Entitlement owners inspect roles and permissions assigned to them. They may approve, revoke, delegate, reassign, comment, inspect history, and sign off. A central team still has to validate scope, chase overdue decisions, export evidence, and check remediation. That is why access reviews are one of the largest hidden pieces of identity governance operating costs.

Application onboarding may be straightforward when the connector is standard and the schema is clean. It becomes heavier when the environment includes custom APIs, mainframes, file-based interfaces, weak test environments, unclear entitlement descriptions, bidirectional provisioning, or no dependable owner. A public customer case described an enterprise with more than 15,000 employees and more than 250 applications moving from months of lead time to as little as a few hours for basic onboarding after shifting to a cloud-based service. That is a useful directional example, not a universal benchmark.

For planning, separate these lines in the model:

• standard-connector onboarding

• custom-connector onboarding

• target-system change maintenance

• failed-provisioning investigation

• entitlement cleanup

• access-review campaign operations

• reviewer and owner decision time

If you blend them together, your staffing estimate will be too vague to manage.

What do automation and modern IGA change in the cost model?

Automation shifts work, but it does not make operating responsibility disappear. The central team usually spends less time on repetitive transaction handling and more time on exceptions, ownership quality, policy tuning, and assurance.

That is why the best way to read automation studies is as capacity models, not promises of layoffs. One Forrester composite for Microsoft Entra Suite models 85,000 users, 12,000 employee onboardings a year, 25,000 ongoing user-access-management tasks, and 80,000 password-related help-desk tickets. It shows onboarding handling time dropping from 120 minutes to 30 minutes per employee and models a 90% reduction in password tickets. Another composite for Okta Identity Governance models 5,000 identities with 10 core IAM FTEs plus 2 audit and compliance FTEs, and it shows task savings improving over time. Those composites are useful because they show how volume and handling time translate into labor capacity. They are not universal staffing ratios. The right reading is simple: automation can return hours, reduce backlog, and sometimes avoid hiring. It does not guarantee headcount reduction.

This is also where a modern platform can change team design. Astranova Labs positions Citadel Identity360 as intuitive enough for the IT team to learn within two weeks of training. If that claim holds in your environment, it supports a simpler operating model with existing IT staff. But the CIO still needs named ownership for the platform, policy, integration, review operations, and audit response. Automation lowers friction. It does not remove accountability.

How should identity governance operating costs appear in TCO?

They should appear as fully loaded labor, not just platform headcount. That means you should capture salary, benefits, employer burden, internal charge rates, and the time consumed by people outside the IAM cost center.

For central labor, budget the platform administrator, integration engineer, governance coordinator, policy and SoD owner, and audit liaison. For distributed labor, include managers, application owners, entitlement owners, HR data owners, security approvers, and sponsor roles for service accounts, machine identities, cloud workloads, and AI agents.

You should also budget for peaks. Annual audits, certification campaigns, mergers, reorganizations, and major application waves create spikes that a monthly average hides. The budget should include explicit capacity for those events, not pretend they do not exist.

A simple way to present the model is:

1. Base run-rate central labor

2. Distributed reviewer and owner time

3. Audit and compliance effort

4. Service-desk identity work

5. Peak-period allowance

6. Implementation effort, kept separate from run-rate

That distinction matters. Connector discovery, data cleanup, role mining, entitlement rationalization, policy design, and initial campaign setup belong to implementation. Ongoing access reviews, evidence collection, remediation, and integration maintenance belong to run rate. If you mix them, your TCO model will blur transformation cost with operating cost.

A final point for CIOs: automation may reduce hours, but the business case should state whether those hours become avoided hiring, lower overtime, reduced contractor spend, fewer tickets, or simply reclaimed capacity for the same team. Those are not the same outcome.

Can an existing IT team run Citadel Identity360?

Yes, in the right operating model, and that is the point of a lighter governance footprint. Astranova Labs’ position is that Citadel Identity360 is intuitive enough for an existing IT team to learn within two weeks of training. If your environment is relatively simple and well integrated, it can remove the need to create a separate IAM team.

But “no separate IAM team” does not mean “no staffing.” You still need a platform owner, backup coverage, application owners, policy authority, reviewer accountability, and audit responsibility. You still need to measure review effort, connector work, exception volume, and service-desk load. The operating model just becomes more distributed and more embedded in the existing IT organization.

That is the most practical way to think about identity governance staffing. In a simpler environment, Citadel Identity360 may let existing IT staff absorb the work more efficiently. In a complex environment, it can reduce manual effort while still requiring dedicated central roles. Either way, the CIO budgets for accountability, not only for software.

FAQ

Is there a standard number of IGA FTEs per 1,000 users?

No. Identity count matters, but it is only one input. Applications, entitlements, review cadence, connector complexity, compliance scope, and data quality can change the answer substantially.

Do application owners and managers count as identity governance staffing?

Yes. Their time belongs in the operating-cost model even when they sit outside the IAM team. Count them as distributed reviewer and owner effort.

Can automation eliminate the need for a separate IAM team?

It can in a simpler, well-integrated environment, but it does not eliminate accountability. You still need named owners for platform, policy, review, audit, and backup coverage.

What should a CIO budget besides platform administrators?

Budget integration and onboarding capacity, certification operations, policy and SoD governance, audit support, service-desk work, reviewer time, data-quality remediation, and peak capacity for audits and application changes.

The right conclusion is not that identity governance needs a large dedicated department by default. The right conclusion is that every CIO needs a transparent model for central effort, distributed effort, and peak demand. Once you size those pieces honestly, the budget becomes easier to defend and easier to manage. If you are evaluating a platform, test it against your own application mix, review cadence, and labor rates, not someone else’s headcount myth.