Anthony Hines · July 2026
Some of the smartest product teams in the business are stuck in the same maddening place right now. They have built a genuinely innovative product that does something nobody else can do. They are backed by funding and have proven their value. Their customers' innovation teams love it, their customers' engineering and security teams love it, and it has a stack of security certifications. The trouble is, no top-tier regulated financial services customer can buy it as it stands. Not because anyone doubts what the product can do, but because between the enthusiasm and a purchase order sits third-party risk review, asking questions that neither the pitch nor the certifications have answered.
Nobody on the buyer side is questioning the core security of the product; the ISO 27001 is real, the SOC 2 came back clean, and the technical credibility was proven. The question the review is actually asking is whether the product can operate inside an enterprise environment at scale, and whether the team behind it understands the constraints their biggest potential customers face. What stalls the deal is rarely a core capability, it is a missing awareness of what running the product inside a highly regulated institution actually takes.
When the deal reaches that review, what arrives is usually a spreadsheet with a few hundred questions in it, and vendors tend to read it as bureaucracy, understandably, because they are holding their certifications in one hand and a clean penetration test in the other, so the diagnosis must be that banks are slow and risk people enjoy saying no. I spent twenty-five years on the buyer side, in both engineering and risk management, and can safely say that diagnosis is wrong.
I learned this first from the engineering side, running network security product engineering at a tier-one global bank at a time when the accountability regimes that followed the accounting scandals were beginning to reach into the technology estate. Sarbanes-Oxley was the name on everyone's lips at the time, and what it meant in practice was that controls which had once been a risk-informed choice were suddenly mandatory and had to be provable.
So we went out to our vendors, established companies whose products already sat in many large enterprises, asking for capabilities they had never been asked for before. We needed to prove hard segregation of duties was encoded into system entitlements. Every change made to a system now had to be checked against an explicit change request that had pre-approved it. Every entitlement to a system had to be periodically reaffirmed. Feeding that machinery became a hard gate and a product that could not do it meant declaring exceptions to policy, explicit risk sign-offs by somebody who could be held to account and a series of representations at governance forums that nobody much enjoyed.
None of these products were broken. Alongside the innovators, many were already well-known and industry-leading names with solid products, but they were built for a world that had not yet asked these questions, and answering these questions required earning a slot on the vendor's product roadmap at a time when none but a few of the biggest and most scrutinised financial institutions were asking them.
Years later, having moved around the cyber security disciplines including risk governance, second-line risk management and third-party cyber assurance, I witnessed the expectations evolve, driven in large part by ever tightening regulations around the globe as regulators responded to increasingly severe cyber attacks, and the realisation of just how interconnected and interdependent the world had become.
The questions that seemed bureaucratic are now standard content in any serious due diligence review, and many of them are as much about operations as they are about security. Can roles be built that separate the people who design from the people who operate, and both from the people who audit? Does provisioning ride on the customer's identity systems, so that when someone leaves, their access is cut everywhere and all at once? When the product changes, does the customer get the notice their own change process needs, and can they see and control what the vendor's administrators can do inside their environment? What happens if the service fails, how would the client's operations centre know, and what's the exit plan? None of this appears on a certificate the product can earn, because the certificate describes the vendor's own controls rather than life inside the buyer's control environment.
It's also not good enough that the controls exist. Controls need to be demonstrable to second line risk teams, internal audit, external auditors and regulatory supervisors and now even to the clients of financial services that deem their dependency significant enough. The controls not only have to work, but you have to be able to prove they were working at three-twenty-six in the morning on a Tuesday last February and the report that proves it has to also prove itself so a reviewer doesn't have to take somebody's word for it. The stakes are higher for security products, because the product is itself a control in the financial services firm's framework, and a security control that cannot produce verifiable evidence of its own operation is, from an assurance point of view, a blind spot with a dashboard.
One reason regulated financial institutions hold the line so firmly is because the people making the decision are increasingly personally accountable for it. In the UK, the senior managers regime attaches named individuals to the firm's control failures, and boards are now being asked to declare the effectiveness of their material controls under the corporate governance code. The EU's operational resilience regulation writes technology risk into law and reaches through firms into their ICT providers, and through those providers into the providers behind them. Regulated financial institutions are now required to keep registers of who depends on whom and their contracts for critical services must carry precise and quantitative service commitments.
From the technology vendor's side all this machinery has been largely invisible, so the financial firm's position reads as temperament, but from the inside it is the inevitable consequence of having a named executive who must stand behind a declaration that the firm's controls are effective, an obligation that reaches through the supply chain. A product that cannot evidence its own operation is a personal risk that someone is being asked to carry, and rejecting it is not pedantry but self-preservation.
So the advice I find myself giving technology companies now, the innovators and the established names alike, is the advice I was giving the first wave years ago, only now nobody has to go first. The requirements are knowable and are expressed in the published regulatory documentation of multiple jurisdictions and encoded into modern control frameworks, and they are remarkably consistent, because they flow from the same basic obligations everywhere. Build the operating machinery in from the start, the roles that separate duties, the integration with the identity and change systems the buyer already runs, the evidence that carries its own provenance, and the wall to your next big customer or renewal becomes a doorway, while leaving it until the deal means building it anyway, one discussion at a time, on a ticking clock, with the growth forecast attached.
Enterprise readiness is an architectural discipline, not a certificate or a tick-box exercise, and the products that treat it as a discipline do more than clear procurement faster. They become the products that the institutions trust, and trust is not a feature a competitor can ship.