Three decades across development, product, consulting, customer success, and executive leadership is a pretty broad lens. What has that experience taught you about where cybersecurity really belongs in the business?
Exposure management currently sits under the CISO, and I think this makes sense, but the work is really shared. Security works when every team is measured on the same outcome of risk reduction, instead of counts of vulnerabilities found or patches deployed.
As COO & CSO, you sit close to strategy, product, operations, and customer outcomes. Which security issues most often find their way onto your desk, and why?
The ones that affect customer trust. As a vendor supporting core security programs, we have contractual and legal obligations to be open and proactive when something touches customers, such as a product or third-party vulnerability, an incident, or a change in our certifications. We aim to go beyond the minimum, so I focus on when and how we tell customers while the CTO and security leads handle the technical response.
When a major security incident hits, what changes for you operationally? Which consequences across customers, product, delivery, revenue, or reputation require the most immediate attention?
When a major incident hits, we see customers skip change control to get back up and running, which can leave changes that nobody documented and new exposures behind. On our side, customers come first. We make sure they hear from us early and openly. Next, we check that our product and service are still working for them, so their programs keep running. Revenue and reputation follow from how well we handle those, so I don't treat them as the starting point.
Brinqa sits in the exposure management space, bringing together different sources of exposure data. What’s still missing between knowing an organization’s exposures and knowing which ones actually deserve action?
The volume of exposures is growing quickly, partly because AI-enabled discovery is finding more of them and chaining lower-severity issues together into paths that matter. Ranking a list by CVE score no longer works. Organizations want to know what is actually reachable and exploitable in their own environment, and what the blast radius and impact on the business would be if it were used. What is missing is the context to answer those questions with confidence. We believe it starts with a high-fidelity data repository that brings together exposure, asset, identity, threat, and business information, because AI-enabled CTEM is only as good as the data under it. With that foundation, teams can prioritize, validate, and act on the exposures that carry real risk and measure success by risk reduced.
You’re responsible for strategy and operations within a cybersecurity company. How do you tell when a security capability is genuinely useful versus technically impressive but difficult to operationalize?
We design and validate our roadmap with customers and our advisory board on a regular basis, so we hear early whether something will work in practice. A useful capability fits into how teams already work, helps them reach a decision or a fix faster, and explains its reasoning so they trust it enough to act. It also has to scale. Exposure volumes keep growing, and AI needs far more processing, so something that works on a small demo data set but slows down or becomes too costly at enterprise volume is not really working. The final test is adoption. Do customers use it, and can they show that their risk went down because of it?
Security buyers hear a lot about AI-native, autonomous, continuous, risk-based, and platform approaches. Which of these ideas are worth digging into, and which can create more noise than substance?
As a vendor, all of them resonate with us, because together they describe how AI-enabled CTEM has to work. It needs continuous discovery, enrichment, prioritization, validation, and remediation, and it has to do that at scale. The noise comes from too much data and too little context. AI working on inaccurate or incomplete data gives bad recommendations, so data accuracy has to come first, and then teams can focus on fixing what really matters. We also see businesses discussing and adopting two-step remediation much more aggressively: first, what can be done quickly before a patch is available or can be rolled out, such as a control change, and then the patch itself. We expect autonomous remediation using AI agents to become far more common in the coming years.
When you enter that buying conversation as a COO & CSO, what are you looking at that the security practitioner may not be? And what do you need the technical team to prove before you take the broader business case seriously?
Practitioners tend to focus on features and detection quality, while I look at the business case around them, and it is the same advice I would give any buyer. First is interoperability: does it work with the tools and data already in place, and does it fill a gap or replace an existing solution? Second is speed to outcomes: how quickly does risk go down, and how much service effort does it take to get there? Third is the cost to operate, including AI and other processing overhead, because volumes keep growing and costs can climb faster than value. I need the technical team to prove all three on real data at real scale, and to show the results in risk reduced, not in features delivered.
Looking across your experience on both sides of the cybersecurity equation, what does a truly operationally mature security vendor look like to you?
A mature vendor gets the basics right. It is open about its own security, tells customers early when something affects them, and does what it says it will do. Beyond that, it works with customers as a partner. It spots new opportunities, builds new ideas that fill real gaps and deliver clear business results, and helps customers see what is possible so they keep improving their programs.
