Beyond Cyber Defense: How Modern CISOs Build Trust, Govern AI, and Drive Business Value

In this latest edition of the CyberTech Top Voice Series, we spoke to Barak Blima, A Global Chief Information Security Officer at CHEQ, a go-to-market security company that helps businesses separate real users from bots, fake traffic, and malicious automation. He leads CHEQ’s global security, privacy, governance, risk, and compliance programs across its product portfolio.

Barak’s background combines cybersecurity leadership with hands-on operational security experience, including leadership roles in complex, high-pressure environments. He works closely with engineering, product, and commercial teams to build security programs that support growth while keeping risk under control. His main interests are the changing role of the CISO, AI governance, and the link between security and customer trust.

Here’s what Barak Blima shared about AI governance, cloud security, DevSecOps, cyber resilience, customer trust, and the evolving role of cybersecurity in driving business value.

The Evolving Role of the CISO

The biggest change is that CISOs are now expected to understand the business as well as they understand security.

Over the years, I’ve watched security conversations grow from a focus on protecting systems and meeting requirements into much broader discussions about business priorities, customer trust and risk. Today I’m part of decisions about customer relationships, product direction and which risks the company is willing to accept. At CHEQ, I can have one customer call that covers encryption, data privacy and contract terms in the same hour.

One thing I’ve learned is that being technically right doesn’t always mean making the right business decision. You need to understand the context, the people involved, and the business impact of your recommendation.

The strongest CISOs in the next few years will be the ones who build relationships, communicate clearly, and use good judgment when there’s no obvious answer.

Technical knowledge gets you into the conversation. Trust and judgment are what make people listen.

Cybersecurity as a Business Enabler

Security creates value when people see it as something that helps them move forward, instead of one more approval to get through.

In SaaS, security is part of the customer relationship long before a contract is signed. Enterprise buyers send detailed questionnaires and security schedules early in the process. When we answer quickly and back it up with real evidence, like a current SOC 2 report or ISO 27001 certificate, the deal moves. When we stall, the deal stalls with us. That’s why security teams should look at how they support the sales process, and not only at how many vulnerabilities they close.

Internally, I start by asking what the business is trying to achieve. Sometimes the answer is a stronger control. Other times it’s a different way to manage the same risk.

Being a business enabler doesn’t mean saying yes to everything. It means knowing when to say yes, when to push back, and how to explain the difference.

Securing Complex Cloud Environments

The hardest part of cloud security is knowing what you actually have, who owns it, and how fast it’s changing.

Cloud gives engineering teams a lot of freedom, which is good. It also means new services, permissions, and integrations can appear faster than any manual process can follow. Growing through acquisitions makes this harder, because every new team arrives with its own stack, pipelines, and habits.

I’ve found that adding more tools doesn’t necessarily solve the problem. Often you just get more alerts and dashboards without a clearer picture of risk.

So I start with the basics: clear ownership, one reliable view of assets, guardrails enforced in code rather than in a policy document, and identity treated as the real perimeter. Strong identity controls, least privilege, and regular access reviews often do more to reduce risk than adding another tool without a clear purpose.

My advice is to do a few things consistently everywhere before trying to do everything perfectly in one place.

AI Adoption and Security Governance

One mistake I see is treating AI adoption mainly as a security problem.

Teams adopt AI because it helps them. If security answers only with restrictions, people will use the tools anyway, just without telling anyone. So I start by finding out where AI is already used, what problems people are solving, and what data is going into these systems. From there, we can talk practically about approved tools, access, vendor risk, and accountability.

Traditional controls are a good foundation, but they don’t cover everything. Unreliable outputs, accidental data exposure, and too much trust in automated decisions all need their own attention.

AI agents are the newer challenge. They can take actions with real permissions, so they need the same identity discipline we apply to people. Businesses increasingly need to know whether activity on their systems comes from a person, an automated service, or an AI agent. That question is close to home for us, since it’s a big part of what CHEQ helps customers answer.

You don’t need every answer before allowing innovation. You need clear boundaries, clear owners, and a willingness to adjust as you learn.

DevSecOps and Secure Innovation

The relationship between security and engineering matters more than the number of tools in the pipeline.

Developers are measured on delivery. If security keeps adding delays, complexity, or findings that don’t matter, frustration is a fair reaction. Drop 400 findings into a pull request with no context, and people will learn to ignore them.

What works for me is getting involved early, while teams are still discussing architecture and design, instead of showing up just before release. Being selective matters too. Not every vulnerability deserves the same attention, and not every finding should block a deployment. I’d rather have three rules that always fail the build for a good reason than thirty that everyone works around.

Security champions inside engineering help a lot, because they know the code better than my team ever will.

A healthy DevSecOps culture is one where engineers bring security in early because they know it will help them make better decisions.

Resilience, Compliance, and Executive Expectations

Security reporting is often more complicated than it needs to be.

Boards and executive teams don’t need another dashboard full of technical metrics. They need to understand where the organization is exposed, whether things are improving, and which decisions need their attention.

So I keep the conversation to a few practical questions. Are our most critical services protected? Could we detect, contain, and recover from a serious incident? Are we making progress on our biggest risks? Where are we accepting risk on purpose?

Metrics like critical vulnerability remediation, incident response readiness, and tested recovery capability support those discussions. But numbers alone don’t tell the whole story, especially when business priorities and security requirements compete. I also bring a short list of top risks, each with an owner and a date. A risk without an owner is just a worry.

Compliance matters, but passing an audit should never be confused with being secure. Good reporting helps leadership make better decisions. It isn’t there to prove the security team is busy.

Looking Ahead to 2027

The biggest challenge I see for 2027 is the gap between how fast organizations adopt new technology and how fast they can understand and govern the risks.

AI is the clearest example. We’re moving from people using AI assistants to systems that access data, work inside business applications, and act with growing autonomy. That raises hard questions about identity, permissions and accountability, and about how much authority we’re comfortable handing to software.

Regulation is moving too. The EU AI Act, DORA, and new privacy laws are pushing obligations down the supply chain, so more vendors will have to prove their controls through contracts and assessments. That makes third-party risk and resilience even more important.

Beyond the technology, the leadership challenge stays the same: making good decisions with incomplete information, building trust across teams, and preparing the organization for the day things don’t go to plan.

Thank you, Barak, for sharing your insights. We look forward to speaking to you again.

For Interview inquiries, you can write to our CyberTech Intelligence team at sales@cybertechintelligence.com