AI Is Changing the Economics of Cyber Risk.

Data Governance Must Become Resilience Infrastructure.

On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026–109618 and CVE-2026–109619. Both were rated 9.2 under CVSS 4.0 and, under the right conditions, could allow an unauthenticated attacker to execute code on a server running PHP. The PHP project considered all installations serving web requests potentially at risk and stated that updating was the only complete solution.

That mattered because PHP is not an obscure component buried in a small corner of the technology estate. It underpins a large share of the web, including commercial applications, government services and widely deployed content-management environments. The consequence of a vulnerability in infrastructure of this kind is therefore not simply technical severity; it is systemic reach.

CNBC's October 23 reporting captured the resulting wave of concern. CNBC's report on the PHP vulnerabilities. But the more important development was not that another serious software vulnerability had been found. It was how the weaknesses were surfaced and validated.

The PHP Foundation says the first signs of the problem behind one vulnerability had been identified during security work in 2024. At that stage, an exploit was theorised, but no concrete attack vector had been established. Remediation stalled amid difficult engineering trade-offs, limited specialist capacity and competing priorities, a delay the Foundation itself subsequently described as a "structural failure." In 2026, AI-assisted research and independent security work materially changed the picture. Calif reported an unconditional remote-code-execution path with the same underlying cause; OpenAI independently reported the root cause and later additional attack vectors; Wiz independently identified vulnerabilities; and AI systems were also used in validating reports and exploits.

OpenAI says Calif identified a critical PHP flaw using GPT-5.6 Sol through its Patch the Planet initiative, while Wiz independently discovered and reported both vulnerabilities. The coordinated response then brought together maintainers, researchers, infrastructure providers and government agencies ahead of disclosure.

This distinction matters. AI did not create these vulnerabilities. Nor was this principally a failure of enterprise data governance. It was a software-security event involving weaknesses in widely deployed infrastructure.

But it exposes a governance question that reaches far beyond PHP.

The economics of vulnerability discovery are changing.

Historically, finding a subtle vulnerability and turning it into a workable exploit could require scarce expertise, sustained effort and considerable time. Reuters reported security researchers describing timelines that previously ran to weeks or months, while increasingly capable AI systems can subject codebases to continuous analysis and, in some cases, shorten parts of the discovery and exploit-development process dramatically. Experts remain appropriately divided over whether more AI-discovered vulnerabilities will translate directly into more successful attacks. More findings do not automatically mean more compromises. But there is much broader agreement that the available response window is compressing.

That changes the economics of cyber risk.

The marginal cost of examining large amounts of code is falling. The number of systems that can be analysed is increasing. Capabilities once dependent on relatively scarce human expertise are becoming more scalable.

Defenders benefit: vulnerabilities can be identified earlier, patches tested more aggressively and weak points found before adversaries exploit them. Attackers potentially benefit from many of the same underlying capabilities.

This is not an argument for inevitability or alarm. It is an argument about velocity.

If organisations must assume that vulnerabilities will increasingly be discovered faster, executives need to ask a different question:

If one of our systems is compromised, what limits the damage?

That question takes us from software vulnerability management into enterprise governance.

The neglected variable: data blast radius

Cybersecurity has traditionally focused considerable attention on preventing compromise: hardening systems, managing vulnerabilities, monitoring threats and controlling identities. Those disciplines remain essential.

But no organisation can credibly assume it will eliminate every vulnerability across every application, supplier, cloud service, open-source dependency and increasingly autonomous AI environment.

The complementary executive objective is therefore to reduce the data blast radius of compromise.

Data blast radius is not simply the volume of information stored in a breached system. It is the total business exposure that becomes reachable when a trusted component fails: which sensitive data can be accessed, which systems can be traversed, which credentials or machine identities can be reused, which AI agents can invoke further actions, which suppliers are connected, and how long those pathways remain open.

This is where conventional data-governance programmes often reveal their limitations.

An organisation may have a data catalogue, stewardship committees, retention policies and classification standards and still struggle during an incident to answer basic operational questions: Where is our most consequential data? Which applications can reach it? Which machine identities have privileged access? Which AI agents consume it? Which copies exist outside primary systems? Which third parties receive it? Can we revoke those pathways in minutes, hours or only after several days of investigation?

Governance that cannot answer those questions may satisfy important compliance or data-management requirements. It is not yet functioning as resilience infrastructure.

Governance becomes real through operating discipline.

My perspective is informed not only by enterprise transformation experience, but also by hands-on involvement in developing data governance policies, role-based access controls (RBAC), and ISO 27001-aligned security practices at ZoomInfo, working alongside senior security leaders, including James Grant, now Vice President of Security and Field Chief Information Security Officer.

The enduring lesson from that experience is straightforward: good governance is not created by writing more policy. It emerges when policy is translated into ownership, decision rights, controls, escalation paths and repeatable operating disciplines around data.

That distinction is increasingly important as data, security and AI converge.

Separately from my own work, ZoomInfo announced on October 6, 2026 that its Artificial Intelligence Management System had achieved ISO/IEC 42001:2023 certification following an independent assessment by Schellman. Its public materials describe governance structures spanning accountability, AI risk and impact management, operational controls, performance evaluation and continual improvement. That later certification is a public fact; I make no claim that my earlier work caused or contributed to it. It is useful here because it illustrates the direction mature governance is taking: from static policy toward management systems with accountability, controls and continuous assurance.

The broader enterprise implication is that cybersecurity governance, data governance and AI governance can no longer operate as independent management systems.

They remain distinct disciplines. Cybersecurity governs threats, vulnerabilities, identities and defensive controls. Data governance establishes accountability, classification, lifecycle decisions and permissible use of information. AI governance governs how models and agents are developed, deployed, monitored and authorised to act.

But their operating models must intersect around a common question: what valuable enterprise resources become reachable through each system, identity and decision pathway?

The Enterprise Data Exposure Model

To make that question actionable, executives need a model that assesses more than whether data is formally "governed." I use six disciplines in what I call the Enterprise Data Exposure Model.

SEE : Visibility. Can the organisation reliably identify its critical and sensitive information across databases, documents, collaboration environments, SaaS platforms, data products and AI-accessible knowledge stores? Visibility must increasingly include the information available through retrieval systems, embeddings, APIs and context layers — not simply conventional databases.

OWN: Accountability. Does every critical data domain have a named business owner with explicit authority over access, permissible use, retention and risk acceptance? Stewardship without decision rights produces committees; accountability produces decisions.

LIMIT : Access. Is access deliberately constrained to business need across people, applications, service accounts, APIs, machine identities, AI agents and third parties? As enterprises move toward agentic operating models, non-human access becomes a first-class governance concern.

TRACE : Movement. Can the enterprise understand how sensitive information travels between applications, clouds, analytical environments, models, agents and suppliers? Traditional lineage focused primarily on data quality and analytics. Resilience requires lineage to become an exposure map.

CONTAIN : Exposure. When a component is compromised, can the organisation rapidly isolate the affected environment and restrict access to important data? Governance should be judged partly by containment velocity, not simply by whether an access policy exists.

ASSURE : Continuous Governance. Are these controls regularly tested, measured and challenged? A control last reviewed for an annual audit may be documented governance. It is not necessarily operational governance.

Together, these disciplines shift the management question from "Have we governed our data?" to "Can we understand and contain our exposure?"

That is a materially higher standard.

What CEOs and Boards should take from PHP

The lesson from the PHP incident is not that boards should become vulnerability-management committees.

It is that the objective of enterprise resilience cannot simply be to prevent every vulnerability.

The executive objective must be to reduce the probability of compromise, reduce the amount of valuable data exposed when compromise occurs, reduce the number of pathways through which that data can be reached, and reduce the time required to identify and contain exposure.

That makes data governance a business-risk discipline.

It also has consequences for enterprise architecture and operating-model design. Systems should not inherit broad access simply because integration is convenient. Data duplication should not be treated as costless. Third-party connectivity should be understood in terms of what information becomes reachable. Business-continuity planning should include the ability to operate while data connections or automated processes are deliberately severed.

Agentic AI raises the stakes further. An AI agent is not merely another user interface. Depending on its design, it may combine machine identity, data access, decision authority and the ability to invoke other systems. An enterprise that knows which employees can access sensitive information but cannot tell which agents, service accounts and machine identities can do so has an incomplete understanding of its exposure.

Boards therefore need to move beyond asking whether the organisation has an AI policy, a data-governance council or a cyber programme. The more useful question is whether those mechanisms produce a coherent view of enterprise exposure.

An executive agenda for reducing exposure

Leaders can begin by creating a common data-risk agenda across the CISO, CIO, Chief Data Officer and Chief AI Officer rather than allowing separate governance architectures to proliferate. Identify the organisation's highest-value and highest-consequence data domains, then map where those assets reside and which internet-facing applications, SaaS services, APIs, models, agents and third parties can reach them.

Machine identities deserve the same scrutiny as human identities. Review privileged service accounts and AI-agent permissions; assign explicit business ownership and decision rights to critical data; test whether sensitive access can actually be revoked during an incident; and reduce unnecessary retention and duplication so the organisation is not continuously manufacturing additional exposure.

AI governance should be connected to existing cybersecurity, privacy and data-governance mechanisms rather than becoming another committee structure. The operating model should define where decisions sit, when risks escalate and who has authority to disconnect systems or restrict data access when conditions change.

Board reporting should change as well. Instead of large compliance dashboards, directors would benefit from a small number of exposure indicators: the percentage of critical data domains with accountable owners; the proportion of sensitive data automatically classified; the percentage of critical flows with reliable lineage; the proportion of AI systems operating within approved data-access boundaries; the number of privileged machine and agent identities; the time required to revoke access to a compromised data domain; and the percentage of critical third parties for which data exposure has been mapped.

None of those metrics is perfect in isolation. Together, however, they begin to tell a Board something strategically useful: does management know where enterprise value is exposed, and can it reduce that exposure quickly?

For years, data governance was frequently treated primarily as an exercise in quality, compliance and stewardship. Those responsibilities remain important.

But its mandate is expanding.

When machines can discover vulnerabilities, interrogate complex systems and operate at unprecedented speed, the enterprise needs an equally sophisticated understanding of what its data is, where it resides, how it moves, who or what can reach it, and how quickly that access can be contained.

The organisations that develop that capability will not simply have better-governed data.

They will be more resilient enterprises.