You’ve worked across security, data engineering, and IT, with problem-solving at the center of your role. How has that combination shaped the way you look at cybersecurity today?
Working across these three disciplines taught me to see them as reinforcing one another. Security brings a mindset of proof: what you say you do, what you actually do, and whether you can demonstrate it. IT supports that with tooling that makes the secure path the easy one and the risky path a little harder. Data engineering closes the loop by measuring results, so we can establish a baseline, track continuous improvement, and keep refining the program as it matures.
iManage deals with highly sensitive documents, emails, business content, and communications across more than 65 countries. From your seat as CIO, what makes protecting a knowledge-work environment particularly challenging?
Our customer-facing platform is where security attention naturally concentrates, and it’s where our protections are strongest. As CIO, though, I’m responsible for everything around it: the infrastructure, the people working on it, our business systems, and even facilities and physical security. The challenge is carrying that same security mindset all the way “to the walls”, so it isn’t sacrificed for the speed of innovation.
As CIO, you’re balancing security with availability, productivity, user experience, and business continuity. When a stronger security control creates operational friction, how do you decide where to draw the line?
This is my everyday life! My approach is to make the right thing easier to do and the wrong thing a little harder, steering behavior in the right direction. Where to draw the line is always debated, and ultimately, it’s risk-based. I’m constantly asking whether a control adds friction for something low-risk, or whether my time is better spent reducing friction around a higher-risk area so it’s properly covered.
Security teams can end up managing a very crowded stack. From your perspective, what separates useful security depth from tool sprawl? And when does adding another tool actually make the environment harder to secure?
Useful depth comes down to two questions: does the tool fill a gap we can’t currently see, and does that visibility drive action? If it doesn’t change behavior, or we lack the capacity to act on what it reveals, it’s sprawl. Every new tool spreads our people across more dashboards, and when attention is diluted, overall security weakens. Rather than chasing the best module for every function, I focus on integrating the tools we already have and optimizing the stack as a whole system.
You’ve advocated combining AI governance with agent discovery tools and purpose-built guardrails. What does that look like in practice, and where should organizations start to make agents useful without letting them operate beyond their intended boundaries?
Agent discovery and AI governance tools are maturing fast, but I’m not yet confident any of them is where it needs to be. Most people test an agent by asking whether it does what they want; I ask whether it’s definitely not doing what I don’t want, and how I can prove it. That starts with process and data governance, clearly defining the use case, the process the agent will perform, and the systems and data needed to accomplish the task. Additionally, it is important to ensure minimal use principles are applied so the necessary access is explicitly limited to what is needed to complete the task.
Two vendors can look almost identical on a feature sheet. What starts separating them for you then? How do you weigh integration effort, implementation risk, time-to-value, scalability, and ongoing operational overhead?
I look first at security control frameworks such as ISO, SOC 2, CSA, or FedRAMP, along with backup, recovery, and logging capabilities. Vendor strength matters too, since a smaller vendor raises more resiliency concerns and puts more weight on our own failover plans. Integration depends on the use case: for instance, HR or finance data that must be 100?curate may call for deterministic API connectors, while directional needs may be well served by an MCP connector. And I ask every vendor for their implementation plan, team, and timeline up front, because time to value slips easily, and paying for a tool that delivers nothing for six months is frustrating.
Security sees strong protection, IT sees deployment complexity, and procurement sees a good commercial deal. How do you bring those different perspectives into one buying decision?
I don’t make that call alone. I bring the experts together: third-party risk management from our security team, IT on how the solution will be managed and rolled out, and procurement on commercial value. We hash out the pros and cons to reach an optimized recommendation, then vet that with the business owner of the application. I see my role as creating the forum where those perspectives resolve into one decision.
Looking back at the full journey – from identifying a security problem to deploying a solution – what ultimately gets the decision moving, and what tells you that the investment delivered real value rather than simply adding another product to the stack?
What gets a decision moving is clearly articulating the outcomes: what value the solution will deliver, what symptoms it will fix, and what life looks like once it’s fully operational. Just as important is defining how and when we’ll measure those outcomes, with checkpoints built into the plan from the start. Pairing objective metrics with a qualitative sense of how life is better means we aren’t looking back a year later, wondering whether it was worth it. When expectations are documented up front, judging the investment becomes straightforward.
