Most organisations that have modernised their identity platform in the last few years reach the same moment. Single sign-on works. Multi-factor authentication is everywhere. Joiners get an account on day one. And then an auditor, a regulator or a board asks a question the platform cannot answer: who has access to what, why do they have it, and who approved it?
That question is what identity governance and administration exists to answer. IGA is the part of an identity program that gets talked about least and funded last, and it is usually the part that decides whether the whole thing holds up under scrutiny. This is the plain-English version: what IGA is, how it differs from the access management most organisations already have, and how to approach it without buying a platform you are not ready to run.
What IGA actually is
Access management is about the front door. It decides whether the person signing in is who they say they are, and lets them through to the applications they are entitled to. Identity governance is about the building behind the door. It keeps the record of who is entitled to what, makes sure those entitlements are granted and removed through a defined process, and can prove all of it when asked.
In practice, IGA covers a handful of capabilities that tend to arrive together:
- Lifecycle management. Access that follows a person through joining, changing roles and leaving, driven by an authoritative source such as HR or a student system rather than by tickets and memory.
- Access requests and approvals. A defined way for someone to ask for access, for the right person to approve it, and for the decision to be recorded.
- Access certification. Periodic reviews where managers or application owners confirm that the people with access to a system still need it, and revoke it when they do not.
- Role and policy management. Bundling entitlements into roles so that access is granted by what someone does rather than one permission at a time, with rules for combinations that should never coexist.
- Segregation of duties. Controls that stop one person holding two permissions that together create risk, such as raising and approving a payment.
- Audit and reporting. The ability to show, for any person or any system, the current access, its history and its justification.
None of these is exotic. What makes IGA hard is that each one depends on data the organisation has often never collected: an accurate list of applications, a clear owner for each, a definition of the roles people actually perform, and a source of truth for who is a staff member, a contractor, a student or an affiliate on any given day.
Why it comes after access management, and why that is right
There is a reason the modern identity platform goes in first and governance follows. Governance depends on lifecycle data being right. If the platform does not yet know reliably when someone joins, changes role or leaves, an access review will certify stale information and an automated revocation will remove the wrong access. Sequencing governance after lifecycle is not a delay. It is the only order that works.
That is the order one leading Australian university is following now. The modern platform went in first, with adaptive MFA extended to every cohort across an environment supporting more than 450,000 identities. Identity governance was scoped alongside the later phases and deliberately sequenced after lifecycle automation, because the team knew certifications and approvals would only be as good as the lifecycle data beneath them. The identity lifecycle has since been documented across every population, which is the foundation governance will be built on. We have written up the full case study.
The mistake is not the sequence. It is treating governance as an optional phase that can be deferred indefinitely. An organisation that stops at single sign-on and MFA has secured the front door and left the building unmanaged. Access accumulates. People change roles and keep what they had. Leavers linger in systems the identity platform does not control. The first serious audit, cyber insurance renewal or regulatory review finds it, and the remediation is done under pressure.
The questions IGA answers, and who is asking them
The pressure to answer these questions is arriving from several directions at once, and it is worth knowing which apply to you.
Regulators. Organisations captured by Australia's critical infrastructure regime need to demonstrate controls over who can access critical systems, and identity governance is where that evidence comes from. We have written a plain-English summary of SOCI Act obligations for executives working out whether the regime applies to them.
Auditors. Financial and IT audits routinely test user access reviews, leaver processes and segregation of duties. Without governance tooling, those tests are answered with spreadsheets assembled in the week before the audit, which is expensive and rarely convincing.
Insurers. Cyber insurance questionnaires increasingly ask not only whether MFA is enforced but whether privileged access is reviewed and whether leavers are removed within a defined window. Governance is how those answers become yes.
Boards. Directors are asking a simpler question: if someone in this organisation misused their access, would we know, and could we show we had done what a reasonable organisation would do? That is a governance question, and it cannot be answered from an authentication log.
Where organisations actually struggle
The technology is rarely the problem. The platforms that do this well are mature. The difficulty is almost always in the organisation, in three predictable places.
Nobody owns the applications. Governance needs an owner for every system who can say who should have access and approve reviews. In most organisations that list does not exist, or it names people who left years ago. Building it is unglamorous discovery work, and it has to happen first.
Roles have never been defined. Role-based access sounds simple until you try to write down what a finance officer, a lecturer or a shift supervisor should be able to reach. The work of defining roles is a business exercise, not a technical one, and it takes managers' time that the project plan rarely budgets for.
Processes live in people's heads. How a contractor gets access, what happens when a student becomes staff, who can approve access to the research system: these are usually known by a few long-serving people and written down nowhere. Governance tooling cannot automate a process nobody has described. Documenting the lifecycle, across every population, is the foundation, and it is the step most often skipped.
A sensible sequence
For organisations that have a modern identity platform in place and are looking at governance next, the order that works is consistent.
Document the lifecycle first. How each type of person is created, changed and retired, what triggers each event, and what should happen downstream. Do this before selecting or configuring anything.
Find the application owners. Build the inventory of systems that matter, name an owner for each, and confirm what access they hold. This is the same discovery that makes application migration plannable, and the two efforts should share it.
Automate the lifecycle. Connect the authoritative source, so that joiners, movers and leavers drive access automatically. Get this right before layering requests, approvals and certifications on top, because every governance control assumes the lifecycle data underneath it is true.
Then govern. Introduce access requests, certifications and segregation of duties in the systems where the risk is highest, prove the process, and extend it. Privileged access, identity threat protection and Zero Trust controls build on this foundation rather than sitting beside it.
Plan the handover. Governance is an operating capability, not a project deliverable. Decide early who will run certifications, maintain roles and handle exceptions once the program ends, and build their capability alongside the tooling.
What good looks like
An organisation with working identity governance can answer the auditor's question in minutes rather than weeks. Access reviews happen on a schedule, owners confirm or revoke with a click, and the record is kept. Leavers lose access everywhere on the day they leave, including in systems the identity platform does not directly control. A role change drops old access as new access lands. And when the board asks whether the organisation would know if access were misused, the answer is a report, not a shrug.
Move FWD provides identity and access management consulting for government, higher education and enterprise, and identity governance is where much of our current work sits: documenting lifecycles, finding application owners, sequencing governance after lifecycle automation, and staying to deliver it. If your identity platform is in and governance is the next question, talk to us.