The CISO Who Says No is Toast

Cheryl Martin is the executive for cybersecurity at C86 and formerly the VP and head of cybersecurity at Capgemini UK, where she led more than 350 cyber specialists across regulated sectors. Before that she served as global head of IT risk at HSBC, navigating 45 global businesses with 45 different risk appetites inside one governance structure. She is recognized in the 2026 Most Inspiring Women in Cyber Award and speaks regularly at the International Cyber Expo on cyber leadership in technical environments. This conversation is about the CISO's role when the organization is mid-transformation — and security can either lead that change or become the friction point that drives shadow adoption underground. 

Cheryl's core argument is straightforward: the CISO who says no is finished, but so is the CISO who waves everything through. What's needed is a governed framework — a known duck — that lets the business move fast on AI while keeping data classification enforced, model risk understood, and regulatory exposure visible. She walks through five areas every security leader needs to pressure-test right now: data risk policy, model risk, security risk (including supply chain), governance of use cases, and the regulatory horizon. The episode is for CISOs and senior security leaders who are being asked to enable AI transformation while simultaneously undergoing their own — and who are doing both in real time, without a playbook.

The regulatory environment is piling personal liability onto CISOs at exactly the moment when the business is moving fastest. NIS2, DORA, GDPR, and the SEC's expanding cyber rules all point in the same direction: security leaders own consequences now. That pressure creates a perverse incentive — don't admit you don't have an answer, because admitting gaps is a liability. But Cheryl's read is the opposite. The CISO who reflexively blocks AI adoption doesn't eliminate the risk; they move it underground.

The duck framework she built at HSBC was a direct response to scale. With 45 global businesses, an eight-to-nine hour risk committee meeting was the norm — every function arguing its priorities, every region with a different appetite. The solution wasn't to adjudicate every case individually. It was to define what an acceptable risk looked like, trademark that shape, and let anything that matched it through without friction. Anything that didn't match came back for review. The principle transfers directly to AI adoption: define your duck, make the criteria explicit, and stop treating every new tool as a one-off negotiation.

What Cheryl is seeing now across clients is that the failure mode isn't reckless adoption — it's the absence of any defined model. Organizations are telling her they want to give Claude access to all their capabilities. Some of them are in regulated sectors in the UK. The risk isn't that they're using AI; it's that they haven't decided what their duck looks like, so they have no basis for saying yes or no to anything. 

Cheryl laid out a five-part framework for where security leaders need to focus their attention when their organization is adopting AI at scale. It is not a checkbox compliance list — it is a set of questions that need a documented answer before an incident forces the conversation. 

First: data risk policy. What data is classified at what level, where can it go, and is that actually enforced? For critical national infrastructure providers on either side of the Atlantic, anything top secret never enters a public model — but most organizations haven't drawn those lines explicitly, and they haven't tested whether the lines hold.

Second: model risk. What does the duck look like for an AI model? What level of bias is acceptable? What's the organization's position on hallucinations, and how will it explain them if regulators ask? The EU AI Act and the UK's incoming Cyber Resiliency Bill are creating accountability for these answers whether organizations have them or not. 

Third: security risk in the new threat environment. Deepfakes are now sophisticated enough that phishing is genuinely hard to identify. Supply chain exposure through third-party AI use is largely unmonitored. And the speed of exploitation has compressed to the point where the old response playbook is structurally too slow.

Fourth: governance of use cases. The eight-hour committee meeting is gone, but documented governance of which AI use cases the organization has explicitly approved — and which it hasn't — is more important now than it was in the cloud era. If a use case isn't in the governance log, it's unmanaged exposure.

Fifth: regulatory horizon. NIST, DORA, GDPR, NIS2, the SEC's expanding rules, the UK Cyber Resiliency Bill — the regulatory environment is not static, and CISOs who are only managing to today's requirements are already behind.

One of the cleaner moments in this conversation was Cheryl's framing of shadow AI as "cottage industries." It sounds polite. It is not a soft concern.

The pattern she's describing is identical to what happened with cloud. A security team draws a hard line. The business, under pressure to move, finds a way around it — a team here, a workflow there, a personal account being used for company documents. The difference with AI is the data exposure surface. When an engineer puts a proprietary codebase into a public model to speed up their work, they are not being malicious. They are doing their job. The risk doesn't care about intent.

Stuart's point about vibe coding landed here too — Sysdig's data from RSA showed 65% of developers regularly using AI-assisted coding. You cannot put brakes on that without losing your best people or pushing the behavior somewhere you can't see it. The governance answer isn't a blanket policy; it's a tiered framework. Red: never. Green: proceed. Yellow: get approval. The organizations that will manage this well are the ones that have made those tiers explicit, communicated them, and built the monitoring to see where the lines are actually being crossed. 

Most executives have one transformation job right now: take their own function from traditional to agentic. The CISO has two. They have to run their own security organization's transformation and simultaneously serve as a guide and guardrail for everyone else's.

Cheryl's observation about where advanced security leaders are succeeding is worth sitting with. It's not the ones with the biggest budgets or the most sophisticated tooling. It's the ones who are asking better questions — why are we doing this, what's the objective, what's the change we're actually trying to make — early enough in the transformation process that security can shape it rather than react to it. Too often, security is the last team to be briefed on a major change. Bringing the security perspective in at the start, when the architecture decisions are still open, is categorically different from inheriting a deployed system and trying to harden it after the fact.

The conductor analogy she closes with is exactly right for this moment. The CISO's job isn't to play every instrument. It's to know the score, know when to bring the percussion in and when to let the flute carry it, and hold the ensemble together through the tense passages. That requires knowing what each section of the orchestra is actually capable of — which is the argument for reverse mentoring. The 25-year-old security engineer who spends 100% of their time on AI red teaming knows things the CISO doesn't. Going to them and asking to be taught is not a weakness. It builds the trust the CISO needs when they have to ask that same engineer to move fast under pressure. 

The aviation industry shares near-misses across competitors because the alternative — competing on safety outcomes while hiding failures — produces crashes. Cybersecurity doesn't have that norm, and Cheryl thinks it should.

The gambling sector example she gave is underappreciated. CISOs across competing organizations sharing threat intelligence before a major sporting event — not because they like each other, but because a successful attack on one of them during the World Cup is bad for all of them. That's the logic, and it works. The mechanism is closed user groups operating under Chatham House rules: what's shared in the room stays in the room, attribution is stripped, and the substance — what happened, what nearly happened, what the organization would do differently — gets shared freely. 

The honest version of the personal liability problem cuts both ways. Yes, the SEC and NIS2 create incentives for CISOs to not publicly admit gaps. But within a trusted peer group, the calculus is different. The CISO who shares a near-miss in a closed forum isn't creating legal exposure — they're building the collective intelligence that makes the whole sector harder to attack. The sectors where this happens are materially more resilient than the ones where it doesn't. That's not an abstraction; it's visible in the incident data.

Guests — Cheryl Martin, executive for cybersecurity at C86; formerly VP and head of cybersecurity at Capgemini UK (350+ cyber specialists across regulated sectors); formerly global head of IT risk at HSBC; recognized in the 2026 Most Inspiring Women in Cyber Award; recurring speaker at International Cyber Expo.

Books mentioned — Black Box Thinking by Matthew Syed (referenced via Simon Sinek attribution in conversation, though the concept originates with Syed).

Frameworks / models / tools named — NIST Cybersecurity Framework; NIS2; DORA; GDPR; UK Cyber Resiliency Bill; SEC cyber regulations; EU AI Act (implied via regulatory horizon discussion); Chatham House Rules; SANS training; Cloud Security Alliance frameworks; Claude; Copilot; Gemini; ChatGPT; Claude Code.

Other people / shows / resources referenced — Simon Sinek (black box thinking); Stuart Mitchell (co-host); Sysdig (sponsor; RSA data on 65% of developers vibe coding); RSA Conference presentations referenced generally.