Teams should plan IGA as an ongoing programme with continuing role maintenance, access rule updates, application onboarding, and exception handling. If maintenance is treated as aftercare, the model drifts, reviews lose relevance, and the platform becomes harder to operate. Budget and staffing must reflect steady-state governance.
How should teams budget for the ongoing work of IGA?
Identity governance succeeds when teams treat it like a living control plane, not a one-time deployment. The operating model has to absorb role cleanup, entitlement change, application onboarding, exception handling, and periodic review refreshes. The practical question is not whether IGA will need maintenance, but who owns it, how often it will change, and whether the programme is funded for steady state.
What actually creates the maintenance burden?
Most of the effort comes from keeping the model aligned to business change. Roles drift as organisations restructure, applications change their entitlement models, and reviewers need better context as access patterns evolve. New systems must be onboarded, existing integrations have to be tuned, and exceptions need expiry or re-approval so temporary workarounds do not become permanent governance debt.
That burden is structural, not accidental. IGA depends on current role definitions, current business ownership, and current access data. If any of those inputs age out, the platform starts producing noisy reviews and stale decisions. A well-run programme therefore treats maintenance as part of control design, including the work needed to keep access rules, owners, and certification populations accurate over time. Teams often find the upkeep easier to manage when they anchor the lifecycle in a disciplined IAM and IGA Basics model and then operationalise it through a clear Joiner-Mover-Leaver (JML) Guide.
How do programme design choices change the workload?
The biggest maintenance multiplier is complexity that was not priced into the original design. Too many roles, too many bespoke exceptions, and too many disconnected applications all increase the amount of manual review and remediation the team must absorb. Role engineering matters because a role model that is easy to explain is usually easier to maintain, and access review design matters because noisy campaigns consume time without improving control quality.
Practically, teams should expect maintenance to grow with the number of joiner, mover, leaver exceptions, the amount of non-standard access, and the degree of application variation. If the business depends on lots of one-off access grants, the programme needs stronger ownership and faster recertification, otherwise the catalogue becomes outdated faster than it can be governed. That is why a thoughtful role model and a disciplined review loop are not optional extras. They are the difference between a manageable operating rhythm and role explosion. The need for durable role design is covered well in the Role Mining and Role Design Guide, while ongoing certification hygiene is reinforced by the Access Reviews and Certification Guide.
What should teams plan for in the operating model?
Teams should budget for recurring human effort, not just software. Someone must own role governance, application onboarding, connector health, reviewer support, entitlement exceptions, and evidence retention. That ownership has to sit close enough to the business to resolve change quickly, but with enough authority to stop drift when control quality is slipping. Steady-state staffing should assume periodic surges when major applications, reorganisations, or audit cycles land at once.
What to verify: Confirm that the budget includes ongoing role curation, review administration, application integration maintenance, and exception expiry handling, not just the first deployment. Confirm also that ownership is explicit for role changes and access decisioning, because a shared-responsibility gap usually becomes a backlog gap.
What good looks like: The IGA team can show current role owners, current exception dates, current application coverage, and a predictable cadence for review and remediation. Reviewers see relevant context, and the platform does not rely on heroic manual cleanup to stay useful.
Practitioner takeaway: Size IGA like a governance service with a permanent change backlog, not like a project with a finish line; if the organisation will not staff for continual upkeep, the model will decay faster than it can deliver value.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | IGA maintenance depends on ongoing account and entitlement governance. |
| AC-6 — Least Privilege | Role drift and exception growth directly affect privilege minimisation. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | IGA operations need ongoing evidence that reviews and remediation are actually happening. | |
| Recommendation — Automate account and entitlement updates, then review residual exceptions on a fixed cadence. Continuously recertify access and remove privileges that no longer match current job need. Use audit reporting to verify review completion, exception closure, and backlog trends. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IGA maintenance is fundamentally about keeping access rules current and enforceable. |
| Recommendation — Maintain access rules and review outcomes as living controls, not one-time approvals. | ||
| CIS Controls v8 | CIS-5 — Account Management | Continuous account lifecycle work is the core maintenance burden in IGA. |
| Recommendation — Operationalise account lifecycle ownership and keep privileged exceptions short-lived. | ||