What breaks when ServiceNow approvals are used as the control instead of the policy engine?

Approvals can document intent, but they do not by themselves enforce least privilege, lifecycle ownership, or separation of duties. If the ticket system is treated as the authority, access changes may be approved without consistent entitlement rules, and audit evidence becomes a record of process rather than a record of control.

When approvals become the control, what stops being enforced?

Once a ticket approval is treated as the control, the organisation starts confusing permission to proceed with actual enforcement. The approval can show that someone reviewed a request, but it does not itself constrain who may receive access, for how long, or under what entitlement rule. The policy engine is the layer that decides whether the requested access is allowed.

This distinction matters because approvals are descriptive while policy is prescriptive. A request can be approved for business reasons and still violate least privilege, exceed role scope, bypass ownership constraints, or create a conflict with separation of duties. The control fails when the workflow evidence is mistaken for the access decision.

What fails in lifecycle, ownership, and auditability?

Using approvals as the primary control weakens identity lifecycle governance. Access can be granted without consistent checks on entitlement state, expiry, revocation, or who owns the target application and data. That makes access changes harder to reason about across joiner, mover, and leaver events, especially when the same approval path is reused for different systems and privilege levels.

It also degrades audit quality. An audit trail that only proves a ticket was approved does not prove that the resulting access was policy-compliant, time-bounded, or reviewed against current entitlement rules. The evidence becomes a record of human process rather than a record of control behaviour, which is much weaker when reviewers want to test whether the control actually prevented overgranting.

Why policy engines are the real enforcement point

A policy engine turns access intent into a repeatable decision based on attributes, roles, context, and exceptions. It can block requests that approvals might otherwise allow, including requests that conflict with least privilege or violate a separation-of-duties rule. For a practitioner view of how policy-based authorization differs from approval-centric access handling, see the Authorisation Models Guide.

That distinction is especially important in environments where access must be consistent across humans, workloads, and delegated automation. Policy can encode the rule once and apply it every time; approvals have to be interpreted case by case. If the approval path is the only gate, every exception becomes a manual judgment call, and the organisation loses the ability to prove that similar requests were treated consistently.

Risk and Threat Considerations

The main risk is control inversion: a process artifact is treated as the authority, so excessive access can slip through with a valid-looking approval. That creates exposure even when the workflow appears well governed, because the real safeguard, policy enforcement, is no longer deciding the outcome.

Failure mechanism: The approval system records consent or business intent, but the entitlement engine is bypassed or reduced to a downstream formality, allowing access that exceeds policy, persists too long, or breaks separation of duties.

Impact: Overprivilege, unauthorized access paths, and weak audit evidence become more likely, and revocation or recertification issues can persist until the next manual review.

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-6 — Least Privilege	Approvals vs policy control directly affects whether access stays least-privilege.
	AC-5 — Separation of Duties	Approval-only workflows can permit conflicting access that SoD policy should block.
	AU-2 — Event Logging	Audit evidence here depends on recording the actual access decision, not just the approval.
Recommendation — Enforce least privilege in policy, not in ticket approvals. Block SoD conflicts with policy checks before provisioning. Log the enforcement decision and resulting entitlement change.
ISO/IEC 27001:2022	A.5.15 — Access control	The subject is about access control authority versus workflow approval evidence.
Recommendation — Define access rights in policy and enforce them consistently.
CIS Controls v8	CIS-5 — Account Management	Approval-only control weakens lifecycle governance over account and entitlement changes.
Recommendation — Tie access changes to managed account and entitlement processes.

Practitioner Guidance

What to verify: Check whether the approval step is only advisory or whether a policy decision actually gates provisioning. If an approval can succeed while the policy engine would have denied the request, the process is compensating for weak control rather than implementing control.

Common mistake: Treating ticket closure, manager sign-off, or CAB approval as proof that access was correctly granted. That shortcut usually hides entitlement drift, missing ownership checks, and exceptions that never get translated into enforceable policy.

Decision rule: If the access decision changes based on the environment, role, target system, or duration, encode that rule in policy and use approval only to capture exception context or business justification.

Practitioner takeaway: Approvals can support governance, but they should not be the mechanism that authorizes access; the control boundary belongs in policy, where it can be enforced consistently and audited as an actual decision.