Cybersecurity today is less about reacting to threats and more about enabling better decisions under uncertainty. In CISO Diaries, we speak with security leaders who operate at this intersection, where technical complexity meets boardroom accountability. This series explores how CISOs and security advisors navigate ambiguity, prioritize what truly matters, and translate risk into language that drives action at the highest levels of an organization.
By focusing on real-world routines, habits, and leadership philosophies, CISO Diaries reveals the evolving nature of the role. Modern security leaders are no longer just defenders of systems; they are strategic partners to the business, responsible for aligning security with growth, resilience, and regulatory expectations in an increasingly complex landscape.
About Fabrizio di Carlo
Fabrizio di Carlo is a cybersecurity strategist and governance advisor with over 14 years of experience across Europe’s financial services and technology sectors. As the founder of ContrailRisks, he works as a fractional CISO and trusted advisor to boards and executive teams, helping organizations navigate the growing demands of cyber resilience, regulatory frameworks such as DORA and NIS2, and the strategic integration of security into business decision-making.
With a career that spans hands-on leadership within highly regulated enterprises to advisory roles at the executive level, Fabrizio specializes in translating complex technical and regulatory challenges into clear, actionable direction. His approach is grounded in the belief that security must serve the business, with a strong emphasis on governance, clarity, and independent challenge, ensuring organizations can make confident decisions in the face of evolving threats and uncertainty.
How do you usually explain what you do to someone outside of cybersecurity?
I usually say: I help companies make better decisions under uncertainty.
Cybersecurity is often framed as a technical problem, but in reality it’s a business risk problem. The threats are real, but so is the cost of over-investing in the wrong places or under-investing where it matters. My role is to translate complex threats into clear trade-offs that leadership can act on, balancing risk, cost, and growth.
Most executives don’t need to understand how an attack works. They need to understand what it means for their business, what it would cost them, and what it would cost to reduce that exposure. Once you frame it that way, the conversation changes completely. Security stops being an IT problem and starts being a strategic one, which is where it belongs.
What does a “routine” workday look like for you, if such a thing exists?
There’s no real routine, but there is a pattern. Most days involve some combination of three things:
- Time with leadership: aligning security priorities with business goals, translating risk into language that lands at board level, and making sure the security agenda is connected to what actually drives the organisation.
- Deep work: working through a complex risk assessment, reviewing an architecture, navigating a regulatory requirement like DORA or NIS2, or stress-testing a governance framework against real-world constraints.
- Decisions: a constant stream of them. What matters now versus what can wait. Where to push back, and where to find a workable path forward.
As a fractional and advisory CISO, context-switching is part of the job. You might move from a board-level risk briefing to a technical architecture review in the same afternoon. That breadth is challenging, but it’s also what keeps the thinking sharp. You develop a kind of mental agility that you don’t get from sitting inside a single organisation.
What part of your role takes the most mental energy right now?
Prioritisation. Without question.
Not identifying risks, there are always many, and most organisations have more open findings than they can ever close. The hard part is deciding which ones truly matter in the context of business objectives, regulatory pressure like DORA or NIS2, and the very real constraints of budget and capacity.
The instinct in security is to flag everything and let leadership decide. But that’s not leadership, it’s delegation disguised as diligence. Real security leadership means being willing to say: out of everything on this list, these three things could genuinely hurt us, and here’s why. That requires judgment, not just analysis.
Clarity is harder than complexity. Producing a 40-page risk register is easy. Distilling it into a clear, actionable recommendation that a busy executive can act on in five minutes, that’s the work.
What’s one security habit or routine you personally never skip?
Checking. Verifying. Not assuming. That sounds abstract, but it shows up in very concrete ways: I verify links before I click them. I check sender details before I respond to anything with a request embedded in it. I treat urgency as a red flag rather than a cue to act quickly.
The adversarial manipulation techniques we worry about at the enterprise level work exactly the same way on individuals. And the professionals who get caught out are almost always the ones who believed they were too experienced to be caught. That belief is the vulnerability.
What does your own personal security setup look like? (Password manager, MFA, backups, devices, at a high level.)
Nothing exotic, just consistent application of fundamentals, which I think is exactly the point. I use two password managers: one for personal and family use, one for work. Every account that supports it has MFA enabled, and wherever possible I use a hardware key, a YubiKey, rather than SMS or app-based codes. All my devices are encrypted.
I also maintain regular backups, with at least one copy that’s offline or immutable, so that even if something catastrophic happens, I’m not negotiating with ransomware. The setup isn’t complicated. The discipline is in actually doing it consistently, not just having the tools.
What book, podcast, or resource has influenced how you think about leadership or security? (Doesn’t have to be technical.)
Several, but I’ll start with the ones that challenged me most. Greg van der Gaast’s books, “Rethinking InfoSec” and “What We Call Security”, genuinely changed how I think about this field. Greg argues, convincingly, that most of what we call security is performance: we keep reinstalling the same broken and compromised system rather than addressing root causes. I have the privilege of working with Greg, which means I’ve had to really interrogate whether I believe it. I do. Those books are for people who are willing to be uncomfortable with the status quo.
On strategy and architecture: Gregor Hohpe’s “The Software Architect Elevator” and “Technology Strategy Patterns” shaped how I think about the space between technical depth and executive communication, something every security leader has to navigate. And Michael Lopp’s “Managing Humans” was quietly one of the most useful things I’ve read on actually leading people, which is ultimately what the role is about.
I’m currently reading Ross Young’s “Cybersecurity’s Dirty Secret: Why Most Budgets Go to Waste” and it’s doing what the best books do: making me nod along and feel uncomfortable in roughly equal measure.
What’s a lesson you learned the hard way in your career?
Being technically right is not enough. I learned this early on. I’d identified a real risk, I had the data to support it, and I was correct. But I hadn’t brought the right stakeholders along, I hadn’t communicated it in terms that landed for them, hadn’t connected it to what they actually cared about. The risk materialised. The outcome was the same as if I’d been wrong.
That experience fundamentally changed how I work. Communication isn’t a “soft skill” that sits alongside security expertise, it is a core security capability. If you can’t make people understand why something matters and get them to act on it, your technical correctness is worth nothing. The most important thing a security leader can develop, after deep competence, is the ability to translate.
What keeps you up at night right now, from a security perspective?
The growing gap between perceived control and actual control.
Organisations often believe they are more secure than they are, especially in complex, hybrid, or AI- driven environments. They’ve invested in tools, passed their audits, and ticked the compliance boxes. But controls on paper and controls in practice are not the same thing. And in fast-moving environments where architectures evolve, third parties multiply, and AI systems are layered in with limited governance, that gap can widen quietly and quickly.
What makes this particularly dangerous is that a false sense of security changes behaviour. When leadership believes the situation is under control, risk appetite rises, edge cases get waved through, and the scrutiny that catches problems before they become incidents gets relaxed.
Known risk can be managed. It’s the risk you don’t know you’re carrying that causes the real damage.
How do you measure whether your security program is actually working?
I look at three things:
- Risk reduction over time: not just control implementation. It’s easy to count the controls you’ve deployed. The harder question is whether your actual exposure has decreased. Are the right risks being addressed, or are you adding coverage in areas that don’t move the needle?
- Decision quality: are we prioritising the right things? A security programme that consistently focuses resources on genuine business risk, rather than compliance theatre or legacy priorities, is a programme that’s working. One that perpetually firefights or defaults to checkbox behaviour is not.
- Business alignment: is security enabling or blocking outcomes? If the answer from the rest of the business is mostly the latter, that’s a signal. Security should be a function that makes good things possible safely, not one that simply says no.
Metrics should reflect reality, not just activity. A dashboard full of green doesn’t mean you’re secure. It might just mean you’re measuring the wrong things.
What advice would you give to someone stepping into their first CISO role today?
Don’t start with controls but start with context.
In the first weeks, resist the urge to immediately audit, assess, and produce a remediation roadmap. That instinct is understandable, it feels productive, it demonstrates competence. But a security strategy that isn’t built on a deep understanding of the business is just a list of things to do. It won’t get traction, and it won’t be sustained.
Understand the business model. Understand the revenue drivers, the operational dependencies, the regulatory environment, and , critically, what genuinely keeps the CEO and the board awake at night. Then build security around that. Your job is to protect the things that matter most to the organisation, not to implement the controls that matter most to the framework.
Also: learn to say no, but more importantly, learn to say “yes, if…”. Security leaders who only say no get bypassed. Those who find the path to yes, with appropriate guardrails, build the trust and influence that actually makes organisations safer.
And read Greg van der Gaast. Seriously.
What do you think will matter less in security five to ten years from now?
Purely technical differentiation.
Many of the controls we invest significant effort and resource in today, endpoint protection, vulnerability scanning, identity verification, will become commoditised or largely automated. The underlying capability will still matter, but it won’t be where competitive advantage or programme quality is determined. You’ll be able to buy it, or it will simply be part of the platform.
What won’t be automated is judgment. The ability to understand which risks actually threaten the business, how to communicate them credibly to leadership, how to design governance that works in practice rather than just on paper, those remain stubbornly human capabilities. The real differentiator, five to ten years from now, will be how well security integrates with business strategy and decision-making. The CISOs who build that bridge will define the next era of the function.
Looking ahead 10 years, what do you believe security teams will spend most of their time on that they don’t today?
Designing and governing trust in complex systems, especially involving AI, third parties, and deeply interconnected ecosystems.
Today, security teams largely work on systems that humans built and humans operate. In ten years, a significant proportion of the systems they protect will be making autonomous decisions, learning from data, and interacting with other autonomous systems. Securing those environments isn’t just about perimeter defence or access controls, it’s about ensuring the integrity of the intelligence itself. Model behaviour, training data provenance, agent decision chains, these will be core security domains.
The other major shift: security teams will spend less time reacting to incidents and more time shaping how systems are designed in the first place. The security function that operates purely as a downstream reviewer, assessing what others have built, will be consistently too late. The functions that embed security thinking into architecture, product design, and supplier governance from the outset will be the ones that actually reduce risk rather than just documenting it.