Topic starter
01/08/2026 8:54 pm
TL;DR: Security teams that treat controls as a product, not an edict, are more likely to earn adoption and reduce friction, according to Abstract Security’s C2 Corner article. The central shift is moving from force-based enforcement to evidence-led controls that users can understand, choose, and work with.
Editorial analysis by NHI Mgmt Group, based on content published by Abstract Security: “C2 Corner: Security as a Product”.
Key questions
Q: How should security teams design controls that people will actually use?
A: They should start with the risk, then design the control around the user journey that already exists.
Q: Why do technically sound controls still fail in real deployments?
A: Because technical soundness only proves the mechanism works under the assumptions in the design.
Q: What are the signs that a security control is failing because it is too hard to use?
A: A control is failing when users repeatedly work around it, delay adoption, or use insecure shortcuts to finish routine tasks.
Practitioner guidance
- Define the control as a user-facing product Write each major control in terms of the risk it reduces, the value users receive, and the workflow it supports, not just the rule it enforces.
- Build an exception path before rollout Create a documented process for edge cases so legitimate users are not forced into informal workarounds when the default control does not fit.
- Use evidence to explain the change Present the misuse pattern, the business impact, and the reason the chosen control is the least disruptive viable option.
Bottom line: Security controls are more durable when they are designed around how people actually work, not just how policy says they should work.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
01/08/2026 9:03 pm
Adoption is a control outcome, not a communications afterthought. Security teams often treat user acceptance as something that happens after design is complete. In reality, adoption determines whether the control exists as intended in daily operations. Where users reject or bypass controls, the governance model has failed before the technical control has a chance to work. Practitioners should treat usability, exception design, and explainability as part of the control itself.
A question worth separating out:
Q: Should security teams optimise for enforcement or for adoption?
A: They need both, but adoption comes first in practice. A control that cannot be used consistently is not really enforced, only announced. The better programme is the one that combines clear standards with a usable path, measured exception handling, and continuous refinement.
👉 Read our full editorial: Security as a product: why adoption beats edicts in practice