Access Request: The Requestable Catalog and the Approval Flow

“Same as Sara”

Daniel has just joined the quarter-end close project in finance and needs to read the reporting warehouse for the next six weeks. His manager sends the service desk a short email: please give Daniel access to the finance share and the warehouse, same as Sara. Someone at the desk picks it up, looks at what Sara has, copies it to Daniel, and closes the ticket. By lunchtime Daniel can work.

It worked, in the narrow sense that Daniel got access. Now consider what nobody asked. Sara has been in finance for four years, and “same as Sara” includes everything she has accumulated, including the ability to edit vendor records from a project two years ago. Nobody decided Daniel should have that; it came along for the ride. Nobody who understood the warehouse or the vendor master approved anything; the person at the desk carried out an instruction. The project ends in six weeks, but the access has no end date, so it stays. And nobody checked whether Daniel, who can already approve invoices in his regular job, can now both create a vendor and pay it.

The first module of this domain built the ground IGA stands on: an authoritative identity record, a governed joiner-mover-leaver lifecycle, a curated entitlement catalog with owners and risk tiers, and the people accountable for all of it. JML covers the access people get because of who they are, the birthright a new hire receives on day one, the change a mover triggers. This article covers what’s left: the access people need because of what they’re doing right now, which no HR event can predict. In most organizations that remainder is bigger than anyone expects, and it’s where Daniel’s email lives.

What a ticket can’t tell you

A ticket answers one question: did someone ask? It rarely answers the ones an auditor, a reviewer, or someone investigating an incident will ask later. What exactly was granted, when “same as Sara” isn’t an entitlement but an instruction to copy whatever Sara happens to have, including what she shouldn’t? Who decided it was appropriate, when the person who executed the ticket was carrying out a request, not approving one? For how long, when a ticket has no idea of an end date? And did it create a conflict, when the queue has no idea what Daniel already holds?

A governed access request answers all of those. It’s the same human need, someone requires access they don’t have, expressed as a structured transaction against the entitlement catalog, routed through approvals sized by risk, checked against policy before anything is granted, and recorded in a way that’s evidence from the start instead of something to reconstruct later.

This isn’t bureaucracy for its own sake. A well-designed request process is usually faster than the queue it replaces, because the routing, checking, and fulfilling that someone at the service desk did by hand become automatic for the low-risk majority of requests. The governance comes from the structure, not from extra steps.

What a request contains

Every governed request, on any platform, carries five pieces of information, and each exists because something later depends on it.

It names a beneficiary, the identity that will hold the access, which isn’t necessarily the person asking. It names an entitlement from the catalog, never free text. It carries a justification, a reason a reviewer can actually judge. It has a duration, a start and, for most access, an end. And it records the requester, who submitted it: the beneficiary, their manager, or a delegate.

Keeping the beneficiary and the requester separate matters more than it looks. A manager requesting access for a new team member is routine. Someone requesting elevated access for themselves through another person’s identity is a warning sign. Keeping both fields lets an auditor tell the two apart, and lets a policy say that nobody may approve a request in which they are also the beneficiary.

Making the entitlement a catalog choice instead of free text is the change that makes everything else possible. It’s how the workflow knows who owns the entitlement (to route the approval), its risk tier (to decide how many approvals it needs), and its separation-of-duties tags (to check for conflicts), all of which the catalog article established. A request system without a catalog underneath it is a ticket queue with nicer forms.

The justification is the field most often wasted. A required text box that accepts “need access” teaches everyone to type “need access.” Better designs ask a specific question, such as which project or ticket this is for, and some link the justification to a work item in another system, so the reason for the access is something that can be checked rather than a sentence nobody verifies. Daniel’s request would carry the close project’s reference and inherit its end date.

What goes in the requestable catalog

Not every entitlement in the catalog should be requestable. The catalog from the previous module is an inventory of everything governed; the requestable catalog is the part someone can ask for through self-service. Drawing that line is the main design decision in an access request program, and it splits the catalog three ways.

flowchart TD
  accTitle: Three channels through which entitlements reach people
  accDescr: The governed entitlement catalog splits into three channels. Access everyone in a population needs is assigned automatically by birthright and role rules driven by HR data. Access some people need case by case is published in the requestable catalog and granted through an approved access request. Access nobody should hold permanently, such as production administration, is granted only through time-limited or just-in-time elevation that expires on its own.
  CAT[Governed entitlement catalog] --> Q1{Does everyone in<br/>a population need it?}
  Q1 -->|Yes| BR[Birthright or role assignment<br/>automatic, from HR data]
  Q1 -->|No| Q2{Should anyone hold<br/>it permanently?}
  Q2 -->|Yes, case by case| REQ[Requestable catalog<br/>approved request]
  Q2 -->|No| JIT[Time-limited or JIT elevation<br/>expires on its own]

Access everyone in a population needs stays out. If every accounts payable clerk needs the same four entitlements, making each new clerk request them one by one wastes everyone’s time and invites inconsistency: one manager approves all four, another forgets the third. That access belongs to the JML process and to the roles and policies covered later in this module.

Case-by-case access is what the requestable catalog is for: entitlements some people legitimately need, where a named owner can judge each request. Read access to a project’s data, edit rights in a particular CRM pipeline, membership in a cross-team workspace. Daniel’s six weeks in the warehouse is the textbook case.

Access nobody should hold permanently, production administration, break-glass accounts, the ability to export a whole customer database, shouldn’t be requestable as standing access at all. It belongs to a time-limited model: a request that grants access for hours, not indefinitely, and removes it on its own. This is where access request starts to overlap with privileged access management, which has its own domain; the IGA side of the boundary is making sure the catalog marks these entitlements clearly so nobody can request them as ordinary, permanent access.

Helping people pick the right thing

A requestable catalog fails quietly when people can’t tell which entry they need. Faced with ERP.PurchaseOrderApproval.Under10K, ERP.PurchaseOrderApproval.Over10K, and ERP.VendorMaster.Edit, someone who just needs to “work on purchase orders” often picks the one that sounds most senior, the one a colleague mentioned, or all three. The approver, seeing three entitlements, approves all three to avoid another round of emails.

The fix is in presentation, not governance. The structured names from the catalog serve reviewers and auditors; requesters need a plain-language name and a sentence on who usually needs it, entitlements grouped by what people are trying to do (“Finance: purchasing”) instead of by system, search that understands the words people actually type (“PO approval,” “purchasing,” “SAP”), and a visible approval path and default duration. Telling a requester up front that an entitlement needs the owner’s approval and expires in 90 days sets expectations and quietly discourages casual requests.

Many platforms offer a “request the same access as this person” button, and it’s popular for the same reason “same as Sara” is: it’s fast. It’s also dangerous for the same reason. If you offer it at all, show the requester the list of entitlements it would add, make them remove anything they can’t justify individually, and send every remaining entitlement through the same approvals and checks as a normal request.

Approvals sized to risk

Approval is where request processes most often go wrong, in one of two opposite directions. With too little, the process is self-service with an audit log. With too much, every request spends days in a chain of approvers who each assume someone else is the real check, so nobody looks. The risk tiers from the catalog are what let a program avoid both.

Two approvers aren’t twice the control of one. They’re only useful if each checks something different. The manager is in a position to confirm the business need: is Daniel actually on the close project? The entitlement owner is in a position to confirm it’s the right access for that need: given the project, is warehouse read access enough, or does he really need more? A second approver for privileged access adds independence, someone outside the requester’s reporting line with no stake in getting the work done quickly. If the manager and the owner check the same thing, one of them is redundant. If neither knows what they’re supposed to check, both are.

sequenceDiagram
  accTitle: The life of a risk-routed access request
  accDescr: A requester submits a request for an entitlement from the catalog. The IGA platform first checks population eligibility and separation of duties. If the checks pass, the request goes to the beneficiary's manager to confirm the business need, then, for elevated or privileged entitlements, to the entitlement owner to confirm the access fits that need. Once approved, the platform provisions the access in the target system with an end date, and a later reconciliation confirms the access exists as granted.
  participant R as Requester
  participant IGA as IGA platform
  participant M as Manager
  participant O as Entitlement owner
  participant T as Target system
  R->>IGA: Entitlement, justification, end date
  IGA->>IGA: Checks (eligibility, SoD)
  IGA->>M: Is there a business need?
  M-->>IGA: Approved
  IGA->>O: Is this the right access? (elevated/privileged)
  O-->>IGA: Approved
  IGA->>T: Provision with end date
  T-->>IGA: Reconciliation confirms access exists
  IGA-->>R: Granted until the end date

When an approver isn’t there

Every approval chain eventually meets an approver who isn’t available, and how the process handles that moment decides whether it degrades gracefully or quietly loses its controls.

Delegation lets an approver hand their authority to someone else for a defined period, a manager on parental leave delegating to a peer. It should be explicit, time-limited, and recorded, and the delegate should never approve a request in which they’re the beneficiary. Chains of delegation, where A delegates to B who delegates to C, are worth blocking outright, because they make it almost impossible to reconstruct who held authority.

Escalation handles the approver who simply doesn’t answer. A sensible default is a reminder after one business day, escalation to the approver’s own manager after three, and automatic rejection, not approval, after a set maximum. Automatic approval on timeout is one of the most common hidden failures in request programs: it turns “nobody looked at this” into “approved,” which is exactly backwards for a control.

Self-approval should be impossible by design. The obvious case, a manager approving their own request, is easy to block. The subtler case is a request where the beneficiary happens to be the entitlement’s owner. The rule worth enforcing is simple: nobody approves access for themselves, in any role, and the platform routes to the next approver automatically when that happens.

Checks that run before anyone approves

The most valuable thing a request process does is often invisible to the people using it: the checks that run before any person is asked to approve anything. Each exists because finding the same problem after access has been granted is slower, more expensive, and sometimes too late.

The most important is separation of duties. The platform compares what the beneficiary would hold after approval with the organization’s conflict rules. In Daniel’s case, if “same as Sara” had gone through a governed request, the platform would have seen that he already approves invoices and was about to receive vendor-master edit rights, a combination that lets one person create a fictitious supplier and pay it. A check at request time catches that before the access exists and either blocks the request or sends it to a risk approver who can grant it only with a documented compensating control. The alternative, finding it in the next review, means the window for fraud was open the whole time. Separation of duties gets its own module later in this domain; here the point is where in the process the check lives.

Population eligibility is the second check. The catalog article recommended recording which populations may hold each entitlement, and this is where that pays off. A contractor never even sees privileged entitlements in their catalog, and a request for a human-only entitlement on behalf of a service account fails immediately, instead of reaching an approver who might not notice.

Redundancy is the third. If the beneficiary already holds the entitlement, directly or through a role, the request is unnecessary, and catching it avoids duplicate assignments that later confuse reviewers and leave stray grants behind when the role is removed. Some programs add limits too, such as a cap on how many elevated entitlements one identity can hold or how many requests can be pending at once. They aren’t universal, but a person who suddenly requests a dozen elevated entitlements in an afternoon deserves a human look even if each request is individually justified.

End dates: making “until further notice” the exception

The single most useful design choice in access request is giving most access an end date. Access granted indefinitely is the raw material of privilege creep: the project ends, the need disappears, and the entitlement stays, because removing it requires someone to remember it exists, and remembering isn’t anyone’s job.

An end date flips the default. Instead of depending on someone to notice and remove access that’s no longer needed, the access removes itself unless someone actively renews it. Renewal becomes a light, targeted review: a few days before expiry, the beneficiary or their manager is asked whether the need still exists, and the access either renews with a fresh justification or lapses on schedule.

Three kinds of duration cover most cases. Long-lived access with renewal suits standard access tied to an ongoing responsibility, usually six to twelve months before the renewal question. Project-scoped access ends when the project does, which is easy to get right when the request is linked to a project or ticket with its own end date; Daniel’s warehouse access ends with the close. And just-in-time access grants elevated or privileged access for minutes or hours to do a specific task, then removes it on its own. It’s now the normal approach for production and administrative access, and it changes the question from “who has standing admin rights?” to “who used admin rights, when, and why?”, which is far easier to answer and to audit.

End dates also change what a review campaign has to do. If most elevated access already expires on schedule, the next review looks at a smaller, more deliberate set of standing grants instead of cleaning up everything that piled up since the last one. The two controls reinforce each other: end dates prevent accumulation, and reviews catch what end dates didn’t cover.

From approved to actually granted

An approved request is a decision, not access. Fulfillment turns the decision into a real change in a target system, and it comes in two forms with very different properties.

Automated fulfillment runs through a connector, SCIM, a REST API, LDAP, a database script, that provisions the entitlement and reports success or failure back to the IGA platform. The request record and the provisioned state stay linked, and removal at the end date happens through the same connector.

Manual fulfillment sends the approved request to a person, often the system’s administrator, as a task. It’s unavoidable for old systems with no API, and it’s where most request programs leak: the task gets closed as done whether the access was granted exactly as approved, granted with something extra “while I was in there,” or never granted at all.

Either way, what makes fulfillment trustworthy is reconciliation, introduced in the JML article: regularly reading the actual state of each target system and comparing it with what the platform believes should be there. For requests, reconciliation answers two questions a task status never can. Was the approved access really granted? And, more importantly, is there access in the system that no approved request explains? The second question is how a program finds access granted directly in an admin console, bypassing requests altogether. The provisioning article later in this module goes deeper into both.

It helps to track three states separately: approved, meaning a person decided; provisioned, meaning a connector or an administrator says they made the change; and confirmed, meaning reconciliation read the system and found the access there. Reports that collapse all three into “complete” hide exactly the failures an auditor will look for.

Worked example: production admin in four steps

A mid-sized online payment processor runs its payments API on a cloud platform. Eight engineers have held standing administrator access to production “in case of incidents.” The security team wants to replace that with requested, time-limited access, and the IGA program designs the flow in four steps.

First, standing access goes and a single entitlement is defined. The catalog gets Cloud.Production.Admin.JIT, tiered privileged, owned by the platform engineering lead, and eligible for employees only. All eight standing assignments are removed. From now on nobody holds production admin by default.

Second, the request has to carry evidence. Requesting the entitlement requires an incident or change ticket number, checked against the ticketing system, and a duration of at most four hours. The form tells the engineer the ticket must be open and assigned to them.

Third, routing follows the situation, not habit. For a planned change, the request goes to the platform engineering lead and then to a second approver from security: two approvers checking different things. During a live incident, waiting for two approvers isn’t realistic, so the flow changes shape. The on-call engineer gets access immediately with one approval from the incident commander, and security reviews the session afterwards within one business day. The control isn’t weaker; it moves from before to after, with a firm deadline.

Fourth, access expires, is logged, and is reviewed. It’s removed automatically at the end of the window, every session is recorded, and a weekly report lists every elevation with its ticket, approvers, and duration. Any elevation without a matching closed ticket is investigated.

After a quarter, standing production admin has gone from eight people to none, the median wait for access during a planned change is under ten minutes, and the question “who could have changed production last Tuesday?” has a precise answer instead of “any of eight engineers.”

A second example: a contractor and the CRM

A shorter case shows the same machinery at standard risk. An external sales consultant, onboarded through the vendor system as a non-employee, needs to work leads in the CRM during a three-month engagement.

Their requestable catalog, filtered by population, shows only what contractors may hold: viewing pipeline data and editing their own opportunities, but not exporting contact data, which the catalog marks employee-only. The person who manages the engagement submits the request on the consultant’s behalf, the justification references the statement of work, and the end date is filled in from the contract’s end date in the vendor system. One approval from the CRM owner is enough at this tier.

Three months later the contract ends and the access lapses on its own, the same day the vendor system closes the engagement. A week before that, the sponsor gets a reminder asking whether the engagement is being extended, so a late renewal doesn’t cut the consultant off in the middle of a deal. Nobody had to remember to remove it, and when the next review runs there’s nothing for a reviewer to clean up.

How request programs go wrong

Most request programs don’t fail loudly. They drift into patterns that look like governance on a dashboard and aren’t.

The rubber-stamp approver approves forty requests in four minutes. Nothing was technically skipped and nothing was really reviewed. The causes are usually structural, too many low-risk requests routed to people, approvers who don’t know what they’re checking, no context on the approval screen, and so are the fixes: automate the standard tier, tell each approver what their check is, and show them what the beneficiary already holds.

The unreadable catalog sends people back to tickets, to “same as Sara,” or to requesting everything that sounds plausible. Request volume looks healthy while the catalog is effectively bypassed.

The permanent default has an end-date field that defaults to “never,” so almost nobody sets one. Make it mandatory above the standard tier and fill in a sensible value.

Timeout-as-approval, mentioned above, is common enough to repeat: any workflow that approves a request when nobody answers has turned silence into consent.

And the side door: administrators keep granting access directly in consoles “because it’s faster,” and the request process governs only what happens to go through it. Reconciliation against approved requests is the only reliable way to find the side door, and the right response is usually a conversation about why the front door is slow, not just a policy reminder. If the governed path takes three days and the side door three minutes, people will use the side door. A process that automates the standard tier and decides elevated requests within a business day removes the main reason to go around it.

Measuring whether it works

Request processes produce plenty of data. The useful measures are the ones that show whether the process is a real control.

Request time, split by risk tier, shows how long people wait; standard requests that take days are a sign the side door is about to open. The share of requests approved without any change, and the rejection rate per approver, show whether approvers ever say no; an approver who hasn’t rejected anything in a year isn’t reviewing, and approval rates near 100% at elevated tiers suggest a rubber stamp. The number of requests that reach their end date without renewal shows whether end dates actually remove access; zero expirations means nobody is setting them. The amount of access reconciliation finds with no matching request is the size of the side door. And the balance between conflict checks that blocked a request and those that were overridden shows whether the check is a control or a suggestion.

As with the catalog measures, the trend matters more than any single number. Falling request times with a steady, non-zero rejection rate describe a process people trust and that still says no when it should. Falling request times with a falling rejection rate describe a process turning into a formality.

Where this maps to standards

Access request is one of the IGA controls standards name most directly:

• NIST SP 800-53 Rev. 5, control AC-2 (Account Management), requires access to be authorized by designated approvers with an intended use and duration, and AC-6 (Least Privilege) explains why requested access should be minimal and time-limited.
• SOC 2 Trust Services Criteria, CC6.2 and CC6.3, expect access to be authorized before it’s granted and changed or removed according to roles and need, which auditors test by sampling request records.
• PCI DSS v4.0, Requirement 7, requires access to cardholder data to be approved by authorized personnel and limited to least privilege, with the approval documented.
• ISO/IEC 27001:2022, Annex A control 5.18 (Access rights), calls for access rights to be provisioned, reviewed, changed, and removed according to a defined process; the request workflow is that process made concrete.
• The IDPro Body of Knowledge covers access request and approval workflow design as practitioner discipline.

Closing the loop

The first article of this domain described IGA as a loop between administration and governance. Access request is where the two halves meet in a single transaction. A governance decision, who approves, under which policy, for how long, produces an administrative action, provisioning through a connector, and reconciliation checks that the action matches the decision. Everything the first module built shows up here: the identity record decides who the beneficiary is, the catalog defines what can be requested and who owns it, the risk tiers set how many approvals it takes, and the program roles decide who answers for the workflow working. Daniel’s six weeks in the warehouse, done this way, would have been the right access, approved by the right people, gone on the day the close ended.

Recap

• An access request is a structured, governed ask for a catalog entitlement, with beneficiary, entitlement, justification, duration, and requester, not a free-text ticket or “same as Sara.”
• The requestable catalog is only the case-by-case part of the governed catalog. Birthright belongs to JML and roles; permanent privileged access shouldn’t be requestable at all.
• Approvals scale with risk, and each approver should check something different: the manager the need, the owner the fit, a second approver independence. Silence never approves.
• Conflict, eligibility, and redundancy checks run before anyone approves, and a failed check must block or route, not just warn.
• End dates are the strongest defense against privilege creep; just-in-time access is the norm for privileged work.
• Approved, provisioned, and confirmed are different states, and reconciliation is what shows the access matches the decision and reveals the side door.

Three questions to test yourself

1. A workflow sends every request to both the manager and the application owner, whatever the risk tier. Requests take four days on average, and both approvers approve 99% of the time. What would you change, and why might adding a third approver make things worse?
2. Explain the difference between a preventive and a detective conflict check, and describe a concrete fraud scenario that only the preventive check would have stopped.
3. Reconciliation finds 300 entitlements in a target system with no matching approved request. Give three different explanations for the gap and what you’d do about each.

Hands-on exercise

Pick one application you use at work or in your studies, or the payment processor from the worked example, and design its access request model on a single page.

1. List five entitlements and classify each as birthright, requestable, or time-limited, with one sentence of justification.
2. For each requestable or time-limited entitlement, set the risk tier, the approval path (who approves and what each checks), and the default duration.
3. Write one conflict rule a preventive check should enforce between two of your entitlements, and decide what happens when it fails: block, or route to whom?
4. Pick three measures from this article you’d report every month, and write down the value that would make you suspect the process had become a rubber stamp.