Access Provisioning Automation (IGA) for 1,000+ Employees

Why manual access management stops working

When a company has a few hundred employees, manual access provisioning often relies on personal agreements: an email to IT, approvals in a messenger, a note in Excel. But once the organization grows to 1,000+ people, that approach starts to fail almost daily. Requests increase, systems multiply, and the number of people who remember “how it should be done” does not.

The first things that break are speed and quality. Manual processes typically lead to:

• delayed access: a new hire waits or is given broad temporary rights
• mistakes: wrong profile, wrong role, access to the wrong environment
• accumulated excess rights “just in case,” because nobody has time to remove them
• lost approvals and decisions made "from memory"
• partial or delayed revocation on termination

Growing to 1,000+ employees increases pressure on IT and security not only because of volume. The environment becomes more complex: more applications, branches, user types (permanent, temporary, contractors). Specialists spend time on manual checks and messaging instead of focusing on risks.

The most painful problems show up at audits. Auditors need proof: who requested access, who approved it, on what basis, for what period, and when it was revoked. If the chain lives in emails and chats, it quickly becomes incomplete. Then even a correct access can look like a violation simply because there’s no evidence.

User lifecycle processes suffer the most, where accuracy and timing matter: onboarding (access on day one), transfers (remove old and assign new without overlap), termination (fast disable), and contractor access (clear owner and limited duration).

When the manual approach no longer suffices, organizations usually request IGA (Identity Governance and Administration): not for a "dashboard," but so rights are issued predictably, approvals are recorded, and excess access doesn’t persist for years.

What IGA is and the problems it solves

IGA is an approach and a class of systems that manage who should have access to what, on what basis, for how long, and who confirmed it. In short, IGA helps issue access by rules, record approvals and regularly check that rights remain appropriate.

Don’t confuse IGA with IAM and SSO. IAM typically handles sign‑in (accounts, authentication, password policies), SSO makes sign‑on more convenient (one login for many systems). IGA sits alongside them but solves a different problem: order in rights and auditability. Even with perfect SSO, employees can still hold extra roles in ERP, mail, file shares or dev services.

Core scenarios: joiner, mover, leaver

IGA is usually built around the employee lifecycle (JML). When a person joins, moves or leaves, access should change quickly and consistently for everyone.

Example: a new accountant starts. Based on HR data, IGA automatically creates the account, grants the baseline set of access (mail, ERP/1C, department folders), routes requests for sensitive modules for approval, and stores the history: who approved and when. On transfer the system removes old rights and adds new ones. On termination accounts are disabled and rights revoked by clear rules, without manual workarounds.

Roles, groups, policies and SoD in plain language

IGA relies on clear building blocks: roles (a set of rights for a job or function), groups (a technical way to grant rights in a specific system) and policies (rules about who may have what).

A separate topic is segregation of duties (SoD). This forbids risky combinations of rights. Simple example: one person should not both create a vendor and approve payments. Or create a user and grant themselves admin roles. IGA helps detect such conflicts and either block issuance or require additional approval.

What is an access review and why you need it

Access review (periodic access recertification) is a regular check to ensure employees still need the rights they have. Managers and system owners confirm or remove access, and the result is recorded for security and audit.

Without reviews, rights grow unchecked: people change roles but remain in old groups, temporary access granted "for a week" often lives on for years. Reviews bring back control and reduce the risk of leaks and misuse.

Typical expectations from IGA are simple: faster provisioning for new hires, fewer incidents from excess rights, greater transparency (who granted access and why), easier audits, and a single governed process instead of dozens of manual procedures.

SailPoint, Saviynt, One Identity: how to choose for your environment

Choosing an IGA platform rarely boils down to “which is best.” What matters is how well the product fits your environment: where accounts live, which systems are critical, how approvals work, and who will support it after rollout.

Start by describing the access “skeleton”: HR source (where employee data comes from), corporate directory (often Microsoft AD/Azure AD), mail, key business systems (e.g. SAP or Oracle), and applications where access is still manual. Then compare platforms on what you actually need to implement in the first 3–6 months.

What to look at first

Usually five criteria are enough:

• connectors and integrations: are there ready connectors to your systems and are your versions supported
• workflows and rules: can you model approvals without workarounds, and how easy is it to change them after go‑live
• deployment model: on‑prem, cloud or hybrid, and where data and logs will be stored
• implementation effort: how many engineers are needed and how much custom code is required
• reporting and audit: how quickly can you answer “who, when and why got access,” plus SoD control

Differences between SailPoint, Saviynt and One Identity often show not in headline features but in details: how the platform behaves in hybrid environments, how review campaigns are implemented, and how much effort is required for ongoing maintenance.

What to verify during the pilot

A pilot is not for a demo but to verify the solution on your data. Take one department (for example, 150–200 people) and 3–5 systems with the highest request volumes.

In the pilot, validate four things: how roles are created and changed, the request lifecycle from submission to provisioning (including exceptions), how reviews run, and what reports you can actually extract for audits (user rights, system rights, approval history).

Also discuss operations: who will administer the platform, which tasks remain with security and system owners, and how many hours per month will be spent on maintenance. Compare solutions after the pilot with measurable numbers: time per typical request, share of automated provisioning, number of manual exceptions and effort for reviews.

Data preparation and integrations before automation

IGA implementation doesn’t start with clicking buttons; it starts with understanding how much you trust your data and sources. If sources disagree, the system will simply distribute errors faster.

First step — determine the authoritative sources for employees and accounts. Usually that’s the HR system, Active Directory (or another directory), corporate mail and 3–5 key business systems where risk is highest (finance, document management, ERP/CRM, service desk, industry apps).

Clean up HR data

IGA relies on simple fields, but they’re often "dirty": job title, department, manager, location, employment type, hire date and termination date. A wrong manager breaks approvals; a missing termination date makes access perpetual.

Before integration, agree a minimal data standard and validations. For example: every employee has a current manager and department; job titles and departments come from a reference; termination date is recorded (at least planned) and kept updated; contractors have a distinct employment type and end date; and it’s clear who fixes HR data issues and within what timeframe.

Define role model and owners

Roles can be stored in the IGA platform or in a separate catalog, but more important is who in the business owns a role and its composition. Without role owners, roles quickly turn into an access warehouse where no one knows why someone has extra rights.

A pragmatic start is to define 10–30 typical roles by department (for example, accounting, procurement, support), assign owners and agree exception rules: when access is granted outside a role and for what duration.

Plan integrations: requests, notifications, logging

Even if you don’t automate everything immediately, decide in advance where requests and approvals will live (service desk, ITSM, internal portal), how notifications are sent (email, messenger) and where audit logs are stored.

A minimal launch typically includes: HR as master employee data, directory (AD) for accounts and groups, mail as a baseline resource, 1–2 critical business applications (finance, document management), and ITSM or a single approval process so approvals don’t live in chats.

Other systems are connected in waves: VPN, DBs, file stores, industry systems, cloud services. In organizations with 1,000+ employees it’s common to start with onboarding and termination (HR + AD + mail), then add finance and resolve exceptions. If an integrator leads the project, agree owners of source data and log formats in advance — otherwise progress will stall due to organizational gaps, not the platform.

Step-by-step IGA rollout for 1,000+ employees

In large organizations a phased rollout works better. This shows results faster and avoids breaking current processes. For IGA, data quality and governance matter more than "connecting everything at once."

Start with a small but visible first wave: 10–20% of accesses that are critical for the business and audit. Often this includes the AD account and mail, key business apps (ERP/CRM), and privileged access.

Early steps logic:

• define scope and objectives: which systems and departments, and a measurable result within 8–12 weeks (e.g. onboarding in 1 day instead of 5)
• document JML processes and issuance rules: what’s granted by job, department, location and employment type
• configure connectors and reconcile accounts: remove duplicates, agree the "source of truth", ensure the platform sees real rights

Then move from data to management:

• launch a role catalog: simple roles by job and typical access sets, avoiding attempts to cover all exceptions
• configure requests and approvals for 2–3 scenarios (new access, temporary access, role expansion)
• enable reviews and basic reports: access owners, approval history, overdue reviews, changes over a period

When the pilot is stable, scale up: add more systems, branches and special environments (production sites, data centers, medical or financial segments). Experience shows this gives a more predictable outcome than a big‑bang: get order in key accesses first, then expand coverage without stopping business.

Automating access requests and approvals

At 1,000+ employees requests become chaotic: emails, messengers, and “same as last time” messages. IGA aims for a single clear path for everyone, with consistent rules and auditable history.

Self‑service usually uses roles and templates. An employee selects a predefined set, sees status and expiry. The manager confirms need and duration. The application owner verifies the role fits the process. Security gets involved where risk is high: critical systems, personal data, finance, admin access.

To avoid free‑form requests, use standard roles like “New Accountant”, “Support Engineer”, “Sales Manager” with predescribed systems and privilege levels. Then discussions are about exceptions, not basics.

Make approval rules predictable: manager confirms need and duration, app owner confirms role correctness, security approves only risky requests or standards deviations, and temporary access always has an expiry date.

Auto‑provisioning is suitable when risk is low and conditions are clear (standard role, employee in correct department, mandatory prerequisites met such as training). It’s not suitable for privileged rights, financial operations, admin panels, patient or customer data, or requests like “make it the same as Petrov.”

Logging is a separate layer. For audits it’s important to store not only the fact of provisioning but its context: who requested, for whom, exactly what (role, group, privilege), who and when approved, which rule applied, duration, and the final entitlement. Record reasons for denial and role change history so audits don’t require digging through emails and chats.

Periodic reviews and SoD conflict control

Once provisioning is automated, another risk source is old rights that nobody reviews. Periodic recertification removes excess access, assigns responsibility and makes audits straightforward.

Start where the impact is largest: critical business systems (finance, procurement, HR, medical data) and privileged rights. Prioritize shared accounts, admin groups, access to customer data and security settings.

To keep reviews meaningful, predefine owners. Usually there are two levels: the application owner (who knows who should generally work in the system) and the data/process owner (who knows who needs access to specific reports, folders or roles). If there’s no owner, reviews stall — assign owners by policy and fix accountability.

Choose frequency by risk. A common scheme works well: privileged rights quarterly, critical business roles semiannually, everything else annually. Add event‑driven reviews for transfers, major role changes, long leaves and terminations.

Review options should be simple and consistent: keep (still needed), remove (no longer needed or inappropriate), or change (map to a standard role instead of an exception). Agree in advance how to handle overdue responses, how to document exceptions, who performs revocations and within what timeframe.

Run SoD checks in parallel. The idea is simple: one person should not hold a full cycle of actions enabling unnoticed fraud or errors. Typical conflicts: create vendor + approve payment, create employee + approve payroll, create request + approve and execute, admin access + viewing confidential data without need.

Don’t try to close everything at once. Start with 10–20 highest‑risk SoD rules tied to specific systems. The platform will flag conflicts during issuance and review, and you’ll see actionable risks rather than a long undifferentiated list of entitlements.

Operating model, metrics and audit readiness

Technology alone won’t solve the problem if nobody understands who changes roles, who approves and how exceptions are handled after go‑live. An operating model is needed so IGA works daily, not just during the project.

Start with simple metrics that show business and security value:

• time to provision: from request to actual entitlement
• share of automated operations: how many accesses were issued without manual steps
• approval delays: how many requests are stalled and at what stage
• denial reasons and share: lack of training, no justification, SoD conflict
• review violations: how many rights remained unconfirmed past due

Then assign responsibilities. IT handles integrations and accounts, security owns policies and SoD controls, HR supplies workforce events, application owners decide which rights exist and who needs them, role owners maintain role composition. Define who makes final decisions on disputed requests and who approves exceptions.

Support should be treated as a service, not a chain of chat messages. Define how access incidents are handled (not provisioned, excess granted, urgent revocation), how roles are changed, and how nonstandard cases are resolved. For example, clinics and banks often need temporary on‑call access; treat these as a separate request type with short duration and mandatory auto‑revocation.

For audits prepare evidence, not slides: reports of granted and revoked access, event logs and change history, approval histories (including denial reasons), review outcomes and actions on unconfirmed rights, SoD reports and documented exceptions.

To avoid IGA becoming a permanent manual effort, set change rules: roles change by request with an owner’s sign‑off, new apps connect by an integration template, exceptions have an owner and expiry. If you outsource parts of the work, agree boundaries and support formats upfront.

Common implementation mistakes and how to avoid them

IGA projects usually fail not because of platform choice but due to details: data, owners, scope of the first wave and change rules.

Mistake 1: starting with “ideal roles” without extracting actual rights

Sometimes teams design a role model in Excel without checking what people actually have. Roles don’t match reality and the migration becomes a never‑ending list of exceptions.

Avoid this by first collecting real entitlements from key systems, comparing them by department and job, and finding recurring sets. Build roles iteratively: 5–10 base roles in the pilot, then expand.

Mistake 2: too broad initial scope

Connecting “everything at once” drowns the team in custom accesses, local admins and manual agreements. The project stalls and the business loses trust.

Avoid this by starting with 2–3 critical systems and one process (for example, onboarding and transfers). Define what will be covered in waves two and three.

Mistake 3: no business owners

Without application and role owners, approvals become pass‑the‑buck and decisions get made by random people. This is a risk for security and audits.

Avoid this by appointing an application owner and a role/entitlement owner with final decision rights. This is critical for finance and HR systems.

Mistake 4: poor HR data and ignoring terminations and contractors

Wrong manager, incorrect start date or missing contractor status lead to wrong grants and delays. The most dangerous situation is active accounts after termination.

Avoid this by agreeing which HR fields are authoritative and setting quality controls (mandatory manager, department, start date, employment type). For terminations and contract ends set a rule to disable access on the event date.

Example: a transferred employee still has the old manager in HR. Approvals go to the wrong person and rights remain unchanged. Solve this with data validations and a correction workflow.

Mistake 5: no change process

After a successful go‑live chaos returns if it’s unclear how to add new systems, roles and rules. The team slips back into manual exceptions.

Avoid this by formalizing change management: who initiates, which data and owners are required, how to test and roll back, how to approve exceptions and how often roles and rules are reviewed.

Short checklist and next steps

Before starting IGA, verify the basics. Early mistakes are almost always not about the product but about missing owners, poor data and unclear rules.

Quick pre‑start checks

Collect the minimums without which a pilot will stall:

• identity sources: HR, AD/Azure AD and other account sources with a clear primary field for name, department, title and status
• list of target systems: mail, file stores, ERP/CRM, service desk, databases, indicating access type (role, group, account)
• owners: who approves access for each system and who maintains role composition
• JML rules: what to grant on hire, what to change on transfer, what to remove on termination, and in what timeframes
• minimal audit requirements: which reports are needed and how long logs are retained

Then define the pilot. A good guideline is quick impact without integration overload: 2–3 systems, one process and one review campaign. A frequent choice is HR as master data, AD for accounts, plus one business system with roles.

Also plan reliability. For on‑prem deployments decide where components will be hosted, how backups are done, who updates systems and what SLAs are needed for critical processes (e.g. disabling access on termination).

If you need help with architecture, implementation and support, it’s often convenient to work with an integrator who can cover infrastructure as well. For example, GSE.kz (gse.kz) as a vendor and system integrator can take on integration and support work, supply servers for IGA and provide 24/7 technical support through a service network.