IGA programmes rarely fail because of the product; they fail because identity data is poor, the scope is too wide for the first release, and the platform is switched on with more power than anyone is ready to govern. This playbook covers the rollout of an identity governance and administration (IGA) platform as a product class: the order of phases, the decisions in each, how security is built into the platform and its connectors from the start, how to test and roll back automated provisioning, and which metrics show progress. It is vendor-neutral and based on NIST SP 800-53, NIST CSF 2.0, CIS Controls v8.1 and NCSC identity and access management guidance. It is written for IGA programme leads, identity architects and the application and HR teams they depend on. For product selection, see the IGA Buyer's Guide; for the detailed per-application method, see the Entitlement Catalogue and Application Onboarding Guide.
Key takeaways
- Fix the identity data before automating it. Automated joiner, mover and leaver processing only reduces risk if the authoritative source is accurate and every account can be correlated to an identity.
- Start with visibility, then reviews, then automation. Read-only aggregation and a first certification give value early and expose data problems before the platform can write to anything.
- Leavers first, joiners second. Automated disablement removes the most risk for the least disruption; birthright provisioning needs role design and testing first.
- Build the platform as a privileged system. Least-privilege connector accounts, separated admin roles and independent logging are rollout tasks, not later hardening.
- Include non-human identities from the first wave. Service accounts and API clients need owners and reviews too; leaving them to a later phase leaves the riskiest accounts ungoverned.
Phases at a glance
The sequence below is our recommendation. Each phase has exit criteria; do not start write-back provisioning until the read-only phases have met theirs.
| Phase | Main work | Security built in | Exit criteria |
|---|---|---|---|
| 0. Mobilise | Sponsor, scope, policy, operating model, success metrics | Access policy approved (NCSC: who should access what, why and under what conditions) | Signed-off scope for release 1 and named application owners |
| 1. Identity foundation | Authoritative sources, identity attributes, correlation rules, identity types (employee, contractor, non-human) | Source feed authenticated; minimum attribute set | Every in-scope person and non-human identity has one record with a status and an owner |
| 2. Platform build | Environments, admin roles, connectors, agents, logging | Connectors read-only; admin roles split; logs to SIEM | Platform passes a security review before connecting production targets |
| 3. Visibility | Aggregate accounts and entitlements from wave 1 applications; correlate; catalogue | Orphan and privileged accounts flagged | Correlation rate and orphan count known for each application |
| 4. First certification | Manager and owner reviews for wave 1 applications | Reviewers cannot certify their own access | Campaign completed; revocations fulfilled and verified |
| 5. Lifecycle automation | Leaver disablement, then mover and joiner, then access requests | Write rights granted per connector only when needed | Leaver SLA met; birthright roles tested |
| 6. Scale | Further application waves, SoD policies, non-human identity reviews, analytics | SoD rules enforced at request time | Coverage targets met per wave |
Phase 0 and 1: scope and identity foundation
- Scope release 1 tightly: one authoritative source, the directory, and five to ten applications chosen for risk and connector readiness (our recommendation). Privileged and regulated applications come first.
- Name the authoritative source per identity type: HR for employees, a contractor or vendor management system for third parties, and an inventory or registration process for non-human identities. NCSC advises covering all user types, including contractors, volunteers and visitors. See the Identity Data Quality and Authoritative Sources Guide.
- Agree the correlation key: an immutable identifier that appears in the source and in target accounts. Where targets lack it, plan attribute-based correlation and a manual correlation task for the remainder.
- Define lifecycle events: which source changes count as joiner, mover, leaver, leave of absence and rehire, with effective dates. See the Identity Lifecycle Event Design Guide.
- Non-human identities: register service accounts and API clients as identities with an owner, purpose and review cycle (CIS safeguard 5.5). See NHI lifecycle automation.
Phase 2: build the platform securely
The IGA platform will be able to create and change access across the organisation, so it is built as a privileged system from the first environment. Full detail is in Securing the identity governance and administration (IGA) platform itself; the rollout tasks are:
- Separate environments: development and test connect only to test targets, with masked identity data.
- Split admin roles: platform configuration, connector management, workflow development, help desk and audit, with dedicated admin accounts and phishing-resistant MFA (CIS safeguards 5.4 and 6.5).
- Read-only connectors first: create each connector service account with read rights only. Add write rights per operation in phase 5, scoped to the containers or groups being governed.
- Vault connector credentials: store them in the PAM vault or secrets manager where the platform supports it and rotate on a schedule.
- Configuration as code: rules, workflows and connector configuration in version control with peer review (NIST SP 800-53 CM-3).
- Logging from day one: admin, connector, workflow, provisioning and certification events to the SIEM.
Phase 3 and 4: visibility and the first certification
Aggregation of wave 1 applications usually reveals orphaned accounts, shared accounts and entitlements nobody can describe. Treat these as findings, not blockers.
- Correlate and classify: link each account to an identity, mark service and shared accounts, flag privileged entitlements, and record entitlement descriptions in business language.
- Handle orphans: disable uncorrelated accounts after owner confirmation rather than deleting them; see Orphaned and Dormant Accounts.
- Run a focused first campaign: privileged entitlements and wave 1 applications only, reviewed by managers and application owners. NIST SP 800-53 AC-6(7) calls for review of user privileges; a narrow first campaign avoids rubber-stamping. See the Access Reviews Guide.
- Close the loop: revocations from the campaign are fulfilled (manually if write-back is not yet live) and verified at the next aggregation.
Phase 5: lifecycle automation, with testing and rollback
Automation should arrive in order of risk reduction against disruption.
| Automation | Risk removed | Disruption risk | Prerequisite |
|---|---|---|---|
| Leaver disablement | Access after departure (PS-4, AC-2(3)) | Wrong person disabled on bad source data | Reliable termination dates; correlation verified |
| Mover access removal | Access accumulation (PS-5) | Users lose access they still need during handover | Grace period agreed; manager confirmation |
| Joiner birthright provisioning | Manual errors and over-provisioning | Wrong roles granted by attribute mistakes | Birthright roles designed and tested; see Role Mining and Role Design Guide |
| Access requests with approval | Untracked ad hoc grants | Approval delays | Catalogue with descriptions; approvers named |
| Preventive SoD checks | Toxic combinations (AC-5) | False positives blocking work | SoD ruleset agreed; see the Segregation of Duties Guide |
How to test and roll back automated provisioning
- Simulate: run lifecycle rules in preview or report-only mode against production data and compare the planned actions with what HR and application owners expect.
- Pilot ring: enable write-back for one application and one population (for example leavers in one business unit) before widening.
- Thresholds: configure or script a circuit breaker that pauses provisioning if a run would disable or change more than a set number of accounts (our recommendation: a small percentage of the population, set per application). A bad source file should stop at the threshold, not disable the company.
- Disable rather than delete: leaver actions disable first and delete after a retention period, so a mistaken leaver can be restored.
- Rollback: keep the previous connector and rule versions in version control, revert them, and re-enable affected accounts from the provisioning audit trail.
Decision guidance
- Software as a service or self-hosted: service platforms move patching and availability to the provider; self-hosted platforms give control over data location and network placement at the cost of operating a privileged system yourself. Either way, connectors, agents and configuration are customer responsibilities.
- Direct connectors or ticket fulfilment: connect high-risk and high-volume applications directly; use manual fulfilment tasks with verification for low-volume or disconnected applications.
- Roles or direct entitlements: start with a small set of birthright roles and direct entitlement requests; build business roles once usage data exists. The OWASP Authorization Cheat Sheet notes that role-based models become hard to manage as roles multiply, so keep the role count small and add attribute conditions where needed. Over-engineered roles before go-live are a common cause of delay.
- Small versus large organisations: smaller organisations may get most of the value from leaver automation and quarterly reviews in the identity provider; large or regulated organisations need the full IGA scope, with a programme office and application owner accountability.
Detection and measurement
Monitor provisioning runs for unusual volumes, connector errors, manual overrides and access granted outside requests. Report these metrics per wave:
| Metric | How to measure | Target (our recommendation) |
|---|---|---|
| Application coverage | In-scope applications aggregated, by risk tier | All high-risk applications by end of release 2 |
| Correlation rate | Accounts linked to an identity, per application | 98% or more, remainder owned exceptions |
| Leaver timeliness | Time from termination effective date to disablement in connected systems | Same business day for connected systems |
| Certification quality | Revocation rate and share of decisions made in bulk | Watch for zero revocations and bulk approvals |
| SoD violations | Open violations without an approved mitigating control | Falling each quarter |
| Non-human identity ownership | Service accounts and API clients with a current owner | Rising to 100% of in-scope accounts |
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Identity foundation and inventory | IA-4 Identifier Management, AC-2 Account Management | PR.AA-01 | 5.1, 5.5, 5.6 |
| Lifecycle automation | AC-2(1) Automated System Account Management, PS-4 Personnel Termination, PS-5 Personnel Transfer | PR.AA-01 | 6.1, 6.2 |
| Dormant and orphan accounts | AC-2(3) Disable Accounts | PR.AA-01 | 5.3 |
| Certification | AC-6(7) Review of User Privileges | PR.AA-05 | 6.8 |
| Separation of duties | AC-5 Separation of Duties | PR.AA-05 | 6.8 |
| Platform logging | AU-9 Protection of Audit Information, AC-2(4) Automated Audit Actions | PR.PS-04 | 8.2 |
Common failure patterns
- Automating dirty data: joiner and leaver rules run against an HR feed with missing termination dates or duplicate records.
- Boiling the ocean: release 1 tries to onboard hundreds of applications and delivers none in a year.
- Write rights from the start: connectors created with full administration during implementation and never reduced.
- Rubber-stamp campaigns: the first certification covers everything, reviewers approve in bulk, and auditors stop trusting the results.
- No circuit breaker: a malformed source file triggers mass disablement.
- Humans only: service accounts and API clients are left out of scope and stay ownerless.
Practitioner checklist
- Approve an access policy and a narrow release 1 scope with named application owners.
- Name the authoritative source and correlation key for each identity type, including non-human identities.
- Build connectors read-only first and add write rights per operation.
- Split platform admin roles and log platform events to the SIEM from day one.
- Run a focused privileged-access certification before enabling automation.
- Automate leavers first, with disable-before-delete and a volume circuit breaker.
- Test lifecycle rules in report-only mode and a pilot ring before widening.
- Report coverage, correlation, leaver timeliness and certification quality per wave.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NCSC: 10 Steps to Cyber Security, identity and access management
- NCSC: Secure system administration, use privileged access management
- CIS: Controls v8.1 Assessment Specification, Control 5 Account Management
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- CIS: Controls v8.1 Assessment Specification, Control 8 Audit Log Management
- OWASP: Authorization Cheat Sheet
Related NHI Mgmt Group resources: IAM and IGA Basics · Joiner-Mover-Leaver Guide · Identity Governance for AI Agents Guide · Identity governance and administration (IGA) platform health check · IGA RFP Template