What do teams get wrong about balancing compliance and user friction?

Why This Matters for Security Teams

Compliance programmes often fail when they optimise for evidence collection instead of control effectiveness. Security teams can end up asking for more approvals, more identity proofing, and more manual checks than the workflow can tolerate, then quietly bypassing the same controls when delivery pressure rises. That creates a brittle system: auditability looks strong on paper, but the actual user path becomes unusable and exceptions become the real policy. The better question is whether the control is proportionate, repeatable, and defensible at runtime, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG guidance on regulatory and audit perspectives. In practice, many security teams encounter control bypass only after business users have already learned where the friction is highest, rather than through intentional policy design.

How It Works in Practice

Balanced compliance starts by separating the proof required for the risk from the paperwork attached to it. For higher-risk actions, teams should use targeted verification, contextual approval, and immutable logging. For lower-risk actions, current guidance suggests using lighter checks that still preserve audit evidence. The point is not to remove friction everywhere, but to move it to the moments where it adds security value. A practical design usually includes:

• Risk-tiered checks that vary by action, data sensitivity, and privilege level.
• Exception handling with expiry, owner approval, and review dates.
• Automated evidence capture so analysts do not manually reconstruct who approved what.
• Clear control mappings so compliance can be demonstrated without duplicating steps.

For NHI-heavy environments, the same logic applies to secrets, service accounts, and automation credentials. NHIMG’s Top 10 NHI Issues highlights how excessive privilege and weak lifecycle discipline often create more compliance risk than the original access request. The issue is not only whether access is approved, but whether it can be rotated, revoked, and reviewed without creating a manual bottleneck. That is why the most durable programmes pair policy with lifecycle controls from the Ultimate Guide to NHIs, so evidence is generated by the process itself rather than by after-the-fact screenshots or spreadsheets. In practice, these controls tend to break down when ownership is unclear across security, compliance, and platform teams because no one can change the workflow without creating a separate approval loop.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, requiring organisations to balance defensibility against speed and usability. That tradeoff becomes sharp in regulated environments, merger integrations, and developer platforms where access patterns change quickly. Best practice is evolving here: there is no universal standard for exactly how much friction is acceptable, only a growing expectation that the organisation can justify the tradeoff and show consistent enforcement. A few common edge cases matter:

• Emergency access needs a pre-approved break-glass path, not an improvised bypass.
• Customer-facing journeys may need step-up proofing only for sensitive changes, not every login.
• Third-party and delegated access often need different evidence than internal workforce access.
• Automated systems should log intent, decision, and revocation, but not force human-style attestations.

Teams also get this wrong by treating compliance as a one-time design choice rather than a living control set. The control that passes audit today can become unusable after a product change, a cloud migration, or a new partner integration. In that sense, the real failure is not “too much friction” or “too little compliance,” but a lack of maintenance on the workflow itself. Organisations that review control usage, exception volume, and abandonment rates together are usually better able to spot where the policy has drifted from the operational reality before users start routing around it.

Related resources from NHI Mgmt Group

• What do security and compliance teams get wrong about self-service transfer setup?
• What do security and compliance teams get wrong about Travel Rule controls?
• What do security and IAM teams get wrong about AI assistants in compliance?
• What do teams get wrong about point-in-time compliance checks?