Most SaaS access problems do not start with someone asking for “global admin”.
They start with a reasonable request.
A revenue operations lead needs to fix routing rules. A support manager needs to export a queue. A finance analyst needs to change an approval workflow. A customer success director needs visibility into account data. The vendor role model offers a few choices: viewer, user, manager, power user, admin.
So someone grants power user.
It sounds limited. It sounds business friendly. It sounds safer than admin. Six months later, that role can change sharing rules, create automations, export sensitive data, modify integrations, invite users, or alter records that feed downstream systems.
Nobody meant to create a control gap. They just used the least bad button available.
The role name is not the control
A lot of SaaS governance still treats role names as if they explain risk.
Admin sounds dangerous. Viewer sounds safe. Manager sounds reasonable. Power user sounds like a compromise.
That is backwards. The name is marketing language or product shorthand. The control is what the role can actually do.
Can it change who has access? Can it export regulated data? Can it install marketplace apps? Can it alter retention, logging, routing, billing, records, templates, workflows, or integrations? Can it approve something that changes financial, legal, customer, or security outcomes?
Those actions matter more than the label.
The trap is that SaaS vendors often bundle permissions around product convenience, not your control model. That is understandable. Vendors need roles that work for a wide customer base. Your organization needs roles that match accountable decisions inside your operating model. Those are not the same design problem.
Why broad roles keep spreading
Broad SaaS roles spread because they solve friction quickly.
Someone cannot complete a task. The business is blocked. Security does not want to become the help desk for every permission request. The application owner has limited time. The vendor’s custom role builder is awkward or only available on a higher plan. The audit team wants quarterly evidence, not a permissions engineering project.
So the organization makes a local tradeoff: grant broader access now, clean it up later.
The cleanup rarely arrives.
By the next review, the user still has the role. Their manager approves it because removing access might break work. The application owner does not want to reverse engineer every permission. Security sees a role name that looks plausible. Everyone moves on.
That is how “temporary power user” becomes the permanent layer between normal users and true admins.
This is why a quarterly certification alone is a weak answer. If the reviewer sees only role names, they are approving vocabulary, not access. The same pattern shows up in broader SaaS access governance, where quarterly certification misses the real risk because the review does not expose what the access can actually change.
Separate tasks from decisions
The useful design move is to separate tasks from decisions.
A task is operational: update a field, correct a record, rerun a workflow, view a dashboard, assign a case.
A decision changes the risk posture: add users, approve exports, change retention, install integrations, alter logging, modify sharing defaults, create automation that moves data, or change rules that affect customers.
Many SaaS roles combine both. That is the problem.
The person who needs to fix a customer record does not automatically need to change global sharing. The analyst who needs reporting access does not automatically need bulk export rights. The manager who needs to approve a workflow exception does not automatically need to edit the workflow itself. The team lead who needs to reassign tickets does not automatically need to invite external users.
If your role model cannot separate those actions, do not pretend the role is low risk.
Name the tradeoff: either accept broader access for operational speed, or invest in narrower roles, compensating approvals, monitoring, and periodic cleanup. Both choices can be rational. The mistake is granting the broad role while documenting it as if nothing meaningful changed.
Custom roles are not free control
Custom roles sound like the obvious answer. Sometimes they are.
They also create their own mess.
Too many custom roles become unreadable. Nobody knows why “Ops Manager 2 Limited Export No Billing” exists. Permissions change when the vendor updates the product. New features arrive with default access nobody reviewed. Old roles survive after teams reorganize. A custom role can be more precise on day one and more confusing by month nine.
Precision without ownership turns into another form of drift.
That connects directly to the SaaS configuration problem. Admin settings, role permissions, app integrations, and workflow rules all change the security posture. If those changes happen outside change control, you are relying on memory and goodwill. As noted in SaaS Configuration Drift Needs Change Control, Not Hope, the issue is not whether a setting looks small. It is whether the organization knows who can change it, why it changed, and how to detect when it drifts.
What good SaaS role governance looks like
Start with the actions that create risk, not the roles the vendor gives you.
For each important SaaS platform, identify the small set of actions that should never be casually bundled:
- User and role administration
- External sharing and guest access
- Bulk export and API access
- Marketplace app and integration approval
- Retention, deletion, and logging settings
- Workflow automation that moves or transforms data
- Financial, legal, customer, or security approval rules
- System configuration that affects downstream systems
Then map who can perform those actions today. Not who should. Who actually can.
That exercise usually produces a better conversation than “who has admin?” It shows where power user is effectively admin for the decisions that matter. It also shows where business teams need legitimate operational access that security should not block.
From there, define a few role patterns:
- Operational roles for routine work
- Elevated roles for sensitive actions
- Time limited access for exceptional tasks
- Separate approval for configuration or data movement changes
- Named owners for each privileged role
- Monitoring for the actions that would hurt if misused
Do not overbuild it. A giant entitlement taxonomy nobody maintains is just expensive theater. The goal is a role model people can understand, operate, and defend.
The review question changes
The access review question should not be “does this person still need power user?”
That question invites rubber stamping.
Ask better questions:
What decisions can this role make? What sensitive actions can it perform? Which of those actions has the person used? Which actions are needed for the job? Which should require separate approval? Who owns the risk if the access is misused? What breaks if the role is removed or narrowed?
Those questions turn access review into governance instead of admin cleanup.
They also expose where SaaS roles are being used to compensate for weak process design. If ten people need broad access because one workflow is brittle, the answer may be workflow redesign, not another role review.
The quiet risk is convenience
SaaS admin role governance is not about making every permission tiny.
It is about refusing to let convenience become invisible authority.
Broad roles are sometimes necessary. Small teams, immature vendor role models, urgent operational workflows, and limited platform features all create real constraints. Security leaders should be honest about those constraints. But they should also be honest about the decision being made.
When power user can change the outcome, it is not a harmless middle ground. It is a privileged role with better branding.
If your organization needs help turning SaaS access from role-name reviews into decision-based governance, Zero Drama Security services can help define a practical operating model without turning every permission into a committee.
The point is not perfect least privilege. The point is knowing where authority lives before the wrong person, workflow, integration, or setting quietly uses it.