Manual Identity Governance: How to Move Beyond Spreadsheets

Authors: Adil Khan and Vrinder Randhawa

To move beyond manual identity governance, start with one application and one access problem. Identify who has access, establish who should approve it, check permissions against business policies, and verify that approved changes actually happen. Automate that complete process before expanding to more applications, users, and identities.

Consider an employee moving from accounts payable into procurement. The new manager approves purchasing access. IT completes the request. The employee starts work.

But who checked whether the employee’s old payment permissions were removed?

That question captures the central challenge for organizations managing access through spreadsheets, email approvals, and service desk tickets: connecting a business decision to the access that actually exists.

What is identity governance, and how is it different from signing in?

Identity governance determines who should have access, why they need it, who is accountable for approving it, and when that access should change.

Three related functions help explain the distinction:

Function	Question it answers
Authentication	Is the person or system requesting access who it claims to be?
Authorization	What actions can that identity perform?
Governance	Why is that access appropriate, who approved it, and what evidence supports the decision?

An employee can sign in successfully and hold valid permissions while retaining access that their current job no longer requires.

Identity governance and administration, or IGA, connects oversight with the processes used to create accounts, grant permissions, review access, and remove it. SafePaaS’s guide to identity governance and administration explains these foundations and the capabilities involved.

Where do manual access processes break down?

Manual processes become difficult to verify when requests, approvals, application changes, and evidence sit in separate places.

A ticket may record what someone requested. An email may contain the approval. A spreadsheet may list assigned roles. None of those records, individually, establishes whether the resulting application permissions match the decision.

In the Webinar, Identity is your biggest risk. Are you still managing it manually? SafePaaS CEO Adil Khan describes an implementation challenge he encounters with customers: identity information is spread across directories, cloud identity platforms, and application-specific accounts. Teams then have to reconcile those sources to establish who has access.

The practical lesson is to trace one request through its entire journey:

1. What business event created the need?
2. Who approved the access, and what information did they see?
3. Which policy checks were performed?
4. What changed in the application?
5. How was the outcome verified?

Record every point where someone retypes information, moves a file, requests clarification, or relies on personal knowledge. Those handoffs reveal where automation could remove work and where accountability needs to be clearer.

Service desk tickets can remain useful for assigning and tracking work. The missing connection may be between the ticket, the access decision, and confirmation from the application.

Why do employee transfers deserve closer attention?

An employee transfer requires a decision about existing access as well as new access.

Illustrative example: Alex moves from accounts payable into procurement. His manager requests purchasing permissions, and IT grants them. If the process only asks what to add, Alex’s previous payment permissions may remain active.

Depending on the exact permissions, Alex could gain the ability to maintain supplier details while retaining payment-related capabilities. That combination warrants a segregation of duties review.

Segregation of duties, or SoD, separates activities that should require independent involvement. However, two job titles alone do not establish a conflict. The assessment must examine actual capabilities, relevant business units, and company policy. An access conflict also does not establish that fraud occurred.

For a transfer, ask:

• Which permissions remain necessary?
• Which permissions should be removed?
• Does the combined access conflict with policy?
• Is temporary overlap justified, approved, and time-limited?
• Who will verify that the old access was removed?

SafePaaS’s identity lifecycle management approach describes how joiner, mover, and leaver workflows can incorporate policy checks, business context, approvals, and evidence. Coverage and execution should be assessed for the applications involved.

What makes an access review meaningful?

A meaningful access review gives the reviewer enough information to judge what a person can do, then tracks the resulting actions through to verification.

A role code or technical entitlement name may mean little to a business manager. Reviewers need understandable descriptions of the activities that access permits, together with relevant organizational context.

For example, “maintain supplier banking details” gives a reviewer a clearer decision than an unexplained role identifier. The reviewer may also need to know which legal entity or business unit the permission covers.

SafePaaS’s approach to entitlement-level access reviews explains how reviewers can examine the privileges behind role names.

The next question is whether reviewers carried out the decisions.

Review completion and verified access removal measure different outcomes. A manager may finish reviewing every item while removal actions remain delayed, unsuccessful, or unconfirmed.

For every removal decision, retain a record of:

• The identity, application, and permission involved.
• Who made the decision and when.
• The person or system responsible for carrying it out.
• The result, including failures and outstanding work.
• The evidence used to confirm the application’s resulting access.

The useful test is simple: can you account for every removal requested in the last review?

How does AI change identity governance?

AI adds another governance question when software can take actions through connected tools and applications: whose authority is being used?

An assistant that reads supplier information and recommends an option has a different access profile from an agent that can update supplier records or initiate a purchasing workflow. The distinction lies in the actions the system can perform and the permissions it uses to do so.

An AI assistant that compares supplier quotes should not automatically have permission to change supplier bank details or release payments. Limit its tools and access to the task, make the connected applications enforce those limits, and require human approval for sensitive actions.

Extend the access inventory to include service accounts, bots, integrations, and identities used by AI agents. For each, document:

• Its business purpose.
• Its accountable business owner and technical operator.
• The applications and permissions it uses.
• Whether it acts through its own account or delegated user access.
• The actions requiring human approval.
• When access will be reviewed or withdrawn.

An instruction such as “do not change supplier details without approval” should be backed by application permissions and an enforced approval step. Written instructions alone do not establish that control.

How can you start without automating everything?

Begin with one process whose outcome you can verify. An employee transfer involving sensitive financial access is one possible starting point.

Four connected activities:

Activity	What to establish
Discover	Identify accounts, permissions, owners, and relevant application context.
Decide	Define appropriate access, approval responsibilities, policy checks, and exceptions.
Enforce	Carry out approved additions, changes, and removals.
Verify	Confirm that application access reflects the decision and retain evidence.

A Repeatable Access Governance Cycle

Assign responsibilities across that process. Business owners explain why access is needed. Application owners clarify what permissions allow. IT or an automated workflow executes changes. Security and compliance teams define policy and evidence requirements.

Automation needs to connect those responsibilities.

Explore how to establish identity governance beyond spreadsheets and email approvals, starting with your highest-priority application and access risks.

Before changing the process, establish a baseline:

Business objective	Useful measure
Security	Time obsolete sensitive access remains active after a transfer.
Compliance	Proportion of required removals verified within the agreed deadline.
Business enablement	Time until an employee has the appropriate access to work.
Affordability	Staff time spent processing requests, chasing approvals, correcting errors, and preparing evidence.

Measure elapsed time separately from active handling time. A request may wait several days while consuming relatively little staff effort; another may close quickly but require repeated intervention. Those problems need different responses.

What does connecting the process look like in practice?

A global mobile insurance provider illustrates how existing identity tools can leave application-level work disconnected.

The insurer already used SailPoint, but its implementation lacked the Oracle-specific visibility needed to assess detailed permissions, privileged access, and segregation of duties risks. Remediation involved email coordination and unclear ownership.

SafePaaS extended governance into Oracle ERP while SailPoint remained the enterprise identity system of record. The organization introduced policy-driven Oracle lifecycle workflows, rules-based access monitoring, and ServiceNow-connected workflows for assigning, investigating, and documenting remediation.

For organizations working manually, the transferable lesson is to connect access information, policy decisions, and remediation ownership within a defined process. Existing systems can remain part of that process.

The global mobile insurer’s Oracle identity governance case study also distinguishes implemented capabilities from planned work: automated ticket creation and controlled deprovisioning are described as a next phase, rather than completed outcomes.

What should you ask an identity governance provider to demonstrate?

Ask the provider to follow one representative access change from the business event through to the verified application outcome.

Use a scenario that reflects your environment. For example, ask the provider to demonstrate an employee transfer that adds purchasing access, checks existing payment permissions, routes any exception, and records the result.

Evaluate whether the proposed solution can:

• Explain the permissions behind application role names.
• Assess requested access alongside existing access.
• Apply relevant business-unit or legal-entity context.
• Show who owns approvals, exceptions, and remediation.
• Distinguish successful changes from failed or outstanding actions.
• Retrieve evidence without reconstructing the decision from separate records.

Confirm which applications support direct changes and which require manual fulfillment. Ask what triggers checks, how current the access data is, and how the system detects an unsuccessful change.

A feature list cannot answer those questions as clearly as a demonstrated process using representative roles, permissions, and exceptions.

Put one access process to the test

Choose one application, one accountable owner, and one access problem you want to improve. Define the evidence that would demonstrate success before selecting automation.

To assess how that process could work in your environment, book a SafePaaS access governance walkthrough. Bring a representative transfer or access-review scenario and ask to follow the decision through policy checks, application changes, and evidence of the outcome.