Organisations should treat approval and fulfillment as separate control stages. The workflow needs a defined expected access state, a clear execution path, and a final verification step against the target system. Whether fulfillment is direct, ITSM driven, or manual, the process should preserve ownership, timestamps, and evidence from request to verified closure.
Designing Request Paths So Approval and Fulfillment Stay Linked
The main design problem is not getting a ticket approved, but ensuring the approved entitlement is actually applied in the target system. That means the workflow should carry a single request through defined states: requested, approved, fulfilled, and verified. The handoff between request governance and system execution needs to be explicit, because that is where access drift and missed changes usually appear.
A practical workflow starts with an access model that the approver can understand and the target application can enforce. If the approval outcome is vague, the fulfiller has to interpret intent, which creates rework and inconsistent access. The request should therefore describe the exact entitlement, scope, duration if relevant, and any conditions needed for closure.
Fulfillment should be treated as a controlled execution step, not an administrative afterthought. Whether the change is delivered through an identity platform, ITSM integration, or manual administration, the workflow should preserve the chain from approval to execution and record who did what, when, and in which system. That record is what lets teams prove the approved change reached the right place.
What Makes Fulfillment Reliable in Real Operations
Reliability comes from removing ambiguity between the approval object and the target object. The approved item should map to a known application role, group, entitlement, or account action, rather than to a free-text instruction. Where the request system and target system do not share a direct integration, the process needs a documented translation step so the fulfiller does not improvise the access change.
The final verification step is what separates an access request workflow from a paper approval process. The workflow should confirm the target state in the application itself, not merely assume success because a task was closed. For higher-risk access, the verifier should confirm both the presence of the granted access and the absence of unintended access that may have been left behind.
Timing also matters. If approval and fulfilment are separated by long delays, stale approvals become more likely and the business context may change before the access is actually applied. Strong workflows therefore use expiry, revalidation, or closure rules so a request cannot sit approved indefinitely without a completed execution path.
Why Ownership, Evidence, and Closure Criteria Matter
Access request workflows fail when ownership is unclear. The request owner, approver, fulfiller, and verifier may be different people or teams, but one function must remain accountable for completion. Without that accountability, tickets get closed on intent rather than outcome, especially when multiple systems or departments are involved.
Evidence should travel with the request. Timestamps, execution notes, target-system confirmation, and any exception handling should be retained as part of the request history. This is not just audit detail, it is the operational proof that the workflow controlled the change from decision to verified effect.
Closure criteria should be written as observable conditions, not as administrative convenience. If the target application cannot confirm the change automatically, the workflow should require human verification before closure. If confirmation is available, the workflow should make that signal the closure gate instead of relying on a status update in the request system alone.
Risk and Threat Considerations
When approval and fulfillment are loosely coupled, the main risk is false completion, where a request appears satisfied in the service desk but no real access change occurred in the application. That creates security exposure, audit gaps, and business disruption because downstream work assumes the entitlement exists when it does not.
Failure mechanism: Broken handoffs, ambiguous entitlement mapping, or unverified manual execution can leave approved requests partially implemented, incorrectly scoped, or never applied at all.
Impact: The organisation may grant the wrong access, fail to grant required access, or lose the ability to prove that approval translated into actual control in the target system.
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 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-2 — Account Management | Access request workflows are account and entitlement changes that must be approved, fulfilled, and verified. |
| IA-5 — Authenticator Management | Workflow closure depends on controlled issuance, change, or revocation of access-bearing credentials. | |
| Recommendation — Define approval, fulfillment, and verification steps for account changes and retain closure evidence. Track credential changes through request, execution, and verification states before closing the request. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The workflow must enforce approved access decisions and confirm they reach the target application. |
| A.5.16 — Identity management | Request fulfillment depends on correct identity and entitlement assignment in the target system. | |
| Recommendation — Document access approval and fulfillment checks so the target state matches the approved request. Tie each request to a managed identity and verify the resulting entitlement in the application. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and entitlement workflows need controlled provisioning, tracking, and closure evidence. |
| Recommendation — Implement request-to-fulfillment tracking with validated closure for every access change. | ||
Practitioner Guidance
What to verify: Make the target application the source of truth for closure, not the ticket status. If the workflow cannot show the entitlement in the system of record, the request is not truly complete.
Decision rule: For any request that changes privileged, shared, or business-critical access, require a fulfillment confirmation step that is independent of the original approval record. Treat “approved” and “implemented” as different control states.
Practitioner takeaway: The workflow succeeds only when it can prove that a specific approved change was executed in the target system, by the right actor, with evidence that stands up after the ticket is closed.
Related resources from NHI Mgmt Group
- What happens when organisations grant privileged access in the cloud without risk-based approval workflows?
- Should organisations allow pull_request_target for automated dependency workflows?
- How do organisations know whether access removal workflows are actually working?
- How should teams design IGA workflows so access reviews actually lead to removal?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
