Operational drag

What Operational Drag Looks Like in Identity and Access Work

Operational drag is not a single failure, but the cumulative friction that appears when decisions, approvals, and control changes depend on manual handoffs. In identity and access programmes, that friction is often visible as slow provisioning, delayed access revocation, repeated ticket queues, and governance steps that add little assurance while consuming time.

It usually emerges when a control process was designed for a smaller environment or a slower business cadence. As the number of systems, roles, and change requests grows, the business still needs quick access decisions, but the operating model forces every change through the same human-heavy path.

Why Operational Drag Matters

Operational drag matters because it changes how security controls behave in practice. A policy may be sound on paper, yet if every routine change requires multiple approvals or engineering intervention, teams start bypassing the process, deferring updates, or accepting temporary exceptions that become permanent.

The result is a governance gap: the organisation believes it has control, but the control cannot keep up with demand. That gap can undermine least-privilege efforts, slow remediation after role changes, and increase the chance that outdated access remains in place longer than intended.

Common Sources of Operational Drag

The biggest contributors are usually process design and ownership ambiguity rather than technology alone. Common causes include too many approval layers, unclear decision rights, manual reconciliation between systems, and controls that require specialist intervention for simple, low-risk changes.

Another source is inconsistent policy granularity. If rules are so coarse that every access change looks exceptional, teams cannot automate safely. If they are so rigid that they ignore business context, staff create workarounds outside the intended control path.

• Manual tickets for routine access moves, adds, and removals.
• Repeated cross-team sign-off for low-risk, pre-approved changes.
• Disconnected systems that force duplicate updates and reconciliation.
• Governance checks that create delay without improving decision quality.

How Organisations Reduce It Without Weakening Control

The practical goal is to remove avoidable friction while preserving the assurance the control is meant to deliver. That means tightening decision criteria, standardising routine changes, and moving low-risk actions onto repeatable workflows where the policy is already clear.

In access and governance programmes, that often means designing for exceptions instead of treating every request as exceptional. It also means clarifying which decisions truly need human review and which can be handled through predefined rules, delegated authority, or automated enforcement. For a control-oriented view of that trade-off, NIST Cybersecurity Framework 2.0 is useful because it ties governance to repeatable operational outcomes.

Where identity and access operations are tightly coupled to business change, organisations also need controls that limit the time people spend waiting for access to be granted or removed. A control catalogue such as NIST SP 800-53 Rev 5 Security and Privacy Controls helps map that need to access control, auditability, and configuration discipline.

Risk and Threat Considerations

Operational drag creates risk because slow controls invite either business bypass or security delay. When routine changes are painful, teams are more likely to postpone revocation, reuse broad access, or rely on standing exceptions, which creates avoidable exposure across identity and access paths.

Failure mechanism: Excessive manual handling turns a governance process into a bottleneck, so the organisation responds by bypassing, deferring, or over-generalising access decisions.

Impact: Access can remain broader or longer-lived than intended, remediation slows, and the control loses credibility because people stop trusting it to keep pace with the business.

Practitioner Guidance

Governance implication: Treat operational drag as a control-design problem, not just a workflow inconvenience. If a routine change needs repeated human escalation, the process is probably carrying more decision weight than the risk justifies.

What to watch for: Repeated exceptions, long ticket ageing, and “temporary” manual steps that never get removed are strong signs that the programme is accumulating friction instead of reducing it. The best fixes usually come from simplifying decision rules, not from adding another approval layer.

Related resources from NHI Mgmt Group

• How should teams reduce operational drag in legacy loyalty platforms?
• Why do legacy SIEM pipelines create so much operational drag?
• How do you know if a DSPM platform is creating operational drag?
• Why do false positives create so much operational drag?