You’ve built and scaled information security, privacy, and AI programmes. What is hardest about turning GRC from a framework on paper into something that genuinely shapes product, technology, and business decisions?
The standards and frameworks describe what a finished product looks like, but they don't tell you how these frameworks fit your organization. The gap between those two is where most GRC programs die on paper.
A standard is a template to be adapted, not adopted. If you pick up ISO 27001 or SOC 2 and apply it as-is, you may pass the audit, but there is little improvement to overall governance of the program. Every organization has processes and procedures, built up over years, to meet real operational needs. The control has to land inside those, not on top of them. So the discipline is to start from the objective: What are we actually trying to achieve, and what's the best way to achieve it here?
AI governance is the clearest example my team has worked on. We're certified to ISO 42001, but certification doesn't tell you how to govern engineering coding assistants, shared departmental agents, and individual productivity agents. They all have very different risk profiles. The work involves operationalizing the policy and closing the visibility gap, so we can see what's actually being used and govern that, rather than relying on assumptions.
The objective throughout is security, privacy, and governance done in a way that doesn't impede productivity or limit innovation. If your program is measurably slowing the business down, you've implemented the framework, not the intent.
With GRC spanning security, privacy, engineering, product, and legal, where does the greatest friction emerge when these teams have different risk priorities, and how do you create a shared view of risk?
Priorities differ. Engineering wants to ship. Product wants to beat the competition. Legal wants to contain exposure. Security wants all of it done safely. But I don't think that’s where the real friction is. The friction arises because each of those teams measures risk in a different unit, so there's no common denominator to debate. When that happens, the decision defaults to whoever has the nearest deadline.
Creating a shared view requires three things.
- A single register where risks are described in terms of business consequence, not control language. For instance, what could happen, to whom, with what likelihood, and bearing what it costs.
- A documented risk appetite set by executive leadership, so teams aren't relitigating the same threshold every sprint.
- A named accountable owner for every accepted risk. The moment a risk acceptance has a name rather than a team attached to it, the conversation gets much more honest.
Because risk appetite drifts as the business changes, revisit it with the executive team on a regular cadence, with all the relevant teams in the room.
Given that Fusion itself helps enterprises make decisions around disruption and resilience, does that create a different standard for how you approach security and compliance internally? If so, where is that standard most visible?
It does change how we approach security and compliance internally. Customers’ due diligence is harder on us than on a typical vendor. Our buyers are resilience and risk professionals, and they read our questionnaire responses the way I’d read a vendor’s. A generic answer doesn’t survive that conversation. So the standard isn’t just “be secure,” it’s “be able to deliver evidence on demand to an audience that does this for a living.”
If we recommend a discipline to customers and can’t run it ourselves, either the discipline is wrong, or we are. Our own program is the first test of whether the advice is workable. It prevents us from prescribing things that only work on a slide.
When comparing vendors, how do you distinguish between a platform that looks comprehensive in a demo and one that can actually fit into Fusion’s existing governance processes, data flows, and operating model?
A demo is a rehearsed performance on clean data. We prefer to use POC that employs our scenario and our data. That tells you most of what you need to know.
Before any demo and POC, we define the objective. What are the specific gaps we’re trying to close? Is this product going to close the primary ones? That ensures everyone is aligned on the actual issue we came to solve.
What does the decision-making group typically look like when Fusion evaluates a GRC platform? How much influence sits with GRC versus security, IT, legal, procurement, finance, and the teams that will ultimately use the platform?
Our procurement team consists of members from all the teams mentioned in the question.
The teams that live in the platform daily carry the most weight on whether it actually solves the problem. The process intent is that by the time a decision is made, every objection has either been resolved or is on the table and understood. The decision should be the easy part. If it’s contentious at the end, the evaluation didn’t do its job.
Lastly, if you stripped your security stack down to the capabilities that genuinely move the needle, what would you refuse to compromise on?
We won’t compromise on any control that jeopardizes the trust we’ve worked years to build with our customers. Our commitments to them carry real weight, and that trust is the asset everything else rests on. Our customers should be able to rely on Fusion for their organizational resilience without ever having to worry about our security, and they do.
