The better pattern is governed self-service for routine work and tighter approval control for high-risk actions. That keeps operational speed where the risk is low while preserving explicit oversight where standing privilege or sensitive change would otherwise expand exposure.
Why a Single Operating Model Rarely Fits All Identity Workflows
Identity workflows are not all equal. Routine, reversible tasks such as access requests, group membership changes, or profile updates can usually be handled through governed self-service. Changes that create standing privilege, widen blast radius, or alter trust boundaries need a tighter approval path because the operational convenience is outweighed by the security and audit consequences.
The practical distinction is risk, not organisational ideology. A central team can standardise policy, but if every request needs manual handling the queue becomes the control, and teams start bypassing it. Conversely, if every action is self-served, the workflow becomes fast but brittle, especially where entitlement creep, account recovery abuse, or privileged change can quickly expand exposure. The right model is usually a tiered one.
For mature identity programmes, this is why identity governance is often split between policy definition and execution. The policy should say which request types are pre-approved, which require step-up approval, and which must be blocked without exception. The execution layer should enforce those rules consistently, ideally with audit trails, role-aware routing, and clear ownership for exceptions.
Where Central Approval Adds Real Security Value
Central approval is most defensible when the request materially changes access risk. That includes privileged roles, production-impacting permissions, emergency elevation, cross-environment access, and changes that affect delegated administration or recovery controls. In these cases, the approver is not just signing off on a ticket, they are verifying that the request remains inside policy and that the business need matches the access being granted.
Central control also matters when the workflow is hard to reverse. If a mistaken approval can leave a standing privilege, an overbroad entitlement, or an exposed recovery path, the approval step becomes part of the control design. In that scenario, approval is not administrative drag, it is the compensating control that prevents routine workflow speed from turning into durable excess access.
That said, central approval should not be used as a proxy for good design. If the request is frequent and low-risk, forcing a human approver into the loop is usually a sign the entitlement model, role design, or policy automation has not been refined enough. Centralisation should be reserved for the decisions where judgement genuinely adds security value.
How to Use Self-Service Without Losing Control
Self-service works best when the workflow is bounded by policy and the outcome is reversible. A good governed self-service process uses predefined request types, least-privilege defaults, expiration where appropriate, and automatic logging. That allows users and teams to move quickly without giving them the ability to invent new privilege paths.
The key is that self-service should be a decision on execution, not a decision on authority. If users can request only within a constrained catalogue, and the platform automatically rejects anything outside policy, then self-service improves throughput without diluting governance. In practice, this is strongest for standardised access patterns, temporary needs, and low-impact administrative tasks.
One useful benchmark is whether the workflow can be reviewed after the fact without reconstructing intent from emails or chat threads. If the system can show what was requested, who approved it, what policy allowed it, and when it expires, self-service becomes auditable rather than informal. That is the difference between controlled automation and uncontrolled convenience.
Risk and Threat Considerations
When approval models are too centralised, teams often respond by bypassing the process, reusing privileged accounts, or granting broader access than needed just to avoid delays. When they are too decentralised, excess privilege, weak request validation, and over-permissive exceptions can accumulate until the workflow itself becomes an attack path.
Failure mechanism: The control fails when approval is either so strict that people route around it or so loose that policy stops constraining the entitlement being granted. In both cases, the organisation loses reliable control over who can obtain sensitive access and under what conditions.
Impact: The result can be privilege creep, poor auditability, slower incident response, and a larger blast radius if a request is abused or approved in error. At scale, a small design weakness in identity workflow governance can create recurring exposure across many roles and systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Identity workflows should limit access to only what each request needs. |
| IA-5 — Authenticator Management | Workflow approvals often govern credentials, resets, and other identity-bearing material. | |
| Recommendation — Constrain request outcomes to least privilege and require review for elevated access. Protect credential lifecycle changes with tighter controls and traceable handling. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | This subject is fundamentally about governing who gets access and how requests are authorised. |
| Recommendation — Define access rules that separate routine self-service from higher-risk approvals. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Identity workflows are a direct access-control concern and need governed request routing. |
| Recommendation — Route low-risk requests through policy automation and high-risk requests through explicit approval. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and entitlement changes are the core subject of the approval versus self-service choice. |
| Recommendation — Standardise account change requests and reserve manual approval for privileged actions. | ||
Practitioner Guidance
What to prioritise: Classify identity workflows by reversibility and privilege impact before you decide where approval should sit. Low-risk, standard requests should be pre-approved by policy, while high-risk changes should require explicit review and traceable justification.
Decision rule: If a request can create standing privilege, cross-environment reach, or recovery-path expansion, treat it as an approval-controlled action. If it is routine, bounded, and automatically expiring or revocable, make self-service the default and keep the control in the policy engine, not in a manual queue.
What good looks like: The organisation can show that routine access flows complete quickly, exceptions are rare and documented, and every sensitive grant is attributable to a specific policy and approver. The strongest signal is not whether approvals exist, but whether they are used where judgement matters and absent where automation is safer.
Practitioner takeaway: Centralise decisions that change risk, decentralise execution where policy can safely constrain it, and never let process convenience become the substitute for access design.
Related resources from NHI Mgmt Group
- How should security teams design self-service identity workflows without creating standing privilege?
- What should organisations verify before relying on self-service identity features?
- Why do self-service rental workflows need stronger identity proofing than traditional onboarding?
- Why do identity checks matter more in taxpayer and benefits workflows than in low-risk self-service journeys?