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 rules that fight the way people actually work do not get followed. They get worked around, often in ways that are less safe than having no rule at all. People-centred security starts from the opposite direction: make the secure way also the easy way. This guide shows how, using three everyday areas: remote work, video meetings, and social media.
Why traditional policy design fails
Classic policies are written by asking "what is the most secure setting possible?" instead of "what will people really do, and how do we make the safe option the easiest?" A rule demanding a new 16-character password every 30 days produces sticky notes on monitors, not security. The problem is not that people are careless. It is that the policy ignored human behavior.
Three common policy areas, redesigned
| Area | Policy that gets ignored | Policy that works |
|---|---|---|
| Remote work | A long list of home-network settings nobody can check | Assume the home network is untrusted. Protect the device (disk encryption↗), the connection (VPN or zero-trust access), and the account (multi-factor authentication↗) |
| Video meetings | "Remember to configure every meeting securely" | Waiting rooms and meeting passwords on by default, and a short reminder before screen sharing |
| Social media | A long list of banned topics | Three memorable principles (below) |
Remote work
Home networks are shared with smart TVs, family members' devices, and routers nobody has updated. Trying to copy office network rules onto them rarely works. Instead, design controls that do not depend on trusting the network. A VPN is a protected tunnel back to the organization, and zero-trust access means every request is checked rather than trusting anyone who happens to be inside the network. 
Video meetings
People join many meetings every week, so any extra step feels like a burden and gets skipped. Make the secure choice the default so nobody has to remember it. Give short, specific advice instead of lectures, such as "check which window you are sharing before you click".
Social media
Nobody can hold a list of forbidden topics in their head while posting. Teach three memorable principles instead:
- Do not share anything that would help someone answer a security question about you or your organization (a pet's name, a first school, a mother's maiden name).
- Assume anything posted is permanent and public, whatever the privacy settings say.
- Before you post, ask: what could a scammer write in a targeted phishing↗ email using this?
The common thread: reduce effort, not only risk
Every example follows one principle. Guidance that asks people to remember, calculate, or choose correctly in the moment will eventually fail, because people are busy and security is rarely their main task. Guidance that changes a default, removes a decision, or makes the safe choice effortless works, because it does not depend on someone remembering a policy at 4 p.m. on a Friday.
A worked example
A department's policy requires a long password change every month, so staff keep passwords on paper. After a review, the department switches to a password manager↗ and two-factor authentication, drops the forced changes, and only asks for a new password when there is a sign of compromise. Sticky notes disappear, sign-in problems fall, and accounts are better protected. The policy got stricter in the places that mattered and easier everywhere else.
Measuring whether it is working
- Count exception requests. A high number means the rule does not fit real work, not that people are being difficult.
- Ask anonymously which requirements are hardest to follow, and treat the answers as a design problem, not a training gap.
- Look for workarounds and shadow IT↗ (tools adopted without approval). They show where the official route is too painful.
Related reading


