Access request to periodic review¶
Trigger¶
Someone needs access, changes role, or leaves.
Intended outcome¶
Access that is appropriate, evidenced, and removed when no longer needed.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Service Desk Analyst | records the request against a catalogue entitlement | request with entitlement and approval path | Entitlement and approval path defined for the request type |
| 2 | Data Owner | or application owner decides whether the purpose justifies access | access decision recorded with its purpose | Purpose-free access grants refused |
| 3 | Identity and Access Management Engineer | provisions through the identity platform | provisioned access, automated where integrated | Leaver revocation evidenced automatically, not attested |
| 4 | Privileged Access Management Administrator | vaults and monitors anything privileged | vaulted account with session monitoring | Break-glass tested on a schedule; every use reviewed |
| 5 | Identity Governance Specialist | certifies periodically that access is still appropriate | certification campaign results | Reviewers have actual knowledge of the access |
| 6 | Internal IT Auditor | tests the control independently | audit finding or assurance | Auditor never operated the control |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
access-request-to-reviewworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.