What is an example of Policy Friction in practice?

An example of policy friction is a control that is technically sound but operationally awkward, so people route around it. The practical failure mode is not the policy text itself, but the gap between the control’s intent and how work actually gets done.

One common pattern is routine access that requires repeated approvals or manual exceptions every time, even when the request is low risk and recurring. That kind of process often produces shadow approval chains, informal sign-offs, or shared credentials, because staff optimise for getting work done rather than following a slow path.

Policy friction usually shows up where the policy is applied too broadly or without enough risk-based tailoring. If the same approval burden is used for low-impact access and high-impact access, users learn that the easiest route is to bypass the control, not comply with it. The control then creates noise instead of assurance.

Risk and Threat Considerations

High-friction policy increases the chance that people create shadow processes, reuse existing access, or delay security steps until after the business need has already driven a workaround. That weakens visibility and makes it harder to tell whether access was properly reviewed, approved, and limited.

Failure mechanism: The control becomes slower or more obstructive than the work it is meant to govern, so users seek informal exceptions, bypasses, or alternative channels that sit outside the intended policy path.

Impact: Over time, the organisation gets weaker assurance, less consistent enforcement, and more exposure from uncontrolled access paths that were never meant to become standard practice.

Why Policy Friction Usually Starts Small

Policy friction often begins with a control that seems reasonable in isolation: extra approvals, mandatory reviews, or repeated revalidation. The issue appears when those steps become routine for low-risk activity, or when the process takes longer than the task it governs. At that point, the policy no longer feels like a guardrail, it feels like a blocker.

The strongest sign is not open defiance, but adaptation. Teams start asking for the same exception repeatedly, copying approvals from previous requests, or building side channels to keep operations moving. Those behaviours are a signal that the policy design no longer matches the operating reality.

What Makes a Control Create Friction Instead of Assurance

Policy friction is usually caused by a mismatch in one of three places: the risk level, the frequency of the activity, or the ownership model. A control that is acceptable for rare, sensitive actions may be counterproductive when applied to routine, low-risk work. Likewise, a process that depends on a central approver for every request will often break down once usage scales.

It is also common for policy to become stale after the environment changes. New systems, faster delivery cycles, and more delegated work can make an old approval model feel disconnected from how teams now operate. When that happens, users stop seeing the policy as meaningful risk management and start seeing it as delay.

For a practical policy template that distinguishes roles, exceptions, and review cadence, see the Information Security Policy Template. It is useful where the question is not whether a policy exists, but whether it is written so people can actually follow it.

Practitioner Guidance

What to verify: Look for repeated exceptions, delayed fulfilment, and the same request being handled through informal channels more than once. If the workaround is becoming the default route, the policy has become operationally misaligned.

Decision rule: If a control is slowing routine, low-risk work, simplify it; if it is protecting high-impact access, keep the control but narrow the scope instead of removing it. The right fix is usually calibration, not blanket relaxation.

What practitioners underestimate: Users do not generally reject security because they dislike security, they reject controls that feel disproportionate to the task. The best policies reduce the need for judgement at the point of use, while still preserving meaningful review where the risk is real.

Practitioner takeaway: Policy friction is a design problem as much as a governance problem, and the clearest sign of failure is when the organisation’s unofficial process becomes more trusted than the official one.

Related resources from NHI Mgmt Group

• What is an example of Fine-grained password policy in practice?
• When does MFA policy fail in practice?
• How do you know if access controls are too friction-heavy to work in practice?
• How should security teams implement AI policy templates in practice?