For much of his career, Michael Adekanye has worked at the intersection of cybersecurity, governance, and business strategy. Having led security and risk initiatives across financial services, technology, and manufacturing organizations, he has seen firsthand how cybersecurity evolves when organizations mature, from focusing on technical controls to making informed decisions about risk, resilience, and growth. His work today increasingly centers on a challenge facing security leaders everywhere: building governance models for technologies that are advancing faster than the frameworks designed to manage them.
That perspective makes Adekanye a compelling guest for CISO Diaries, our interview series exploring the people behind modern security programs. Beyond incidents, audits, and compliance requirements, the series examines how security leaders think, prioritize, and adapt in rapidly changing environments. In this conversation, Adekanye discusses the realities of governing AI adoption, why access management remains one of the most overlooked security disciplines, the growing convergence of operational technology and cyber risk, and the leadership lesson that transformed his effectiveness: learning that being technically correct is only valuable if you can translate that insight into action.
How do you usually explain what you do to someone outside of cybersecurity?
I tell people I help the organization understand what could go wrong and make deliberate decisions about which risks are worth taking. Most people picture cybersecurity as firewalls and hackers. The reality is closer to enterprise risk management with a technical dimension. I’m asking: where are we exposed? What would the impact be? Are we treating this risk proportionally? When I explain it that way, people outside the industry usually say, “Oh, that’s actually really important.” This tells you something about how we have historically communicated what we do.
What does a “routine” workday look like for you, if such a thing exists?
I start most mornings reviewing threat intelligence and overnight alerts, a quick read to confirm nothing changed while I was offline. From there, the day could go anywhere: a third-party risk assessment, a conversation with engineering about a new AI integration someone wants to deploy, a risk committee presentation, a regulatory inquiry. The predictable parts are the governance cadences, audit cycles, board reporting, and compliance deadlines. Everything else tends to emerge. After more than ten years across financial services, fintech, and now manufacturing, I have stopped expecting predictability and started treating adaptability as a core professional competency.
What part of your role takes the most mental energy right now?
Governing AI adoption, specifically the gap between how fast the business wants to move and how immature the risk frameworks still are. We are dealing with questions that ISO 27001 and NIST CSF were not designed to answer: How do you manage data residency risk when a process calls an external LLM via an API? How do you audit an AI-assisted decision? What does third-party risk look like when the “third party” is a foundation model? We’re building a governance architecture in near real time, drawing on principles from existing frameworks while extending them significantly. That kind of original thinking under business pressure, without established precedent, is the most demanding work on my desk.
What’s one security habit or routine you personally never skip? (Work or personal.)
Access review. It sounds unglamorous compared to the more visible parts of security practice, but access sprawl is one of the most persistent and underappreciated risk vectors in any organization. I periodically review what I personally have access to, and at the program level, I push hard to ensure we run disciplined access recertification cycles across the business. Least privilege is easy to endorse in a policy document and very easy to erode in practice. The person who left a team eight months ago and still has read access to a sensitive repository is a real exposure, not a theoretical one. Closing those gaps consistently requires deliberate effort.
What does your own personal security setup look like? (Password manager, MFA, backups, devices, at a high level.)
Password manager, no exceptions, across every account. Hardware security keys wherever a service supports them, TOTP for everything else. Backups on a 3-2-1 basis: three copies, two different media types, one stored offsite. Strict separation between work and personal devices, both in terms of physical hardware and what services I access from where. DNS-level filtering on my home network. None of it is particularly exotic; it is the disciplined application of basics. I have noticed that practitioners who have worked through serious incidents tend to be the most rigorous about fundamentals, because they’ve seen what the failure modes actually look like.
What book, podcast, or resource has influenced how you think about leadership or security? (Doesn’t have to be technical.)
Peter Drucker’s writing on management has shaped how I think about security governance more than most technical literature. His argument that you can’t manage what you don’t measure, and the harder corollary that not everything worth managing is easily measurable, is something I return to constantly when designing risk metrics and board reporting. On the security side, the Verizon data breach investigation report has been a reliable north star for grounding strategy in what’s actually happening in the threat landscape rather than what’s theoretically possible.
For staying current and connected to the practitioner community, two podcasts I return to consistently are Simply Cyber with Gerald Auger and Chuck Sapp, and David Bombal’s podcast. Simply Cyber is particularly good at translating what’s happening in the threat landscape into actionable thinking for security professionals. Gerald and Chuck bring a grounded, no-nonsense perspective that resonates with how I approach the work. David Bombal covers a broader technical range and has introduced me to thinking across networking, ethical hacking, and emerging technologies, keeping the technical foundations sharp even as my role has become more governance-oriented.
I also stay closely engaged with the research and technology roadmaps coming out of major OEMs like Microsoft, Cisco, Fortinet, and Check Point, in particular. Their threat intelligence publications, security blogs, and annual reports aren’t marketing material if you read them critically; they surface real-world attack pattern data, emerging capability gaps, and where the industry is investing defensively. Watching how these vendors are positioning their platforms around AI-assisted detection, zero-trust architecture, and OT security gives me a practical lens into where enterprise security is actually heading, not just where the frameworks say it should go.
My background in electrical and electronics engineering also shaped how I reason about security, because good security thinking has a lot in common with good systems engineering: you model failure modes before they manifest, not after.
What’s a lesson you learned the hard way in your career?
That technical correctness doesn’t automatically produce organizational action. Early on, I believed a well-evidenced, well-structured risk finding would carry its own weight in a room. It doesn’t. Executives and board members respond to risk framing that connects to their context in terms of financial exposure, regulatory consequence, reputational risk, and strategic objectives. I had to learn to translate security findings into business language, and to understand that my role isn’t only to identify and assess risk, but also to be understood and acted on. The shift from “I’m right” to “I’ve communicated this in a way that enables a good decision” took time, but it made me significantly more effective as a security leader.
What keeps you up at night right now, from a security perspective?
The convergence of OT and IT risk in industrial environments. In manufacturing, the consequences of a breach aren’t limited to data loss; they can mean production downtime, physical damage to equipment, or safety incidents involving people. Picture a legacy PLC controlling a production line with no realistic patch path, increasingly reachable from the corporate network as the environment becomes more connected. OT security maturity across the industry still lags IT security substantially, and the attack surface keeps expanding. Combine that with the pace of AI-assisted offensive tooling, which lowers the skill threshold for sophisticated attacks, and the gap between attacker capability and defensive readiness in industrial environments becomes real. It’s a category of risk that doesn’t get enough boardroom attention relative to its potential impact.
How do you measure whether your security program is actually working?
A combination of leading and lagging indicators. Lagging indicators like incidents, breach dwell time, audit findings, and regulatory actions will tell you how you performed. Leading indicators such as patch cadence, mean time to detect, third-party assessment completion rates, and risk treatment velocity will tell you whether the program is positioned to perform well. I pay particular attention to risk treatment velocity: are identified risks being closed within agreed-upon timelines, or are they accumulating in a register? A program that generates findings but doesn’t resolve them isn’t functioning, regardless of how well-documented it is. Qualitatively, I also track whether the business comes to security proactively or treats us as a compliance checkpoint. Culture is a lagging indicator, but one of the most revealing ones.
What advice would you give to someone stepping into their first CISO role today?
Spend the first ninety days listening more than presenting. Understand the business model, risk appetite, regulatory context, and organizational culture before you begin restructuring anything. The most common mistake I see new security leaders make is importing a program from their previous organization without accounting for where the new one actually is. Security maturity is context-specific, and a well-intentioned program calibrated for the wrong organization will fail regardless of its technical quality. Build relationships with the CFO and General Legal Counsel early; your most consequential conversations won’t be with other security leaders, they will be with the people who control the budget and who translate risk into legal and financial consequences. And be honest about what you don’t know. Credibility is damaged faster by overcommitting than by acknowledging complexity.
What do you think will matter less in security five to ten years from now?
With signature-based detection as a primary defensive mechanism, the threat landscape has moved well beyond what pattern matching can handle at the required speed and scale. The compliance-as-a-security mindset will also lose credibility; regulators are raising their expectations, and passing an annual audit will increasingly be seen as a floor rather than an achievement. Manual penetration testing, as the primary assurance method, will recede as continuous automated testing and adversarial simulation take on more of that function. What will endure is human judgment, the contextual risk reasoning that accounts for business strategy, organizational culture, and threat context in ways automation can assist but not replicate.
Looking ahead 10 years, what do you believe security teams will spend most of their time on that they don’t today?
AI governance and assurance. As organizations embed AI into consequential processes, such as underwriting, supply chain management, manufacturing control, and access authorization. The security teams will need to ensure those systems: verifying that models behave within expected parameters, that training data integrity is maintained, that outputs aren’t being manipulated, and that AI-assisted decisions leave an auditable trail that regulators will accept. The discipline is nascent, and the intersection of security engineering, data science literacy, and governance design is not yet a common professional profile. Teams that begin developing that capability today will be meaningfully ahead when it becomes a baseline expectation.
