Cybersecurity Is Not Just Technical: Why Security Policy Is a Human Problem
Deputy Head of Master IT Program
Head of Cybersecurity Research Centre of Excellence
Head of Security Operations Center
Swiss German University
When most people think about cybersecurity, they imagine a purely technical battlefield: firewalls filtering packets at line rate, cryptographic keys protecting data at rest, and adversaries probing systems through lines of code. In this view, security is something engineers build and attackers attempt to break.
This perspective is incomplete—and dangerously so.
Modern cybersecurity failures rarely stem from cryptographic weaknesses or insufficient computing power. Instead, they arise from flawed assumptions, unrealistic policies, human behavior, and institutional trade-offs. Security policy, in particular, sits at the intersection of technology, governance, and human decision-making. Understanding this intersection is essential for anyone responsible for digital safety in governments, enterprises, and critical infrastructure.
This article explores five fundamental insights that challenge conventional thinking about security policy and highlight why cybersecurity must be treated as a socio-technical discipline rather than a purely technical one.
- The Security–Safety Paradox
One of the most counterintuitive truths in security policy is that increasing security can reduce safety.
Although often used interchangeably, these concepts are fundamentally different. Security protects systems against intentional malicious actions, while safety protects people and systems from unintentional harm or failure. Enhancing one can inadvertently undermine the other.
A widely cited example is the reinforced aircraft cockpit door introduced after the 9/11 hijackings. From a security standpoint, the solution was highly effective: unauthorized access to the cockpit became extremely difficult. However, this same control introduced a safety risk—if the pilot becomes incapacitated or malicious, intervention becomes impossible. The measure designed to save lives can, under specific conditions, endanger them [1], [2].
This paradox extends to emerging cyber-physical systems. In autonomous vehicles, for example, a cybersecurity breach is not merely a data-loss incident; it is a direct threat to human life. Yet many regulatory frameworks still treat cyber incidents as financial or privacy risks rather than safety-critical failures [3].
Effective security policy must therefore evaluate controls not only in terms of threat mitigation, but also in terms of the new risks they introduce. Failing to do so creates brittle systems that collapse under unexpected conditions.
- The Inescapable Trade-Off: Security, Usability, and Performance
Security policy is constrained by a fundamental design trade-off between security, usability, and performance. Improving one almost always degrades at least one of the others [4].
Consider multi-factor authentication in financial applications. Requiring multiple authentication steps significantly improves resistance to account takeover attacks, but it also increases login time, user frustration, and support costs. When security controls become too burdensome, users predictably bypass them—writing passwords down, reusing credentials, or disabling safeguards entirely [5].
This phenomenon is well documented in usable security research. Systems that ignore human factors often fail in practice, regardless of their theoretical robustness [6].
From a policy perspective, this means perfect security is neither achievable nor desirable. Organizations must consciously decide what level of risk they are willing to accept and explicitly encode those decisions into policy. Treating risk acceptance as an implicit outcome of technical design is a governance failure, not an engineering one.
- A Security Policy That Cannot Be Executed Is Worse Than No Policy
Many organizations equate security policy with documentation produced for audits or compliance reviews. In reality, a security policy is only valuable if it can guide action during real incidents.
High-level statements such as “all sensitive data must be protected” or “systems must be secure by design” are meaningless unless they are decomposed into concrete, executable procedures. This decomposition—from abstract principle to operational instruction—is where many policies fail [7].
For example, a policy mandating “rapid incident response” is ineffective without clear guidance on:
-
- Who has decision authority during an incident,
- What actions are permitted without escalation,
- Which systems take priority for recovery,
- What evidence must be preserved.
During crises, humans do not have time to interpret vague principles. Studies of incident response failures consistently show that ambiguity in policy leads to hesitation, inconsistent decisions, and escalation of damage [8].
An unrealistic policy creates a dangerous illusion of preparedness. When tested, it collapses, leaving teams without actionable guidance at the moment it is most needed.
- Security Policy Is a Negotiation, Not A Mandate
A common misconception is that security policy can be imposed top-down through authority or technical enforcement. In large organizations, this approach almost always fails.
Different departments operate under different incentives. Marketing prioritizes speed and customer engagement, operations prioritize availability, and finance prioritizes cost control. A security policy that obstructs these goals will encounter resistance—overt or covert.
This is not a technical problem; it is a human one rooted in organizational behavior [9].
Effective security leaders therefore function less as enforcers and more as negotiators. The key is to make goals explicit rather than implicit. When security objectives are openly discussed alongside business objectives, trade-offs become visible and negotiable.
Research in security governance shows that policies developed collaboratively—rather than unilaterally—are more likely to be followed, adapted, and sustained over time [10]. Compromise does not weaken security; it strengthens legitimacy and compliance.
- The Most Powerful Security Capability Is Asking the Right Question
Technical expertise is often equated with having the right answers. In cybersecurity, the more valuable skill is asking the right questions.
Claims such as “the system is secure,” “the risk is low,” or “we are compliant” are meaningless without evidence. A mature security culture challenges such statements by default:
-
- Secure against which threat?
- Under what assumptions?
- Based on which measurements?
This approach aligns with case-based learning and adversarial thinking, both of which are central to effective security education and practice [11]. Instead of relying on static checklists, organizations that cultivate questioning continuously reassess their assumptions as threats, technologies, and operating environments evolve.
From a policy standpoint, this mindset transforms security from a document into an ongoing process of inquiry, validation, and adaptation.
Conclusion: Rethinking Security Policy as Human Infrastructure
The central lesson is clear: cybersecurity is not just a technical discipline. It is a human one.
Security policy must account for human behavior, organizational incentives, imperfect information, and unavoidable trade-offs. The most serious failures do not occur because encryption algorithms are broken, but because assumptions go unchallenged, policies are unrealistic, or incentives are misaligned.
By treating security as a socio-technical system—one that integrates technology, governance, and human judgment—we can move beyond checkbox compliance and toward genuine digital resilience.
The most important non-technical question you can ask about any system you rely on is this:
“What assumptions does this system make about human behavior—and what happens when those assumptions are wrong?”
References
[1] B. Schneier, Secrets and Lies: Digital Security in a Networked World, 2nd ed. Hoboken, NJ, USA: Wiley, 2015.
[2] M. Burghardt et al., “Human factors in aviation security,” IEEE Security & Privacy, vol. 12, no. 4, pp. 14–21, 2014.
[3] N. Kalra and S. M. Paddock, “Driving to safety: How many miles of driving would it take to demonstrate autonomous vehicle reliability?” RAND Corp., 2016.
[4] R. Anderson, Security Engineering, 3rd ed. Hoboken, NJ, USA: Wiley, 2020.
[5] A. Adams and M. A. Sasse, “Users are not the enemy,” Communications of the ACM, vol. 42, no. 12, pp. 40–46, 1999.
[6] L. F. Cranor and S. Garfinkel, Security and Usability, Sebastopol, CA, USA: O’Reilly, 2005.
[7] ISO/IEC 27001:2022, “Information security, cybersecurity and privacy protection — Information security management systems,” ISO, Geneva, Switzerland, 2022.
[8] NIST SP 800-61 Rev. 2, “Computer Security Incident Handling Guide,” National Institute of Standards and Technology, Gaithersburg, MD, USA, 2012.
[9] J. Reason, Managing the Risks of Organizational Accidents, Aldershot, U.K.: Ashgate, 1997.
[10] E. Weippl et al., “Security governance: A framework for effective collaboration,” Computers & Security, vol. 87, 2019.
[11] D. P. Fidler, “Cybersecurity, human factors, and governance,” Journal of Cyber Policy, vol. 4, no. 2, pp. 145–164, 2019.
