About

I work in systems architecture across OT and IT, which is where I learned that the technical problems are rarely the hardest part. The real friction shows up in us: how people react under pressure, how communication fails when things go wrong, how fear shuts down curiosity exactly when it's needed.

That observation shapes how I work on the things this field is actually made of: critical infrastructure and OT security, incident response, operational resilience, and the European regulatory frame (NIS2, DORA, CER, GDPR) that now sits behind them. The tooling and the standards are the easy half. The hard half is whether a team stays curious and coordinated while the pressure is real.

Two points drive that. People learn and commit best when they own the work and are genuinely interested in it, not when it arrives as a procedure to follow. And a group under stress behaves much the same whether it is a family or an organisation. Working that human and organisational layer is most of the job.

That means making the situation concrete enough to work with, then stepping back to see what happens: what an attacker can do, what a defender can see, where a decision changes the route, and what people do when the pressure is real. Sometimes that is a rehearsal or a simulation. Sometimes it is an assessment, an investigation, or a small piece of software built because the question had nowhere else to go. The useful part is what becomes visible that wasn't before.