Teams can tell by checking whether they can update policies, connectors, and workflows directly, and whether upgrades preserve those changes without rework. If administrative ownership disappears during normal change management, the platform may be configurable in name but not governable in practice.
What “preserving control” really means in an IGA platform
An IGA platform preserves control when governance changes remain owned by the customer, survive routine upgrades, and do not depend on hidden vendor intervention to keep working. The test is not whether the interface looks configurable, but whether the organisation can continue governing policies, connectors, workflows, and access rules without reimplementing them after every release.
That distinction matters because some products shift control into implementation services, proprietary templates, or upgrade-dependent customisations. In those cases, the team may still be operating the platform, but not truly governing it.
How to test control before and after upgrades
The most reliable test is practical: change a policy, modify a connector, or adjust an approval workflow, then confirm the change persists through a normal upgrade cycle. If the platform preserves those edits cleanly, the governance layer is under your control. If upgrades silently reset logic, disable connectors, or require brittle rework, the platform is constraining control rather than preserving it.
Teams should also look for whether administrative ownership stays visible. If the people who run access reviews, role models, and workflow rules cannot directly manage the objects that define them, the product has introduced a hidden dependency that will show up later as friction, delay, or vendor lock-in.
This is where the distinction between a managed service and a governable platform becomes operational. A team can tolerate vendor assistance, but it should not need vendor permission to execute ordinary lifecycle changes. For background on what strong governance should cover across lifecycle, roles, and controls, see IAM and IGA Basics and the IGA Buyer’s Guide.
What failure looks like in practice
Control is usually lost in predictable ways. Custom rules get trapped in vendor-specific code, connector changes require professional services, or upgrade packages replace local workflow logic with a newer model that does not match the organisation’s process. That is a governance failure even when the product still “works.”
Another common failure is role and entitlement drift. If the platform cannot preserve access-review logic, segregation-of-duties rules, or joiner-mover-leaver changes without manual cleanup, then control is only partial. Strong governance also depends on persistent lifecycle discipline, so teams should compare the platform’s behaviour against the Joiner-Mover-Leaver (JML) Guide and the Segregation of Duties (SoD) Guide where those controls are part of the scope.
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 | CM-3 — Configuration Change Control | IGA upgrade control depends on preserving governed configuration through change. |
| CM-6 — Configuration Settings | Preserved policy and workflow settings are the core test of retained control. | |
| Recommendation — Require controlled changes so governance logic survives upgrades without breaking ownership. Baseline and monitor key IGA settings to prevent vendor-driven drift. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | IGA platforms must retain customer-managed configuration through normal lifecycle changes. |
| A.8.32 — Change management | Upgrade testing and change control determine whether governance survives releases. | |
| Recommendation — Maintain controlled configuration states for policies, connectors, and workflows. Test upgrades against governed workflows before promoting them to production. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | IGA control preservation depends on stable, verifiable software configuration. |
| Recommendation — Standardize and verify platform settings so governance is not lost during updates. | ||
Practitioner Guidance
What to verify: Confirm that the platform exposes the real governance objects, not just a front-end abstraction. You should be able to identify who owns policies, connectors, workflows, and role logic, and prove that those objects can be exported, changed, and restored without rework after a standard upgrade.
Decision rule: If a change survives an upgrade only because a vendor or implementation partner reapplies it, treat that as loss of control. If the platform can preserve state, ownership, and auditability through routine release cycles, it is behaving like a governable system rather than a fragile service wrapper.
What good looks like: Governance changes are versioned, recoverable, and operationally owned by the customer team. Upgrades may require validation, but they do not force redesign of core controls, and the platform does not obscure where policy ends and product logic begins.
Practitioner takeaway: The real question is whether control survives change. If governance depends on bespoke reinvention after every upgrade, the platform is reducing administrative ownership even if it advertises configurability.