Nvidia’s head of cybersecurity policy has urged security leaders to make accountability central to AI adoption, arguing that executives need to understand both the commercial stakes and who accepts the risks. Speaking at ISC2 Security Congress in Denver, Colorado, on 26 October 2026, Mark Weatherford said the expanding use of AI was changing what businesses need from their chief information security officers.
According to reporting by Infosecurity Magazine, Weatherford’s message extended beyond securing new technology: CISOs must understand how their organisations earn money and explain security decisions in that context. For UK and European organisations considering AI investments, his argument raises a governance question: whether responsibility for the resulting business exposure is as clear as responsibility for the technology.
What happened
Weatherford described a tension facing boards. Delaying AI adoption may leave a company at a competitive disadvantage, but accelerating deployment can put tools into operation before safeguards are ready or risks are understood. The security leader’s task, he argued, is to explain those competing pressures rather than treat adoption simply as a technical approval decision.
He distinguished assessing risk from owning it. In his view, the CISO rarely owns the business risk associated with an AI deployment, even though the role includes interpreting that exposure and ensuring executives know where accountability sits. That distinction matters when a decision promises commercial benefits while introducing security weaknesses: identifying a weakness does not, by itself, establish who can accept it.
To illustrate the credibility at stake, Weatherford recalled a board meeting in which a CISO struggled to connect security with the company’s business. Directors questioned the executive’s understanding of its business model. Weatherford said the exchange damaged their confidence in the CISO’s ability to protect the organisation.
His practical advice was to support investment discussions with a concise proposal setting out the work needed to reduce risk and the resources required. He also warned against spending heavily on AI merely because others were doing so, placing business due diligence ahead of pressure to keep pace with the market.
Product selection requires similar discipline. Weatherford said he favoured security products built around AI to solve a problem over established products to which AI had subsequently been added. His comments concerned how buyers judge suppliers, a related scrutiny issue explored in our coverage of oversight gaps in AI-built security tools.
The background
Weatherford identified two simultaneous demands on security teams: defending the AI systems their organisations introduce and deciding how AI can improve their own security operations. These are distinct responsibilities. A tool used by defenders still needs scrutiny, while AI deployed elsewhere in a business creates protection requirements beyond the security team’s own systems.
He argued that the speed of technological development was also straining established approaches. Calling for continuous penetration testing, he presented the frequency of security assessment as an area where organisations risk falling behind. That was his assessment of the challenge, rather than a formal testing requirement announced at the conference.
The supplier landscape adds another complication. Weatherford warned that apparently separate vendors can rely on the same underlying providers, allowing one failure to affect several products or services. Those connections may be hidden several layers below the suppliers an organisation deals with directly.
For continuity teams, the implication is that a diverse supplier list does not necessarily demonstrate operational independence. Assessing resilience requires attention to shared dependencies, not simply the number of contracts. The broader challenge of exposure beyond an organisation’s direct systems also features in our reporting on the Engie customer data breach involving partner marketing systems, although Weatherford’s warning concerned common suppliers rather than that incident.
What people are saying
Weatherford’s advice also addressed how security executives maintain their own expertise. According to Infosecurity Magazine, he encouraged CISOs to remain curious and revisit existing knowledge as technology develops, rather than assume that past experience will remain sufficient.
His suggested discipline was deliberately modest: “learn one new thing every week”. By concentrating on a single subject at a time, leaders could make professional development a regular activity rather than an occasional response to an unfamiliar technology.
He identified model context protocol, or MCP, prompt injection and sandboxing as possible starting points. These subjects cover different parts of the AI security challenge: connections between AI applications and external tools, attempts to manipulate a model through the material it processes, and restrictions on the environment in which software operates.
The distinction is useful for executives deciding what expertise they need around them. Understanding how an AI system connects to information and services is not the same as understanding how its instructions might be subverted. Equally, isolating software can limit its reach without establishing that its output is reliable. These are complementary areas of scrutiny, not interchangeable safeguards.
Weatherford also advocated professional communities, both formally organised and informal. He said he had established a CISO Exchange Network, inviting security leaders from Nvidia’s major customers, partners and suppliers to exchange practical experience, concerns and advice.
That example gives his recommendation a specific organisational setting: a forum spanning commercial relationships, rather than a discussion confined to one company’s security department. The account did not provide membership numbers or evidence of measurable improvements resulting from the network.
What happens next
The immediate follow-through suggested by Weatherford’s remarks is a sustained learning programme for security leadership. His examples offer a starting agenda, but not a prescribed syllabus or a deadline for completion. Organisations would still need to choose subjects relevant to the systems they operate.
For UK and European teams, one practical implication is to connect that learning with operational questions. Studying MCP can inform questions about which tools an AI application may access and with what permissions. Examining prompt injection can help teams consider how untrusted documents or other inputs might influence an application’s behaviour. Neither exercise requires treating every AI deployment as technically identical.
Peer exchanges introduce a separate consideration: how to share useful lessons without disclosing sensitive information. Any organisation establishing such a forum would need to decide what participants can discuss, how information may be circulated and which matters must remain within existing confidentiality arrangements. Weatherford’s reported comments did not set out rules for his network.
The next evidence to watch is therefore practical rather than rhetorical: whether these exchanges produce lessons that participants can apply, and whether regular study changes the questions security leaders ask during deployment reviews. Infosecurity Magazine’s report describes recommendations and an existing peer initiative; it does not establish their effectiveness or announce a wider implementation timetable.
