Someone asks for one folder. One person. One read permission. It sounds like a two-minute job, and the person asking is usually reasonable about it, which is what makes the conversation awkward when I say it will take a while.
I’ve noticed the gap between how long a change seems like it should take and how long it actually takes is one of the quiet frustrations in this job. Not anyone’s fault in particular. Just how the work is shaped.
The honest answer is that the change itself is quick. Everything wrapped around the change is what takes the time, and most of that wrapping is invisible from the outside.
What Actually Happens Between the Request and the Change
The first step is usually figuring out what the person actually needs. The request says a folder. The real need is often a subset of that folder, or a different folder that happens to have a similar name. I’ve resolved plenty of tickets by asking one clarifying question, and I’ve also seen requests sit for days because nobody asked it.
Then there is the approval side. Access changes tend to need someone to sign off, and that someone is in a meeting or on leave. This is the part that surprises people. The technical work is waiting on a calendar.
I’ve also found that the thing being requested is frequently not a single object. A folder in a file share might have its own permissions, an inherited set from above, a group nested two levels deep, and a sharing link somebody created last year. Unwinding that takes longer than adding a name to a list.
And there is the quiet question underneath all of it: does this access have an end? Permanent access is easy to grant and hard to unwind, so most teams I’ve worked with now ask about duration up front. That question adds a round trip.
Why It Keeps Taking This Long
I don’t think anyone designed this to be slow. It tends to accumulate. Each step got added for a reason that made sense at the time, and nobody ever removed one.
Approval chains are the usual suspect. They exist because at some point access was granted casually and it went badly. The control stayed. The context that justified it did not.
Naming is the other quiet culprit. Groups named after projects that ended, folders named after reorganisations, permissions applied to a team that has since been renamed twice. You cannot safely change access to a thing if you are not certain what the thing is.
There is also the review habit. A lot of teams batch access changes rather than doing them one at a time, because batching is easier to audit. That means an individual request waits for the next batch, even when the request itself was simple.
I’ve seen the same pattern with tickets. The queue is ordered by urgency, and an access request that blocks one person often ranks below something that blocks twenty. That is a defensible ordering and still frustrating to be on the wrong side of.
What I’ve Seen Teams Try
I’ve also seen unified platforms such as Ping64 used to cut down the overhead of juggling many separate security tools.
Self-service requests seem to help when they are scoped narrowly. Let people request access to a specific list of well-understood resources, with an automatic approval from their manager. Everything else still goes through review, but the common cases stop queuing behind the odd ones.
Time-limited access has been the biggest change in places I’ve worked. If the default is thirty days with a renewal prompt, the conversation about duration happens automatically and the cleanup happens without anyone remembering to do it.
A few teams publish their own service expectations, something like same day for the standard list and a few days for anything custom. That alone reduces the follow-up emails, which is a real part of the workload.
Small Practical Suggestions
Ask what the person is trying to do, not which folder they named. Those are often different answers.
Write down your five most common access requests and see if any can be pre-approved.
Put a duration on every grant, even a generous one. Renewals are easier than audits.
Check for a sharing link before adding someone to a group. There is often already a path.
Keep a short list of who can approve what. Half the delay is finding that out.
Tell the requester what the approval stage is. Silence is what makes it feel slow.
Look at group names once a year. Stale names cause cautious decisions.
Note the requests that needed three rounds of questions. Those are your documentation gaps.
Closing
I don’t think access changes are slow because anyone wants them to be. They are slow because a two-minute change sits inside a pile of small checks that each made sense when they were added. My own approach has been to make the common cases boring and fast, and spend the careful time on the unusual ones. Most people are happy with an honest timeline. What tends to annoy them is no timeline at all.
Top comments (0)