The gap most Identity Security programmes never close
Most organisations that have invested in an IGA platform can demonstrate that the programme exists. What is harder to demonstrate is that the governance above the platform exists too. These six questions surface whether yours does.
Most identity programmes are governed at the level of the platform and the delivery team. There is an identity programme manager, a set of delivery workstreams, a product roadmap, and a relationship with the platform vendor. What is frequently absent is a governance structure above the programme that connects identity decisions to business risk, resolves conflicts between security requirements and operational need, and provides the escalation path that a programme of this complexity requires.
These questions address the structural governance problem that sits above all the technical ones. They are not measuring maturity against an abstract model. They are asking whether the conditions exist for your programme to reach genuine maturity rather than stalling at operational maintenance.
Who owns the Identity Programme strategy?
Not the platform roadmap. The programme strategy: the decision about which business risks identity governance is designed to address, how the programme prioritises between competing objectives, and how its success is defined in terms that the business recognises. If the honest answer is that strategy is set by the identity team in consultation with the platform vendor, the programme is technology-led rather than business-led. That is a governance gap with direct implications for how the programme is funded, prioritised, and sustained.
How are conflicts between security requirements and business access needs resolved?
Identity governance creates friction. Least privilege means people can’t always access what they want when they want it. Segregation of duties means some combinations of access are unavailable to individuals who believe they need them. Recertification creates work for managers who have other priorities. When these conflicts arise, who resolves them and against what framework? If the answer is that the identity team negotiates case by case without a defined decision framework, the programme is vulnerable to erosion through accumulated exceptions.
Is there a defined escalation path for access decisions that fall outside policy?
Every programme has edge cases that the policy does not cleanly address. Emergency access requests, business-critical exceptions to segregation of duties controls, access requirements for new business models that were not anticipated when the programme was designed. How these decisions are made and documented is a governance question. If they are made informally by the identity team without a defined escalation path and formal approval record, the programme has a governance gap that will be visible to an auditor.
How does the identity programme connect to your wider risk governance?
Specifically, does identity risk appear in your risk register as a set of quantified exposures with defined owners and remediation plans, or as a programme status update? The distinction matters because it determines whether identity risk is governed as a business risk or managed as a technology programme. Regulators and audit committees increasingly expect the former, and the gap between what most identity programmes report and what regulators are beginning to require is widening.
How is the programme funded beyond the initial implementation?
Most Identity Security programmes are funded around the platform. With on-premise deployments that means a capital project that closes at go-live. With SaaS it means a subscription that sits in operational expenditure from day one. Either way the budget tends to cover the platform and not the programme. What it rarely covers is the sustained investment that determines whether the organisation reaches genuine governance maturity: capability building, process improvement, governance design above the platform, access debt remediation, keeping pace with regulatory expectations.
Who will own this programme in three years?
Not who owns it now. Whether there is a succession plan, a capability development path, and an institutional knowledge management approach that means the programme does not depend on specific individuals who may not be in their current roles in three years. Identity programme continuity is a governance risk that most organisations have not formally assessed. The knowledge required to operate a mature Identity Security programme is specialised, accumulated over time, and genuinely difficult to replace quickly.
What these questions are telling you
The governance structure above the platform is what determines whether an identity programme reaches maturity or stalls at operational maintenance. Most programmes invest heavily in platform capability and underinvest in the governance structures that would allow the business to actually use that capability. Building those structures is slower and less visible than configuring workflows, but it is what distinguishes a sustained programme from a successful implementation.
The questions that were hardest to answer honestly are the ones that matter most. They are also the ones that are most difficult to address without external challenge, because the people closest to the programme have usually accommodated the gaps rather than escalated them.
If this has surfaced something worth addressing
We work with CISOs and identity programme leads in regulated financial services organisations across EMEA who have an Identity Security programme in place but have not yet reached the governance outcomes that justified the investment. Our starting point is a structured programme diagnostic: a fixed price, time-bounded engagement that produces a clear gap analysis and a prioritised remediation roadmap that can be taken directly to a board or audit committee.
If that is relevant to your current situation, get in touch directly.
There are no forms, no automated follow-up sequences, and no sales calls unless you want one.
