Human-Centric Security

Human-centric security starts from an observation most security teams already make in practice: people, not systems, decide whether a control works. A policy that is slow, unclear or at odds with the job gets worked around, however sound it looks on paper. The approach therefore treats usability, context, and motivation as security properties, next to encryption and access control.

It does not mean fewer controls, and it is not the same as awareness training. It is a design stance: controls are tested against real workflows, explained at the moment they apply and tuned with feedback. Its natural focus is the human side of insider threats, where the same employee can be a careless actor, a target of social engineering or, rarely, a deliberate attacker.

Technology-first programs assume that once a rule exists, people will follow it. In reality a blocked task rarely disappears: it moves to a path the security team cannot see, which is how shadow IT and shadow AI grow inside organizations with strict policies. Common workarounds look like this:

• Sending a work file to a personal email address because the approved sharing tool is slow
• Pasting a draft or a customer message into a public AI chatbot to finish faster
• Sharing one account to avoid waiting for an access approval
• Avoiding a security tool that interrupts every task

The approach is usually described through a handful of principles. They are shared habits of design rather than a single formal standard, and vendors and analysts phrase them in different ways.

A human-centric program is a loop, not a one-time rollout. Begin with data classification so that effort follows value, then run the same loop for each group of controls.

1. 1

   Map real workflows

   Observe how teams actually handle sensitive data, including the shortcuts they use.

2. 2

   Match controls to risk

   Apply strict controls where a mistake is costly and lighter, explanatory ones elsewhere.

3. 3

   Guide in the moment

   Show short, plain messages when an action is blocked or risky, with a clear next step.

4. 4

   Review and tune

   Look at where people bypass or struggle, then change the rule or the tool, not only the training.

The phrase «people are the weakest link» is common in security talks, and it shapes design: if people are the problem, the answer is to remove their choices. Human-centric security reverses the question and asks why the secure choice is hard. The two views lead to different habits.

Anexet does not replace training or culture, but its console supports the human-centric loop. A blocking rule can show a short notification on the employee's workstation, with text the administrator writes, and access to dashboard widgets and user lists is configured by role. Because Anexet Activity is deployed on-premise, the data behind these views stays inside the organization.

1 / 2

• 
• 

Looking at behavior raises its own human question: how much visibility is fair. A human-centric program treats monitoring as proportionate and transparent. Staff should know what is collected and why, access to personal-level data should be limited to the roles that need it, and deeper drill-down should follow an alert rather than curiosity.

This is also where user and entity behavior analytics belongs: as a way to notice a change against a person's own normal pattern, not as a verdict about the person. Rules on employee monitoring and personal data differ by country and by employer, so legal review comes before rollout, not after.

Start small and concrete. Pick one high-value type of data, find out how people really move it and compare the approved route with the shortcuts. Remove the friction that pushes people toward the shortcut, then add data loss prevention controls for what remains, with messages that say what happened and what to do next. Review the results with the teams affected and repeat.