Identity Governance and Access Certification: Why Do Managers Approve Everything They Cannot Understand?

The quarterly ritual everybody knows is theatre

A compliance analyst exports entitlements from eleven systems, pivots them into spreadsheets by manager, and emails 340 of them. A manager in operations opens hers and finds 61 rows. One says FIN_GL_JE_POST_ALL. Another says SAP role Z_MM_INV_02. A third says database role rw_prod_billing. She has fourteen direct reports, a day job, and no basis whatsoever for judging whether any of these are appropriate. She selects all, clicks approve, and returns the spreadsheet in four minutes.

The campaign completes at 98 percent approval. The evidence pack goes to the auditor. Everyone involved knows the exercise proved nothing, and the reason is not laziness. It is that the manager was asked a question she was structurally unable to answer. Nobody told her that FIN_GL_JE_POST_ALL lets a person post journal entries without a second approver, that only four people in the company should hold it, or that her report last used it eleven months ago.

Meanwhile the actual risk is somewhere else entirely. A developer who moved to a different team in 2022 still holds production database access, because the move was a transfer rather than a leaver and no process covers transfers. A contractor's account in a legacy application that was never connected to the identity system is still live two years after the engagement ended, because the offboarding checklist covers the systems someone remembered in 2019.

What SailPoint, Saviynt and the platform vendors do well

These products exist because the problem is real, and where they fit they are a better buy than a build. SailPoint and Saviynt have deep connector libraries, mature campaign engines, role mining and policy models developed over many years. Omada and One Identity are strong in their segments. Microsoft Entra ID Governance and Okta Identity Governance are excellent value if your estate is largely within their ecosystem, because the identity data is already there and access reviews become a configuration exercise rather than a project.

Two things push organisations past them. The first is the long tail of applications. A bank or a hospital group runs a core system from the 1990s, a specialist clinical or trading application, several vendor hosted systems with no API, and a handful of tools where access is defined inside the application by a local administrator. None of these have a standard connector. Every governance product supports building custom connectors, and that is real engineering work you will do regardless of which licence you hold. The uncomfortable arithmetic is that if two thirds of your risk sits in applications you must integrate manually anyway, a large licence buys you the campaign engine and not much else.

The second is entitlement semantics. A connector can extract that a user holds a role called Z_MM_INV_02. Nothing extracts what that role permits, who should hold it, or whether it combines with another role to break a segregation of duties rule. That knowledge lives with application owners, and building the process to capture and maintain it is the actual project. Products give you fields to store it in. They do not give you the descriptions, and campaigns run on undescribed entitlements are the rubber stamp you already have.

Make the reviewer's question answerable

The design principle worth building around is that a reviewer must be able to decide from what is on screen, without asking anyone. That means every entitlement presented in a campaign carries a plain language description written by its application owner and reviewed on a cycle, a risk rating, whether it is privileged, and any segregation of duties conflicts it participates in.

Then add usage. Last used date changes reviewer behaviour more than any other single field, because approving access a person has not touched in a year feels different from approving access they used yesterday. Usage data is harder to get than entitlement data, since it means pulling application logs or authentication events, and it is worth the effort. Add peer comparison where it is meaningful: this person holds three entitlements that none of their fourteen colleagues in the same role hold. That is the outlier a reviewer can act on. Finally, make revocation the cheap path. If approving is one click and revoking triggers an email thread, you have designed for approval. Revocation should be one click too, with the de-provisioning executed automatically and reversibly if it turns out to be wrong.

The joiner, mover, leaver gap is where the real risk lives

Certification campaigns are a periodic backstop. The continuous control is lifecycle, and movers are the weak point in nearly every organisation. Leavers get attention because HR (Human Resources) triggers a termination and someone disables accounts. Movers accumulate: each transfer adds the new team's access and rarely removes the old, so a person who has been at the company eleven years and moved four times holds the union of every role they have ever needed.

Build the mover event explicitly. When the HR system reports a department, manager or job code change, generate a review of that person's existing access against their new position, routed to the new manager with the old manager copied, with a deadline and an escalation. This is a smaller piece of engineering than a campaign engine and it prevents more accumulation than any quarterly review does.

Handle the systems outside your identity provider with the same seriousness. Every application that a person could have access to needs to be in the leaver checklist, including the ones with local accounts, and the system should track which of those have confirmed removal rather than assuming it. Orphaned accounts with no matching active employee should be detected continuously and surfaced, not discovered during an annual review.

Connectors are the budget, so plan them deliberately

Modern applications supporting SCIM or a decent API are quick. The rest fall into a few patterns and each has a known cost shape. Database backed applications where entitlements live in tables can be read directly with a read only account, which is fast but requires the vendor to tell you the schema and requires you to handle their upgrades. Vendor hosted systems with only a user interface need either a scheduled export the vendor can produce or, as a last resort, automated interaction with the interface, which is fragile and needs an owner. Mainframe and terminal systems usually have a reporting path that an administrator has been running manually for years, and turning that into a scheduled feed is often the cheapest win available.

Where no automated path exists, do not pretend otherwise. Build an attested manual feed: the application owner uploads a signed extract on a schedule, the system records who provided it and when, and it ages visibly if it is not refreshed. That is honest, it is auditable, and it beats a connector that silently returns stale data.

What it costs and how long it takes

From the projects Digital Heroes has delivered, a first release covering the identity and entitlement data model, HR feed integration, connectors for your top applications by risk, the campaign engine and revocation workflow runs $100,000 to $200,000 and ships in 14 to 20 weeks. The full build adding the long tail of connectors, segregation of duties policy, mover and leaver automation, usage data collection, privileged access handling and audit evidence generation runs $280,000 to $650,000 phased over 9 to 18 months.

What drives cost up: the number of applications and how hostile each one is to integration, which is by far the dominant factor. Segregation of duties policy, because defining the rules is a business exercise involving finance and internal audit rather than an engineering task. Usage data collection, which multiplies the integration work per application. Regulatory evidence requirements. And organisational complexity, since a group with multiple legal entities and different approval hierarchies per entity is a materially different build from a single company.

What keeps it down: rank applications by risk and integrate the top ten properly rather than forty superficially. A campaign covering your ten most sensitive systems with meaningful descriptions and usage data is worth more than one covering everything with role codes nobody understands.

When to buy instead

If your estate is essentially Microsoft or Okta with modern applications, buy the native governance product. The identity data is already in place and you will be running real access reviews in weeks rather than months. Anyone who tells you to build in that situation is selling you a project.

If you have a large but conventional application estate with good connector coverage, evaluate SailPoint or Saviynt properly. Their campaign engines and role mining are mature and rebuilding them is not a good use of money.

Build when a large share of your risk sits in applications with no standard connector, when your approval hierarchy crosses legal entities or works differently by business unit, when segregation of duties rules are specific to your own process design, or when you have licensed a governance product and are still running the campaigns that matter in spreadsheets. The last one is the clearest signal, and it is more common than vendors would like.

How to choose a developer

Ask them to describe integrating your three worst applications by name. If the answer is generic, they have not done this. Ask specifically what they do when an application has no API and no export capability, and expect the attested manual feed rather than a promise.

Ask how they will make entitlements understandable to a reviewer, and listen for a process to capture and maintain descriptions from application owners rather than a database column. The column is easy. The process is the work.

Ask how revocation actually executes, end to end, including what happens when de-provisioning fails silently on one system. An access review that produces revocation decisions nobody carries out is worse than no review, because now there is documented evidence that you knew.

Ask how movers are handled, since that is where accumulation happens and where most implementations are thin.

Get code and infrastructure ownership in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A system that holds the map of who can do what across your entire organisation should not be rented from a supplier you cannot replace.