People-Centred Security: Designing Policies Humans Actually Follow
Security policies that ignore how people actually work get quietly ignored. A practical look at designing remote work, video conferencing, and social media policies people follow because they make sense.
Security policies that fight against how people naturally work don't get followed, they get worked around, often in ways that are less secure than if no policy existed at all. People-centred security starts from the opposite direction: design the secure path to also be the easy path.
Why traditional security policy design fails
Classic security policies are often written by asking "what's the most secure configuration possible?" rather than "what will people actually do, and how do we make the secure option the path of least resistance?" A password policy demanding a new 16-character password every 30 days produces sticky notes, not security. The failure isn't that people are careless, it's that the policy didn't account for human behavior.
Applying this to remote work policy
Remote work security policies often try to replicate office-network security assumptions onto home networks, which rarely works. A more effective approach: assume the home network is untrusted (because it usually is, shared with smart devices, family members, and unmanaged routers), and design controls that don't depend on network trust at all, device-level encryption↗, VPN or zero-trust network access for anything sensitive, and multi-factor authentication↗ everywhere, rather than a long list of home-network configuration requirements nobody will verify or enforce.
Video conferencing: security that doesn't interrupt the meeting
Video conferencing security policies frequently fail because they add friction to something people do dozens of times a week. What works instead: default-secure settings (waiting rooms and meeting passwords enabled by default, not opt-in), clear and simple guidance on what's safe to screen-share (a reminder before screen-sharing, not a lecture), and making the secure choice the default so people don't have to remember to configure it correctly every time.
Social media: guidance people can actually apply
Corporate social media policies that consist of a long list of prohibited topics get ignored because nobody can hold that list in their head while posting. More effective guidance boils down to a few memorable principles: never share information that would help someone answer a security question about you or your organization, assume anything posted is permanent and public regardless of privacy settings, and think about what a targeted phishing↗ email could do with the information in this post before hitting share.
The common thread: reduce cognitive load, not just risk
Every one of these examples follows the same underlying principle: security guidance that requires people to remember, calculate, or choose correctly in the moment will eventually fail, because people are busy and security is rarely their primary task. Guidance that changes the default, removes a decision, or makes the secure choice effortless succeeds because it doesn't depend on someone remembering the policy at 4pm on a Friday.
Measuring whether it's working
- Track how often people request exceptions to policy, a high exception rate is a signal the policy doesn't fit real workflows, not that people are non-compliant.
- Run anonymous surveys asking what security requirements people find hardest to follow, and treat the answers as a design problem, not a training gap.
- Watch for shadow IT↗ and workarounds, their existence tells you exactly where the official path is too painful to use.
Related reading


