Why do risky security behaviors persist even when employees know the rules?

Why This Matters for Security Teams

Knowing the rule is not the same as being able, willing, or rewarded to follow it. In security operations, risky behavior usually appears when a control adds delay, ambiguity, or extra cognitive load to an already pressured workflow. That creates a gap between policy intent and day-to-day execution, which is where exceptions become habits and habits become exposure. The NIST Cybersecurity Framework 2.0 emphasizes governance and risk management because control design has to work in real operational conditions, not only on paper.

Practitioners often misread repeated policy violations as simple noncompliance, when the deeper issue is usually a system that makes the secure path harder than the unsafe one. If employees must choose between finishing a task and following a cumbersome approval flow, speed tends to win. The result is not just one-off deviation but a pattern of shadow work, such as unapproved file sharing, credential reuse, or bypassing ticketing controls. In practice, many security teams encounter the behavior only after an incident or audit finding has already exposed how normal the shortcut had become.

How It Works in Practice

Risky behavior persists because people adapt to incentives, friction, and repeated local experience. A user who is blocked by a slow access request, a confusing data classification rule, or a tool that fails to support legitimate work will often develop a workaround that feels reasonable in the moment. Over time, those workarounds become the real operating model unless security and business owners intervene.

Effective response starts with understanding where the workflow breaks down. The goal is not to “train harder” in the abstract, but to remove predictable causes of noncompliance. That usually means simplifying approvals, making secure tools faster than unsanctioned ones, and reducing the number of exceptions that employees must remember. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they translate governance into enforceable safeguards, but the implementation still has to fit the task flow.

• Map the exact step where users bypass the control, not just the policy that was ignored.
• Separate high-friction controls from high-risk activities so every task does not require the same burden.
• Use defaults that make the secure path the easiest path, including pre-approved templates and automated checks.
• Assign clear ownership for exceptions so temporary workarounds do not become permanent practice.
• Measure adoption, not just completion of training, because awareness does not guarantee behavior change.

Where identity and access are involved, the same pattern shows up with passwords, shared accounts, and over-broad entitlements: users take the path of least resistance when access processes do not match operational reality. The most reliable fixes are usually structural, not educational. These controls tend to break down in high-churn environments with frequent urgent requests because rapid task switching encourages reuse, shortcuts, and unreviewed exceptions.

Common Variations and Edge Cases

Tighter control often increases friction and support overhead, requiring organisations to balance risk reduction against productivity and operational tolerance. That tradeoff is real, especially in teams that handle urgent customer issues, incident response, or time-sensitive production changes. Current guidance suggests that the answer is rarely “more policy”; it is usually better workflow design, clearer thresholds for escalation, and better integration between business tools and security controls.

Some cases deserve different treatment. Contractors, shift workers, and frontline staff may not have the same access to training or support channels as office-based employees, so one-size-fits-all enforcement can backfire. In regulated environments, security teams may need to demonstrate that exceptions are controlled and auditable even when the workflow is simplified. The governance principle in NIST CSF remains useful here, but the specific control design should reflect the actual risk and the user population. In practice, that means distinguishing between unavoidable friction and self-inflicted friction, then removing the second without weakening the first.

There is no universal standard for this yet: some organisations use behavioral analytics and just-in-time prompts, while others rely on stricter approval gates. The better option depends on whether the main problem is lack of clarity, tool fatigue, or misaligned incentives. The NIST SP 800-53 Rev 5 Security and Privacy Controls can support either approach, but only if the control owner treats user behavior as an operational signal rather than a disciplinary issue.

Related resources from NHI Mgmt Group

• Why do passwords still persist even when organisations know they are risky?
• Why do identity security gaps persist even when organisations prioritise IAM?
• How do security teams know if an extension is risky in practice?
• Why do password-heavy environments remain risky even when users know better?