Separate the policy decision from the presentation layer. The organisation should define which elements are fixed by identity policy, which can be styled or routed locally and which require explicit security sign-off before they change.
Policy-Bound Identity Workflows Need a Clear Control Boundary
Customized workflows stay consistent when the policy logic lives in one place and the workflow only consumes the result. That means the workflow can change the look, routing, or user experience without being allowed to redefine entitlements, approvals, or who can bypass controls. The practical test is simple: if a change would alter access decisions, it is policy, not presentation.
When teams blur that boundary, they often end up encoding exceptions into forms, scripts, or ticket paths that were meant to be temporary. Over time, those exceptions become the real process, which makes policy drift hard to see and even harder to reverse.
Where Customisation Is Safe, and Where It Is Not
Safe customisation usually sits in fields, labels, routing, notifications, and local task ordering. Unsafe customisation starts when a workflow can approve itself, skip a control, or infer an exception without a policy decision that is visible and reviewable. The more a local team can alter the meaning of a step, the more that workflow becomes a control surface rather than a convenience layer.
A useful design rule is to separate fixed policy from local presentation with a narrow, documented interface. Local teams can adapt the experience for their process, but they should not be able to redefine required approvers, override conditions, or eligibility rules unless there is an explicit security review.
How to Keep Changes Governed Over Time
Consistency depends on versioning and ownership as much as on design. Policy changes should have a single owner, a change record, and a review path that makes it obvious when workflow behaviour is diverging from the baseline. That is especially important when multiple applications consume the same identity policy but present it differently.
Use a simple governance model: one authoritative policy source, one documented set of local extension points, and one approval route for exceptions. The moment a team needs a workaround outside those extension points, it should be treated as a policy exception, not a harmless workflow tweak. For broader identity governance patterns, the Identity Security Programme Guide and the NHI Lifecycle Management Guide show why lifecycle ownership and review discipline matter as workflows scale.
Risk and Threat Considerations
When policy and presentation are mixed, the main risk is silent drift, a local change can weaken approval logic without a visible policy update. That creates inconsistent access decisions, weak auditability, and a larger blast radius if a workflow is abused or misconfigured.
Failure mechanism: A custom workflow stores decision logic in scripts, fields, or routing rules that were intended only for presentation, so later edits bypass policy review.
Impact: Users or non-human identities may receive access they should not have, and investigators may be unable to prove which rule actually granted it.
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, OWASP ASVS and NIST CSF 2.0 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 | Custom workflow exceptions can expand access beyond intended need. |
| CM-3 — Configuration Change Control | Workflow changes need controlled review when they affect policy behaviour. | |
| Recommendation — Restrict workflow override paths to the minimum privileges required. Require formal approval before changing policy-bearing workflow logic. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Customised workflows must preserve controlled, approved configuration states. |
| Recommendation — Track workflow variants and approve policy-affecting configuration changes. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Separating policy from presentation is an architecture control issue. |
| Recommendation — Design workflows so policy decisions are enforced outside the UI layer. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | Identity workflows must preserve consistent authorization decisions. |
| Recommendation — Centralise access rules and prevent local workflow edits from changing them. | ||
Practitioner Guidance
What to verify: Check that every workflow step maps to either a fixed policy decision or a permitted local presentation change. If a local owner can alter approvers, thresholds, or exception handling, the design needs a control review before it goes live.
Decision rule: If a change affects eligibility, approval, or revocation, route it through the policy owner; if it only affects layout, sequencing, or notifications, local ownership is usually acceptable.
Practitioner takeaway: The safest customised workflow is one that can be rearranged without being able to change who gets access or why.