How should security teams design controls that people will actually use?

Why This Matters for Security Teams

Controls fail when they are designed as policy statements instead of workable steps inside the real operational flow. If a control slows down incident response, breaks a help desk process, or forces extra logins at the wrong time, people will bypass it, delay it, or invent a shadow process. Good control design therefore starts with human behaviour, business context, and the actual risk path.

NIST guidance on control selection and implementation, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful here because it treats controls as something to be tailored, not copy-pasted. The practical question is not whether a control exists in a catalogue, but whether it can be applied without creating constant exceptions. In security programmes, adoption is often the deciding factor between a control that reduces risk and one that only creates audit evidence.

In practice, many security teams encounter control failure only after users have already built an unofficial workaround, rather than through intentional design of the workflow.

How It Works in Practice

Designing controls people will actually use means mapping the control to the moment of decision, not just to the policy requirement. The strongest controls are usually the ones that appear at the point where action happens, are easy to understand in one reading, and do not ask the user to remember a second process. That applies across identity checks, privileged access, data handling, and change approvals.

A practical design pattern is to treat the control as part of the user journey. If an engineer needs elevated access, the request, approval, and time-bounded grant should sit inside the existing ticket or workflow tool. If an analyst needs to handle sensitive data, the warning, classification, and logging should appear in the system they already use. This reduces cognitive load and lowers the chance of bypass. For control wording, plain language matters more than perfect policy language, because users act on what they can interpret quickly.

Security teams should also test controls with real operators before rollout. That includes help desk staff, administrators, developers, finance users, and incident responders, because each group has different time pressure and different tolerance for disruption. Useful checks include:

• Can the user complete the task without needing a side channel or manual exception?
• Does the control still work under incident conditions, when speed matters?
• Does the design support logging, review, and rollback without extra burden?
• Does the control reinforce the desired path, or merely punish the undesired one?

For broader control mapping, NIST SP 800-53 Rev 5 and the CIS Controls v8 both reinforce the idea that implementation detail matters as much as control intent. The same is true for operational resilience guidance in ISO 27001, where governance only works if procedures are actually followed. Measuring deployment is not enough; teams should track whether the control is used, bypassed, overridden, or repeatedly exceptioned after release. These controls tend to break down when they are inserted into emergency workflows, because users under time pressure choose the fastest path and the control becomes a block rather than a safeguard.

Common Variations and Edge Cases

Tighter controls often increase friction and operational overhead, requiring organisations to balance reduced risk against speed, usability, and support load. That tradeoff is real, especially in environments where rapid response is part of the business model. Best practice is evolving, but current guidance suggests that a control should be stricter where the blast radius is high and lighter where the action is low risk and high frequency.

There is no universal standard for how much friction is acceptable. In high-trust internal tools, a well-placed warning or approval may be enough. In privileged or irreversible actions, stronger steps such as step-up verification, time-limited access, or dual approval may be justified. The key is proportionality. Overly rigid controls in software delivery, SRE, and SOC operations often push people toward copy-paste approvals, shared accounts, or out-of-band messaging, which weakens both accountability and telemetry.

Edge cases matter most where the environment is dynamic. Remote work, outsourced operations, break-glass access, and automated service workflows all change how people interact with controls. In those settings, the control must still be usable without becoming a bottleneck. For identity-heavy processes, identity assurance and privilege design can help, but they should not be introduced as friction for its own sake. Current guidance suggests that controls work best when they are embedded in the system of work, not layered on top of it after deployment.

Related resources from NHI Mgmt Group

• How should security teams measure whether authentication controls are actually working?
• How do teams know if identity security controls are actually working?
• How should security teams use AI in identity governance without weakening controls?
• How do security teams know whether privacy controls are actually working?