Security teams should treat employees as part of the control environment, not as the problem to be constrained. The goal is to make secure behaviour easier than unsafe workarounds through usable controls, regular awareness training, simple reporting channels, and visible reinforcement from leadership. When controls are overly rigid, people create backdoors to do their jobs, which often increases risk instead of reducing it.
Why employee-related risk is really a control-design problem
Employee-related risk grows when security controls assume people will tolerate friction that helps the policy but hurts the job. In practice, the control environment should reduce unsafe improvisation by making the secure path the easiest path, with clear defaults, usable exceptions, and fast escalation when work genuinely needs an exception.
That means treating employees as part of the operating environment, not as a compliance problem to be punished. When a control is too rigid, teams route around it, and those workarounds are often less observable, less reviewable, and harder to reverse than the original risk.
What actually lowers risk without creating workarounds
The most effective controls are the ones people can follow under time pressure. Good security design usually combines simple training, clear reporting channels, right-sized access, and visible leadership reinforcement so the secure path feels normal rather than exceptional. The aim is not to remove judgement from employees, but to remove unnecessary obstacles that push them toward shadow processes.
Awareness training works best when it changes behaviour at the point of decision, not when it simply increases policy knowledge. Reporting paths should be short and trusted, because employees will disclose mistakes earlier when they do not expect blame or delay. Leadership matters because people measure the real policy by what managers reward, ignore, or work around.
Security teams should also look for the controls that break down most often in routine work, such as access requests, approvals, file sharing, password resets, device exceptions, and urgent customer or production support. Those are the places where people feel pressure to bypass process, so they are the places where simplification creates the greatest risk reduction.
How to distinguish healthy flexibility from dangerous exceptions
Not every workaround is malicious, and not every exception is a weakness. The key question is whether the exception remains visible, time-bound, and reviewable. A controlled exception can be a valid business decision; an informal bypass is usually a control failure, even if it is well intentioned.
Teams should be especially cautious when a process depends on repeated manual favours, shared credentials, informal approvals, or offline side channels. Those patterns often indicate that the official workflow is too slow or too opaque, and the resulting unofficial method may become the default operating model.
A practical way to test the design is to ask whether a tired, busy, non-specialist employee can still complete the task safely without discovering a hidden path around the control. If the answer is no, the control is probably trading security intent for operational friction, and that tradeoff will usually erode over time.
Risk and Threat Considerations
Rigid controls can create two kinds of exposure: accidental rule-breaking by employees trying to get work done, and deliberate abuse of the informal paths those controls encourage. Once a workaround becomes normal, it often has weaker logging, weaker review, and weaker ownership than the process it replaced.
Failure mechanism: employees adopt bypasses, shared access, informal approvals, or unsanctioned tools when the approved path is too slow, too complex, or too disruptive; that reduces visibility and increases the chance that misuse or compromise goes unnoticed.
Impact: the organisation gets the cost of the control without the protection of the control, and in some cases creates a larger attack surface than before because risky behaviour becomes embedded in everyday operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT-01 — Awareness and Training Policy and Topics | Employee behaviour and awareness are central to reducing unsafe workarounds. |
| GV.RR-03 — Roles, Responsibilities, and Authorities Are Established | Leadership reinforcement and clear ownership shape whether employees follow or bypass controls. | |
| PR.AA-01 — Identities and Credentials Are Issued, Managed, Verified, Revoked, and Audited | Workarounds often arise around access requests, approvals, and credential handling. | |
| Recommendation — Design role-based training that reinforces secure defaults and safe exception paths. Assign clear ownership for workflow exceptions and employee-risk decisions. Reduce manual access friction while keeping issuance, review, and revocation controlled. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least-privilege design limits damage when employees choose shortcuts or misuse access. |
| Recommendation — Minimise standing access and review exceptions that exceed job needs. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and access processes are a common source of employee-driven workarounds. |
| Recommendation — Streamline account processes so legitimate work does not depend on shadow access. | ||
Practitioner Guidance
What to prioritise: focus first on the controls that generate the most routine friction, not the controls that are easiest to justify on paper. If people repeatedly ask for exceptions to complete ordinary work, the design problem is likely in the process itself, not in employee discipline.
What to verify: check whether the secure path is actually faster than the workaround for common tasks, whether exceptions expire automatically, and whether managers can see when their teams rely on informal processes. If you cannot measure those conditions, you probably cannot govern them.
Common mistake: treating training as a substitute for usability. Training helps only when the workflow is already reasonable; when the workflow is hostile to the job, people remember the objective and ignore the procedure.
Practitioner takeaway: the best employee risk reduction strategy is not more control pressure, but better control design, because secure behaviour only scales when it is also the least painful way to get the work done.
Related resources from NHI Mgmt Group
- How should security teams govern employee use of public LLMs to reduce confidentiality risk without blocking useful AI work?
- How should security teams reduce OT remote access risk without blocking maintenance work?
- How should security teams reduce VPN risk without disrupting remote work?
- How should security teams integrate human risk signals into GRC programs without turning the process into a compliance-only exercise?