Access requests that keep piling up on one person

When every access request routes through one approver, you have an access request bottleneck: a single queue, no role model and no audit trail. Requests wait days, rushed reviewers grant too much, and one resignation stops the business. The fix is tiered ownership — roles, delegates and time-bound grants.

Key Takeaways

• An access request bottleneck is a missing role model, not a slow person. You cannot delegate what you have never defined.
• Measure before changing. Log two weeks of requests; the pattern with the longest wait shows which fix pays for itself first.
• Define least-privilege roles per system, then hand approval to named system owners — in that order.
• Put an expiry date on every elevated grant. No standing admin, including yours.
• Keep one sealed, logged break-glass account for emergencies and review it after every use.
• Verify with numbers: median request age, monthly grant sampling, quarterly offboarding drills.
• Most teams past roughly ten staff need identity-provider groups with owners — not dedicated access-management tooling.

Why does every access request end up on one desk?

Access pools on one person because granting rights needs two things most teams never wrote down: a list of roles per system and a record of who already has them. Without that map, trust substitutes for process — the one admin who "knows what everyone should have" becomes the only safe approver.

The pattern starts innocently. A founder or ops lead sets up the email, the accounting tool and the file store, keeps the passwords, and becomes admin by default. Two years later there are fourteen systems, no written roles, and nobody else who can tell a legitimate request from a risky one. The queue is not a workload problem; it is a missing role map plus a missing audit trail, and both can be written down in an afternoon of honest work.

What does an access request bottleneck cost you?

The bottleneck costs latency, then security. Requests that take three days push staff toward shared passwords; rushed reviewers grant admin instead of the right role; and offboarding stalls because only the approver knows who holds what. Every failure traces back to access knowledge stored in one head.

The visible cost is idle time: a joiner sits waiting, a report goes stale. The hidden costs are worse. Staff who wait start sharing logins, so the audit trail you never had now actively lies. "Give them admin for now" becomes forever. And the approver is a bus-factor risk — how many people would have to disappear before the work stops? When system knowledge lives with one person, their two-week leave is an outage.

When is one approver actually the right call?

Keep a single approver while the team is small enough that they know every system personally — roughly one admin per ten staff and fewer than a handful of systems. Past that, latency and bus factor outweigh the control. Write the role map first; delegation without it just moves the queue.

Do not build machinery you do not need. A five-person company with three systems and one director who knows every login is working as intended. Start fixing when any of these is true: systems number more than a handful, requests outpace same-day answers, or any single system's loss would stop billing or production.

How do you find where the queue is actually stuck?

Diagnose with a two-week sample before changing anything. Log every request with arrival time, grant time and what was granted. Most queues split into three patterns: repeated role onboarding, one-off elevated access and forgotten revocations. The pattern with the longest wait tells you which fix pays for itself first.

1. Count the queue. Pull the last two months of requests from email or chat; note arrival and grant time for each.
2. Classify each request as onboarding, elevated access, read-only lookup or revocation. Three or four patterns usually cover everything.
3. Measure median wait per pattern. The slowest one marks where the fix pays first — usually lookups, which self-service clears cheaply.
4. Check for shared credentials. Ask who else knows each admin password. More than two names per system means the queue is already leaking.
5. Test the bus factor. If the approver is offline tomorrow, what stops? If the answer is "everything", you have your mandate.

How do you fix the bottleneck without losing control?

Fix it in this order: inventory, roles, owners, delegation, time limits, audit. Inventory before roles because you cannot define roles for systems you forgot; roles before delegation because an owner cannot approve what is not defined. Each step is small and reversible; skipping one leaves the queue in a new place.

1. Inventory every system that can grant access. SaaS admin panels, cloud consoles — AWS IAM, Microsoft Entra ID, Google Cloud IAM — the GitHub organisation, server sudoers, database users, hosting and DNS panels. For each, note the blast radius: how much damage a wrong or stolen grant can do. A read-only dashboard is not the same class as billing or production data.
2. Write least-privilege roles per system. Least privilege means each role gets the minimum rights the work needs, nothing more. Three or four roles per system is usually enough: viewer, operator, admin. On AWS that means a policy scoped to named resources — test it in the IAM policy simulator before you attach it to anyone:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::reports-bucket", "arn:aws:s3:::reports-bucket/*"]
  }]
}

3. Name one owner per system — the person who feels it first when the system breaks, not whoever currently holds the password. The owner approves within the defined roles only. AWS's own least-privilege guidance is the reference here.
4. Delegate the granting. In Microsoft Entra ID, Google Workspace or your cloud IAM, roles become groups; owners approve joins without ever seeing a password — Microsoft documents its RBAC model on Microsoft Learn. Retire shared credentials as you go, and switch on multi-factor authentication for every admin path before you tighten anything else, or a mis-scoped role locks someone out with no recovery path.
5. Put expiry on elevated access. Temporary admin gets an end date — a group membership with a removal date in the calendar, or a just-in-time grant where the tool supports one. No standing admin, including yours.
6. Open self-service for the low-risk tier. Read-only report access becomes a group a manager can join without an approver. This alone clears most lookup traffic off the queue.
7. Seal a break-glass account — one emergency admin login, credentials in a vault or sealed envelope, opened only when everything else fails, then reviewed and re-sealed. Tie a monthly audit to it: reconcile actual group members against the role map and log the exceptions.

Which fix applies to which request type?

Match the remedy to the request, not to the loudest requester. Read-only lookups belong in self-service groups a manager can join; new starters take a role template; elevated access gets a time limit; emergencies use a sealed account; offboarding runs from the leaver checklist. One queue was never the right shape for these five cases.

How do you verify the delegated model works?

Verify with measures, not opinions. Track median request age weekly — a healthy tiered setup answers most requests within a day. Sample ten grants each month against the role definitions, run one break-glass drill per quarter, and offboard a test account end to end. If the numbers slip, the queue moved somewhere.

None of this needs new tooling. The tracker you already use records request age; the grant log you switched on in step eight feeds the monthly sample. If you would rather not carry the owner role for hosted systems at all, that is a normal part of our website maintenance service — defined roles, answered requests, your accounts.

What breaks first after you delegate access?

Three failures recur. Role sprawl: owners invent new roles until the map is unreadable — cap roles per system at a handful. Stale grants: expiry dates get quietly extended — reconcile actual members against the role list monthly. Approver queues reform around a new owner: watch request age per system, not company-wide.

Debug in that order. Rising request age on one system points at an overloaded or absent owner before it points at process. A grant log that shows approvals outside the defined roles means the owner is improvising — narrow their rights, do not add a rule. And a break-glass use with no follow-up note is either a real incident you did not hear about or someone treating the sealed envelope as a spare key. Both deserve a conversation the same week.

Which security checks must survive the handover?

Delegation moves approvals; it must not weaken the audit trail. Every grant needs a recorded requester and approver, multi-factor authentication on all admin paths, and separation of duties — the person who requests access never approves their own request. Emergency accounts stay sealed, logged, and reviewed after every use.

Separation of duties is the check teams drop first, usually under deadline pressure. Hold the line. If you also hold credentials on client systems, the same trail applies on their side of the fence — we set out our own approach in the guide to client access permissions.

What mistakes do teams repeat here?

The repeated mistakes are predictable. Teams buy a tool before writing the role map, delegate approvals while shared passwords survive in a spreadsheet, hand owners standing admin instead of scoped rights, and skip the audit step because nothing has broken yet. Each one reintroduces the same single point of failure under a new name.

• Buying access-management tooling before the role map exists — you automate the queue, not the decisions.
• Delegating approvals while shared logins remain in chat threads and password spreadsheets.
• Giving system owners permanent admin rather than the right to grant three defined roles.
• Treating the fix as a one-off project instead of a monthly habit of reconciliation.
• Forgetting the approver's own access — who reviews the reviewer?

A realistic scenario: forty staff, fourteen systems, one ops manager

Picture a forty-person distribution company where one operations manager holds admin rights to fourteen systems. Requests average three days; password sharing is common; nobody else can offboard a leaver. Six weeks after writing the role map and naming owners, routine requests are self-served and the manager approves only exceptions.

Week one and two: the team lists the systems and finds nine with shared admin passwords — the diagnosis writes itself. Weeks three and four: three roles per system, owners named — the warehouse supervisor owns the inventory tool, finance owns billing. The manager keeps only the exceptions: break-glass, billing changes, and the monthly reconciliation. Median wait for lookups drops from three days to minutes. The honest cost is two afternoons a week of the manager's time for a month, plus one noisy week when the warehouse owner over-approves and the audit catches it — which is the system working, not failing.

What are the alternatives compared?

Compare four options before building anything: keep one approver, add a shared service inbox, use identity-provider groups with named system owners, or adopt dedicated access-management tooling. Cost rises down that list; so does operational overhead. Most teams need the third option and not the fourth — confirm any licence figure with the vendor's own calculator.

Approach	How it works	Where it breaks	Fits when
One central approver	Every request goes to a single admin who knows the systems	Latency grows with headcount; offboarding depends on one memory	Fewer than ten staff and a handful of systems
Shared service inbox	Requests land in a monitored mailbox or helpdesk queue	Faster routing, but grants still happen ad hoc and drift	You need triage while the role map is being written
IdP groups with owners	Roles are groups in Entra ID, Google Workspace or cloud IAM; system owners approve joins	Needs the role map kept current; owners can over-approve under pressure	Most teams past ten staff — the default we recommend
Dedicated PAM tooling	Privileged access management with vaulting, session recording, just-in-time grants	Licence cost, integration effort, another system to operate	Regulated environments or large standing admin populations

In short

The access request bottleneck is a role-model problem wearing an inbox costume. Inventory systems, define least-privilege roles, hand approval to named owners, put expiry on elevated access and keep the audit trail. Do it in that order and the queue disappears without loosening control.

People also search for

• How do you offboard a leaver's access across every system?
• What should a website access audit cover?
• Who should hold client site and hosting credentials?
• How do we restrict access to patient records properly?
• When should a partner get API access to our system?
• How do we keep our data when cancelling a SaaS tool?
• What happens when system knowledge lives with one person?

If the queue has outgrown the person holding it, our team can review what exists, write the role map with you and set up delegated, time-bound access in accounts you own — alongside the web, mobile, hosting and other services we already run for clients. Tell us what is piling up and we will start with a review, not a pitch.