CISO Diaries: Samuel Kibet Keter on Protecting Revenue, Identity, and Trust

Cybersecurity is often framed as a technical discipline, but at its core, it is about protecting the mechanisms that keep a business alive. In CISO Diaries, we sit down with leading security executives around the world to explore what their roles actually look like beyond headlines and breach reports. We examine how they structure their days, where they focus their mental energy, the habits they refuse to compromise on, and how they translate technical risk into business reality.

This series is designed to spotlight the human side of security leadership, the constant context switching, the risk decisions made under pressure, and the invisible guardrails that allow organizations to grow safely. Because modern CISOs are not just defending networks; they are safeguarding revenue streams, digital trust, and operational resilience in increasingly complex environments.

About Samuel Kibet Keter

Samuel Kibet Keter is a cybersecurity leader with over a decade of experience in audits, risk management, and security governance across banking, fintech, and consulting environments. Most recently, he served as Senior Manager of Cyber Defence at Equity Bank Limited, where he led cyber defense strategy across six markets, securing digital banking platforms and cross-border financial operations in high-risk regions including South Sudan, Tanzania, Uganda, the DRC, and Rwanda.

Throughout his career, Samuel has aligned enterprise security programs with ISO 27001, NIST, and PCI DSS standards, strengthened regulatory compliance across subsidiaries, and led incident response, vulnerability management, and third-party risk programs at scale. Known for his practical and data-driven approach, he focuses on measurable risk reduction, automation, and ensuring that security enables, rather than slows, business growth.

How do you usually explain what you do to someone outside of cybersecurity? 

I tell them I protect how the company makes money. Every business runs on data, code, access, and trust. I make sure the right people have access to the right systems, attackers stay out, and when something breaks, we respond quickly. If the business stops because of a breach, I failed. If customers trust us with their data, I did my job. That usually clicks. 

What does a routine workday look like for you, if such a thing exists? There is no fixed routine, but there is structure. 

My day often looks like this: 

• Review overnight alerts and incidents with SecOps 
• Check risk exposure across the cloud and endpoints 
• Align with engineering on secure design decisions 
• Unblock a compliance or audit dependency 
• Review metrics for attack surface and remediation speed 
• Make at least one decision that reduces risk in the long term 

Some days, I am deep in architecture. On other days, I am in board-level discussions, translating risk into business language. Context switching is constant, and prioritization is a matter of survival. 

What part of your role takes the most mental energy right now? 

Balancing speed and control. Engineering wants to ship. The business wants growth. Security wants guardrails. My job is to build controls that enable speed without creating silent risk. In cloud environments, a single misconfiguration can scale quickly. One exposed secret moves across systems in minutes. You cannot rely on policy documents. You need automation, visibility, and cross-team ownership. That alignment takes the most energy. 

What’s one security habit or routine you personally never skip? 

I never reuse passwords, ever. Every account has a unique password generated by a manager.  Every critical account has hardware-based MFA. Small habits prevent big incidents. Most breaches start with simple mistakes.

What does your own personal security setup look like? 

At a high level, I keep things locked down by: using a dedicated password manager with unique creds for every account, MFA keys on my main email and bank stuff, separate admin/standard user accounts on my devices, auto encrypted backups, full-disk encryption on laptops and phones, super minimal apps (especially browser extensions), and I regularly audit connected third-party apps. Security isn’t about paranoia; it’s about shrinking your attack surface as much as possible. 

What book, podcast, or resource has influenced how you think about leadership or security? 

The Phoenix Project by Gene Kim changed how I see security inside engineering organizations. It showed me that bottlenecks kill performance. Security becomes a bottleneck when it lacks visibility or automation. On the leadership side, I follow leaders who write openly about failure.  Real stories of incidents, poor decisions, and recovery. That shaped how I lead during crises.  Calm. Direct. Transparent. 

What’s a lesson you learned the hard way in your career? 

Assuming someone else owned a risk. Early in my career, I saw a misconfiguration in a cloud environment. I flagged it casually. I did not push hard. Weeks later, it became a real issue. Now,  if I see a control gap, I document it, assign ownership, track remediation, and follow through.  Silence creates exposure. 

What keeps you up at night right now, from a security perspective? 

With all the identity sprawl from the SaaS explosion, cloud setups, API-heavy worlds, service accounts, Slack bots, GitHub tokens, and CI pipelines, most attacks these days are straight-up identity-based. Think stolen tokens, OAuth hijacks, or privilege escalations. If you lose the keys to identity, you’ve lost the whole environment. That’s my main focus. 

How do you measure whether your security program is actually working? 

I go by data, not vibes. Stuff like mean time to detect and respond to incidents, percentage of assets with critical misconfigurations, time to patch high-severity issues, MFA coverage on privileged accounts, phishing failure rates over time, and audit findings year-over-year.

If risk drops and engineering speed holds steady (or even picks up), the program’s doing its job.  If teams start dodging security to ship faster, it’s a total failure. 

What advice would you give to someone stepping into their first CISO role today? 

First, map your assets. You cannot protect what you do not see. Second, understand how the company makes money. Tie every security priority to revenue, trust, or regulatory exposure.  Third, build alliances early with engineering and product leaders. Security without relationships becomes noise. Fourth, automate from day one, as manual reviews do not scale. Fifth,  communicate risk in business terms. Boards do not care about CVE numbers. They care about impact. 

What do you think will matter less in security five to ten years from now? 

Manual checklist compliance. Security teams spend too much time proving controls exist instead of building systems that enforce controls by design. Continuous monitoring and policy as-code will replace many spreadsheet-driven audits. Security will shift from reactive review to embedded engineering. 

Looking ahead 10 years, what do you believe security teams will spend most of their time on that they don’t today? 

Machine-to-machine trust. AI agents making decisions. Autonomous systems deploying code.  Automated infrastructure changes. 

Security teams will focus on: 

• Governing AI-driven actions 
• Verifying the integrity of software supply chains 
• Continuous validation of identity and device trust 
• Detecting subtle abuse inside legitimate workflows 

The future risk will not always look like a hacker in a hoodie. It will look like your own systems acting in ways you did not expect. That is where the next decade of security work will concentrate.