Warning signs include every rollout creating new role definitions, certification scopes, or connector approaches, plus repeated delays when local teams are asked to adopt the same control pattern. That usually means the organisation has not turned governance intent into reusable delivery standards.
When IGA becomes a project factory instead of a control fabric
The clearest sign is repetition without reuse. If each rollout needs fresh role logic, bespoke certification scopes, or one-off connector patterns, the programme is behaving like a series of custom deliveries rather than an operating model. That usually means the organisation has not standardised how identity governance decisions are designed, approved, and implemented.
A more mature iga programme reduces variance across business units and applications. It should absorb new use cases with a recognisable pattern for roles, entitlements, reviews, and onboarding or offboarding flows, even when the underlying systems differ. If every implementation starts from a blank sheet, the programme is carrying project work that should have been turned into governed standards.
That is why reusable IGA platform design matters: the platform may be the same, but the delivery model should stop forcing teams to rediscover the same governance decisions for every integration.
Signs the operating model is too bespoke
Watch for symptoms that show up in delivery friction as much as in policy gaps. A common pattern is that role engineering happens application by application, so the role catalogue never stabilises and each new rollout expands the role count instead of reusing existing structures. Another is that access reviews keep changing shape because each business unit insists on its own scope, reviewer list, or evidence format.
Connector work is another useful clue. If each source system or target application needs a unique integration pattern, the programme is not only building connections, it is building exceptions. That becomes especially visible when local teams cannot adopt the same control pattern without bespoke mapping, custom workflow steps, or manual data fixes.
Good governance programmes also expose whether policy can survive contact with delivery. The role mining and role design discipline is supposed to reduce role explosion, not create another round of bespoke role definitions every time a new system arrives.
When recertification is constantly redesigned for each team, it often signals that access governance has been treated as a project deliverable instead of a repeatable control. The access review and certification process should scale through common review logic, not depend on a new exception model for every population.
What changes when governance becomes reusable
Reusable IGA delivery means the organisation has explicit standards for the parts that should not be reinvented. That includes role naming and ownership, certification scope rules, connector patterns, entitlement naming, onboarding and offboarding triggers, and how exceptions are approved. Once those patterns exist, project teams spend less time designing governance mechanics and more time fitting applications into an existing model.
This shift also improves lifecycle control. Joiner-mover-leaver handling stops being a series of local fixes and becomes a common process for provisioning, deprovisioning, and access correction. A JML model only works at scale when role and entitlement handling are standardised enough that changes can flow through without bespoke exception handling.
Reusable standards also reduce governance debt. The more custom the delivery, the harder it becomes to answer basic questions such as who owns a role, why a connector behaves differently, or whether a review result can be compared across systems. Standardisation is what turns IGA from a recurring implementation effort into a control system that can be measured, audited, and improved.
That is the logic behind good IAM and IGA foundations: governance is only repeatable when the organisation separates policy intent from one-off project execution.
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 | Role, entitlement and certification reuse directly affect account governance. |
| AC-6 — Least Privilege | Custom role design often signals inconsistent privilege scoping and access decisions. | |
| IA-5 — Authenticator Management | IGA programmes often govern credentials and secrets lifecycle through repeatable processes. | |
| Recommendation — Standardise account lifecycle and review patterns so each rollout does not rebuild control logic. Use least-privilege rules to constrain bespoke access designs and reduce role sprawl. Apply lifecycle controls to credentials and remove one-off handling for each application. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Reusable access control policy is central when governance keeps becoming custom project work. |
| A.5.18 — Access rights | Repeated certification and role exceptions show weak standardisation of access-rights management. | |
| Recommendation — Define a common access control standard and enforce it across integrations and teams. Centralise access-rights rules so entitlement reviews follow the same operating pattern. | ||
| CIS Controls v8 | CIS-5 — Account Management | IGA customisation usually shows up in inconsistent account and entitlement lifecycle handling. |
| CIS-6 — Access Control Management | The question is about standardising governance controls rather than reinventing each implementation. | |
| Recommendation — Use a common account-management process to eliminate bespoke onboarding and offboarding patterns. Define reusable access-control standards for roles, approvals, and review scope. | ||
Practitioner Guidance
What to prioritise: Look first for places where the programme keeps rebuilding the same governance decision, especially role creation, certification scoping, and connector design. Those are the strongest indicators that the operating model is not reusable.
What to verify: Check whether new integrations can use an existing pattern without redesigning the control, and whether the same access review or role ownership rules can be applied across multiple applications. If they cannot, the issue is usually governance design, not just delivery capacity.
Common mistake: Teams often treat each new exception as a normal implementation challenge. In practice, repeated exceptions are evidence that the standard is missing or too vague to be operational.
Practitioner takeaway: An IGA programme is too dependent on custom project work when delivery teams are repeatedly manufacturing governance logic instead of applying a stable, reusable control model.
Related resources from NHI Mgmt Group
- What signs show that a PAM programme is too dependent on manual processes?
- What signs show that a return programme is too dependent on customer-facing claims?
- What signals show that a cloud native security programme is too dependent on scanning?
- What are the signs that PCI DSS compliance work is being left too late in a payments programme?