How We Helped a 12,000-User, SAMA-Regulated Bank Close 30+ Audit Findings by Rebuilding Identity Governance

The situation

Internal and external auditors had repeatedly cited the same gap: no reliable view of who had access to what across the bank's critical applications. Provisioning was largely manual, processes were fragmented, and every hiring, transfer, and termination consumed significant effort across IT and business teams. Multiple compliance observations named the lack of governance over critical applications, and the bank's identity security team faced that pressure every audit cycle.

The target was well defined: automated joiner, mover, leaver processes for all users, bank-specific access requests, systematic access reviews, and strong governance on an enterprise IGA platform. Four phases were planned. A foundational phase connected six key applications, with the rest governed as disconnected systems from the start; three further waves then automated roughly ten applications each, all inside a strictly on-premises infrastructure regulated by SAMA.

The auditors were not asking for a tool. They were asking for visibility and control.

The challenge

Five conditions created real delivery risk:

1. Regulatory pressure from SAMA and internal and external auditors for centralized identity governance and reporting.
2. No holistic view of users and access; manual, fragmented processes were the norm.
3. Identity data needed cleanup before any JML automation could work.
4. Frequently changing application owners and unclear entitlement ownership across 36 in-scope applications.
5. A tight budget, fixed delivery timelines, and a strictly on-premises environment.

The approach

Phasing was anchored on quick wins and risk reduction: critical applications first, then waves, each phase delivering something tangible, so the bank saw auditable results inside the foundational phase, not at the program's end.

The operating model

Delivery ran hybrid and deliberately lean: an IAM delivery manager primarily onsite to coordinate teams, manage requirements, and navigate the bank's approval culture; two senior IAM engineers remote on design and development; a project manager on planning, risk, and reporting. That small team, with about five core client stakeholders across identity security, HR, infrastructure, and operations plus application owners, carried the full application portfolio. Work ran Agile across the portfolio, each application in a strict waterfall sequence from analysis to deployment. Decisions were formally approved through official channels, matching the bank's governance culture instead of fighting it. Cadence was heavy: three standing meetings a week, a monthly review, and daily follow-ups.

Data and ownership first

Identity data in the bank's Oracle HR system, the single authoritative source, was reconciled before automation was switched on, yielding a clean identity inventory across employees, contractors, and functional users. Workshops with HR, security operations, internal audit, application owners, infrastructure, and UAT teams were used to clean up existing practices and settle ownership, not just gather requirements. Every application, role, and entitlement got a named, accountable owner, with the mapping maintained as owners rotated, so the program absorbed the bank's churning ownership instead of stalling on it.

The technical architecture call

SailPoint IdentityIQ was deployed fully on-premises in the bank's data center with a dedicated DR site, driven by strict security and data residency constraints; environments were segmented across DEV, SIT, UAT, PROD, and DR. Active Directory, Exchange, and multiple core banking systems were onboarded through direct connectors, or a bank-managed Web Services middleware where none existed. Application servers ran load-balanced and highly available; users authenticated via Active Directory pass-through, with platform administration authorized through well-defined administrator roles. HR events drove auditable, reviewable changes in every downstream system.

Workflow design

• Joiner. HR events automatically create identities with birthright entitlements per user category (employees, contractors, functional users) by job role, department, location, and employment type; executives, contractors, and other high-risk roles got dedicated patterns meeting security as well as operational requirements.
• Mover. Department and role changes strip all non-birthright access and reassign only what the new role warrants; anything further must be re-requested through the standard request process. Historical access cannot accumulate as people move, exactly the creep the auditors had flagged.
• Leaver. HR termination events immediately disable all accounts and revoke access across connected systems, sharply reducing the orphaned-account and post-employment exposure that had been a key finding. With Active Directory and Exchange disabled at once, interactive and directory-brokered access dies even for applications still on work items.
• Access requests. A standardized, bank-specific request process handles all access beyond birthright; request scenarios were validated in UAT alongside the JML flows.
• Downstream tasks. Fully integrated systems execute changes automatically; disconnected applications generate work items, with unaddressed tasks escalated to the owner's manager after five days: the backstop that kept leavers and movers on a controlled clock even as owners changed.
• Access reviews. Quarterly certification campaigns involve entitlement, business, and application owners, with decisions feeding automatic revocation or tracked follow-up actions; initial phases covered standard certifications across every in-scope application.
• Role model. A pragmatic mix of job-based roles, department-based roles, and application bundles, with strict naming conventions and entitlement-to-owner mapping to prevent role explosion.

Access creep is not a tooling problem. It is a design decision you make in the mover workflow.

Deployment and release

Rollout was application by application: each went to production as soon as it cleared design, SIT, UAT, and formal written approval, without waiting for the rest of its wave. Business users and application owners validated every key scenario type against real processes before sign-off: joiners, movers, leavers, requests, and reviews. HR-to-Active Directory automation was among the earliest production wins. Each release shipped with formal documentation and a structured handover, so the bank bought a capability, not a dependency.

The outcome

All 36 applications are in production under centralized governance for 12,000+ users, onboarded wave by wave into automated provisioning and handed over with ongoing support; applications awaiting their wave were governed through tracked, escalated work items until then. Identity operations moved from reactive and manual to a governed, automated model directly supporting regulatory compliance and operational efficiency. Each result below is measured against the pre-migration baseline of manual, ticket-driven operations:

• 70% reduction in onboarding time for new users: provisioning that had moved through fragmented manual handoffs across IT and business teams now executes automatically from the HR event, with clearer business accountability.
• 80% reduction in orphan and dormant accounts across the environment, closing the post-employment access paths auditors kept finding.
• 30+ internal and external audit findings closed, the same observations on identity visibility and governance of critical applications that had driven the program.
• 700+ manual tickets eliminated as provisioning moved to automation across the application waves, returning that effort to IT and business teams.
• 60% improvement in access review completion rates and certification timelines once quarterly campaigns ran on the named-owner model.

An audit finding is closed by the auditors who raised it, not by the vendor who fixed it.

Audit and security stakeholders now hold the centralized view of identities and access the compliance observations had demanded. The broader proof: a constrained, on-premises banking environment can still reach enterprise-grade identity governance when design, ownership, and data come first.

Designed to graduate

The review framework was built to grow: privileged-access and toxic-combination certifications are the staged next phase, running on the same ownership model and campaign machinery. Beneath it, the bank now holds a reconciled identity inventory, a curated entitlement catalog with named owners, and least-privilege principles embedded in the JML workflows and reviews: the working inputs a future privileged access management or policy-based access control program needs, with integration patterns ready for cloud when the bank is.

What we took from it

1. Clean the data and settle ownership first. JML automation fails without a reconciled identity source and named entitlement owners; that groundwork is the project.
2. Design around how the bank actually operates. Workshops with HR and application owners produced workflows that survived contact with reality; a generic IGA template would not have.
3. Get approvals in writing. Formal sign-off on process and design decisions is what prevents rework and scope creep in a governance-heavy institution.
4. Deliver quick wins early. HR-to-AD automation and early application onboarding built the trust that carried the longer phases.
5. Educate the application owners. Their understanding determines the quality of governance; the investment in workshops paid for itself in review quality.