What should teams do before using self-service for access requests?

What should be defined before self-service becomes the request path?

Teams should treat self-service as the delivery layer, not the policy engine. Before users can submit or route requests automatically, the organisation needs a clear decision model for which request types are allowed, which ones are conditional, and which ones stay manual because they carry higher privilege, separation-of-duties, or business-impact risk.

That definition belongs in the access model, not in the portal. If the workflow is not bounded first, self-service simply scales inconsistent approvals, ambiguous ownership, and exceptions that are hard to audit later.

Who needs to own approval and validation rules?

Each application should have an identified approver or approver group that is responsible for access decisions, and that ownership should be explicit enough for routing to be deterministic. The point is not just to send tickets somewhere faster, but to ensure the right person can approve, reject, or escalate based on the application’s sensitivity and the requester’s role.

Validation rules should also be defined before launch. For example, some entitlements may be safe for workflow automation, while others should trigger extra review because they affect production data, privileged functions, regulated workflows, or broad inherited access. A self-service request is only as reliable as the policy behind it.

How should teams decide what is safe to automate?

Use the request design to separate low-risk, repeatable access from requests that need human judgement. Routine joins, standard roles, and narrowly scoped entitlements are usually the best self-service candidates; unusual combinations, elevated privileges, shared access, and access that can bypass controls should be handled more cautiously.

Good practice is to require the workflow to check entitlement scope, requester context, and approval path before the request is accepted. That keeps the portal from becoming a bypass around governance and prevents users from learning that the fastest path is also the least controlled.

Risk and Threat Considerations

Self-service request flows increase the speed of access, but they also increase the speed of bad decisions when the routing logic is weak. The main risk is not the portal itself, it is that uncontrolled request types, missing ownership, or poorly validated entitlement rules can turn convenience into access sprawl and approval drift.

Failure mechanism: If request eligibility, approver ownership, and entitlement sensitivity are not defined up front, the workflow can approve access that should have been reviewed manually, route decisions to the wrong owner, or create exceptions that are hard to detect and recertify.

Impact: Teams can end up granting excessive access, weakening segregation of duties, and creating audit gaps where no one can show why a particular entitlement was approved or who was accountable for the decision.

Practitioner Guidance

What to prioritise: Start with the access catalogue and approval matrix, not the portal implementation. If a request cannot be mapped cleanly to an owner, an approval rule, and a review threshold, it is not ready for self-service.

What to verify: Confirm that each application has a named approver, that each request type has an allowed path, and that high-risk entitlements are forced into exception handling rather than normal fulfilment.

Practitioner takeaway: Self-service works when it automates a governed decision, not when it invents one; the control point is the policy definition that sits before the request reaches users.

Related resources from NHI Mgmt Group

• How should security teams design self-service access requests without losing accountability?
• What do teams get wrong about contractor self-service access requests?
• How should teams balance self-service access requests with approval controls in identity governance?
• What should teams do when self-service access requests still leave gaps?