Security Behaviour

The majority of successful attacks do not exploit a software vulnerability. They exploit a person who was busy, helpful, tired, or simply following a process that made the unsafe action the easiest one. Technical controls matter, but the deciding variable is behaviour — and behaviour can be observed, understood and changed.

Why this matters now

Generative AI has collapsed the cost of convincing deception. Spear-phishing emails in flawless German, voice clones of the CFO, fake vendor portals built in an afternoon: the “obvious tells” that awareness training relied on for a decade are gone. Meanwhile, the same AI tools inside your organisation create new surfaces — an engineer pasting credentials into an assistant, an agent acting on a manipulated document, a support bot that can be talked into revealing data.

Regulators have noticed. DORA, NIS2 and sector guidance now expect evidence that awareness measures are effective, not merely delivered.

How I approach it

My background is in interdisciplinary research on how humans interact with complex, security-critical systems. That shapes the method: before any training, I assess. Structured observation, interviews, workflow analysis and controlled simulations reveal why unsafe behaviour occurs — time pressure, ambiguous responsibility, tools that punish caution — and that diagnosis drives the intervention.

Training is then designed for the actual teams: engineers, operations, finance, leadership, each with their own attack surface and their own language, often across cultures. Sessions are interactive and measured, and results feed a culture dashboard that management can act on and regulators can read.

Where it typically starts

A four- to six-week behaviour assessment of one business unit or one critical process, including a simulation baseline. From there, a training programme, a redesign of the riskiest workflows, or both.