Last week, two critical vulnerabilities in PHP, the programming language behind a substantial proportion of the world’s websites and web applications, became public knowledge. Collectively known as PHP2Shell, they created the potential for attackers to execute code remotely on vulnerable systems without needing to authenticate.
For the cybersecurity community, this was a significant technical event. Advisories were published, patches released, researchers investigated the vulnerabilities and suppliers began assessing their exposure. For business leaders, however, it should have prompted a rather different reaction. It was a reminder of just how dependent their organisations have become on technology they do not necessarily understand, systems they do not directly control and suppliers whose responsibilities may cover only a small part of the overall business.
For any CEO, CFO or COO who could not immediately identify someone capable of explaining what the emerging threat meant for their organisation, I suspect it was a rather uncomfortable few days. Not necessarily because their business was vulnerable, or because their suppliers had failed to do something, but because they suddenly needed answers to questions they might never previously have considered.
Were we at risk? Were our suppliers at risk? What did we know, what did we need to find out and what were we going to do about it?
Those questions might require technical expertise to answer, but they are fundamentally executive questions. The consequences of getting the answers wrong extend well beyond the technology itself, touching customers, commercial relationships, operational continuity, regulatory obligations and ultimately the confidence that the Board can place in the organisation’s ability to manage its risks.
What happened last week provides an excellent illustration of why organisations need someone who can connect those two worlds.
The warning before the storm
On 20 October, the PHP security team announced that two critical vulnerabilities would be addressed in an imminent security release. Both carried a severity score of 9.2 out of 10, placing them firmly in the category of issues that demanded attention. The UK’s National Cyber Security Centre reinforced the urgency surrounding the disclosure, drawing attention to the need for organisations to prepare for the release and take appropriate action.
For anyone following the cybersecurity community, particularly those who follow the NCSC through channels such as LinkedIn, this was a difficult warning to overlook. It was striking because of its timing and the level of concern being expressed before the vulnerabilities had been publicly detailed. We knew that serious weaknesses had been identified in technology used extensively across the internet, but organisations did not yet have the complete technical information necessary to establish their exposure or apply the relevant patches.
That created an unusual situation for executives. There was a credible warning that something potentially serious was coming, but no immediate way to determine whether the organisation was affected. The normal reassurance of asking someone to check that the latest patches had been installed was not yet available. Instead, the business needed to prepare to act quickly once the full details emerged.
Consider what that means for a medium-sized organisation with an outsourced IT provider, a web development agency, several business-critical SaaS platforms and perhaps a handful of bespoke applications supporting its operations. The internal IT team or MSP might be able to establish that the infrastructure under its direct management did not use PHP, or that its existing monitoring had identified no immediate concern. That would be useful information, but it would not necessarily answer whether the organisation’s customer portal, finance platform, marketing systems or other third-party applications might be affected.
Nor would it necessarily establish whether PHP was embedded within a network appliance, an integrated software component or some other system where the organisation had never consciously selected PHP as a technology.
The challenge was therefore broader than determining whether a particular server needed patching. Someone needed to understand the scope of the technology estate, identify the relevant suppliers, establish which systems were critical to the business and coordinate preparations for the disclosure. All of this had to happen while the precise nature of the threat remained uncertain.
It is at this point that the distinction between technical support and executive technology leadership becomes apparent. Individual suppliers may have been preparing perfectly appropriate responses within their own areas of responsibility, but who was bringing those preparations together to establish what they meant for the business as a whole?
Day zero: more information, but not necessarily more certainty
On 21 October, the vulnerabilities and their associated patches were published. Technical teams finally had the information necessary to understand the affected components, investigate exposure and begin remediation. In principle, this should have helped reduce uncertainty, but the disclosure also triggered a wave of additional information, analysis and speculation.
Security researchers began examining the possible consequences of exploitation, discussing different attack scenarios and investigating reports of suspicious activity. Questions emerged about the capabilities attackers might gain, the circumstances under which systems would be vulnerable and whether exploitation had already been observed in the wild. For someone without a cybersecurity background, distinguishing established facts from technically plausible scenarios or developing threat intelligence was far from straightforward.
There is an important difference between understanding that a vulnerability could allow remote code execution, observing an attempt to exploit that vulnerability and establishing that an attacker has successfully compromised a system. Each represents a different level of evidence and potentially a very different risk to the business. Yet those distinctions can easily disappear when information is being shared rapidly, particularly through social media or secondary reporting.
The evolving analysis from Palo Alto Networks’ Unit 42 provides a useful illustration. An initial report associated observed post-compromise activity with PHP2Shell, but Unit 42 subsequently withdrew that attribution because its researchers could not confirm that these vulnerabilities had provided the initial access. That change did not mean that the vulnerabilities were harmless, nor did it remove the need for remediation. It demonstrated that threat intelligence evolves as new evidence emerges and earlier assessments are tested.
For the executive team, this creates a difficult balancing act. Waiting for absolute certainty before taking action may be irresponsible, but reacting to every speculative report as though it represents a confirmed threat can be equally unhelpful. Someone needs to interpret the available evidence, understand how it relates to the organisation’s actual exposure and determine which actions are necessary, proportionate and sufficiently urgent to take priority over other business activities.
That responsibility includes knowing when the available information is insufficient to support a confident conclusion. A credible response should be able to distinguish between what has been established, what is reasonably suspected and what remains unknown, while explaining how the outstanding questions are being addressed.
Confidence does not come from pretending that every answer is already available. It comes from understanding which answers are supported by evidence, which remain uncertain and who is responsible for resolving that uncertainty.
When your customers start asking questions
While technical teams were investigating the vulnerabilities, another dimension of the incident was becoming apparent for businesses selling products or services to other businesses. Their customers were beginning to ask questions about the security of the services upon which they depended, and quite reasonably wanted to understand whether their suppliers had been affected.
For a B2B organisation, this introduces an additional layer of complexity. It is no longer sufficient to establish whether your own systems are vulnerable. You must also consider what assurances you can provide to customers, whether those assurances are supported by evidence and what information you can appropriately disclose about your infrastructure, security arrangements and third-party dependencies.
A customer might ask which versions of PHP are in use, whether the relevant patches have been installed, whether an investigation has identified evidence of compromise and whether the same assurance extends to the suppliers supporting your service. These are legitimate questions, particularly where your service processes sensitive information or forms part of a customer’s critical operating environment.
However, responding requires more than forwarding a technical statement from your IT provider. The organisation needs to establish an agreed position that combines technical accuracy with commercial judgement. It must provide sufficient detail to demonstrate that the risk is understood and being managed, while protecting commercially sensitive information and avoiding unnecessary disclosure of its security architecture. Different customers may also have different contractual or regulatory requirements, making it important to understand which information can be shared generally and which belongs within a more controlled assurance process.
A generic statement that the organisation takes cybersecurity seriously is unlikely to reassure a customer facing its own Board or security team. Equally, providing an exhaustive description of internal systems, configurations and security controls may create additional exposure without materially improving the customer’s understanding of the risk.
The appropriate response sits between those extremes. It explains the scope of the assessment undertaken, what remediation or mitigation has been completed, what the organisation’s monitoring has established and whether material questions remain unresolved. Where technical specifics are necessary, they can be provided through an appropriate assurance channel rather than being distributed more widely than required.
Just as importantly, that response needs to remain consistent across the business. The assurances provided by an account manager should reflect the position established by the technical teams, the evidence received from suppliers and any formal communications issued by the organisation. If the message changes as it passes between departments, customers are likely to become less confident rather than more reassured.
Your customer does not need to understand every technical detail of your response. They need confidence that your organisation understands the risk, has taken appropriate action and is able to substantiate the statements it makes.
This is where incident management becomes a commercial responsibility as well as a technical one.
For organisations selling directly to consumers, particularly those with connected products or services, the challenge may be even more complicated. Imagine a business with internet-connected devices deployed across thousands of customer premises. A critical vulnerability emerges in a widely used software component, and the organisation must establish whether that component exists within its products, supporting infrastructure, cloud services or third-party integrations.
If the affected component is present, the technical investigation needs to establish which products and versions are vulnerable, whether the relevant functionality is exposed in a way that makes exploitation possible and what remediation options exist. Some devices may support remote updates, while others may require customers to install firmware, change configurations or take temporary mitigating action. In some circumstances, the business may need to consider whether continued operation of an affected service is acceptable until a permanent fix becomes available.
Not every connected device uses PHP, and PHP2Shell should not be interpreted as a vulnerability affecting every IoT product. The important point is that embedded software and third-party dependencies can create exposures in places that are not immediately apparent to the organisation selling or supporting the product.
For the executive team, understanding the technical exposure is only the beginning. It also needs to establish how many customers could be affected, whether those customers can be identified, what action they might need to take and how the business will support them. There may be implications for customer service capacity, product support, contractual commitments, regulatory obligations and the organisation’s reputation. A technically straightforward update can become a substantial operational exercise when thousands of customers must be informed and supported through the process.
The response may involve product management, engineering, cybersecurity, customer operations, communications, legal advisers and external suppliers, each with legitimate responsibilities and expertise. Someone must coordinate those contributions, resolve competing priorities and maintain a coherent understanding of the risk and the business response.
Day one: the suppliers respond, but what have they actually told you?
By 22 October, organisations were beginning to receive more substantive information from suppliers. The responses could vary considerably, both in the level of detail provided and in the confidence they offered.
At one end of the spectrum were statements explaining that no issues had been observed, or that an investigation was continuing. At the other were detailed explanations confirming where PHP was used, which components had been assessed, which versions had been installed, when remediation had been completed and what monitoring or investigation had established about possible exploitation.
Both responses might have been truthful, and both suppliers might have been acting entirely responsibly. However, they provide very different levels of assurance to the business relying upon them.
A statement that a supplier has not observed any issue may simply mean that nobody has reported a problem. It does not necessarily establish whether the supplier is vulnerable, whether its systems have been examined, whether appropriate monitoring exists or whether any remediation has taken place. Without that supporting information, the organisation receiving the statement cannot determine how much confidence to place in it.
By contrast, a supplier that explains the scope of its assessment, identifies affected components, confirms remediation to the appropriate fixed versions and describes the monitoring or investigation undertaken provides a much stronger foundation for decision-making. Even then, the limits of that assurance must be understood. Applying a patch does not prove that a system was never exploited, and an absence of detected compromise does not establish that compromise was impossible.
The difficulty becomes greater when an organisation is dealing with several suppliers, each responding at a different level of technical detail and with different degrees of completeness. A collection of individually reasonable statements does not automatically provide a coherent picture of the organisation’s exposure. Someone needs to assess whether the responses address the questions that matter, identify where evidence remains insufficient and determine which outstanding issues require further investigation or escalation.
That assessment then becomes the basis for the organisation’s own decisions and communications. It influences whether additional controls are necessary, whether particular services require attention, what the executive team should be told and what assurances can legitimately be provided to customers.
An organisation cannot credibly offer its customers a greater level of assurance than the evidence available to it supports.
This is the essential connection between supplier management, incident management and executive accountability. The organisation remains responsible for understanding the risks it has accepted, even when the technology and services involved are provided by others.
Your MSP may be doing an excellent job, and you may still have a problem
I want to be particularly clear that none of this is intended as criticism of managed service providers. A competent MSP should understand the systems it manages, respond to relevant threats, investigate potential exposure and provide appropriate technical guidance within its contracted responsibilities. For many small and medium-sized businesses, an effective MSP is an essential part of maintaining reliable and secure technology services.
However, the responsibility of an MSP is not necessarily the same as the responsibility of a CIO.
Your MSP may have no contractual relationship with the finance platform selected by your CFO, the CRM implemented by your sales team, the website maintained by a digital agency or the specialist SaaS products used by individual departments. It may not manage the connected products you sell to customers or have visibility of third-party integrations introduced by application owners. In some cases, it may not even know that those systems exist.
That does not make the MSP ineffective. It means that the supplier’s view of your organisation is limited by the services you have engaged it to provide and the responsibilities you have agreed.
The problem arises when the executive team assumes that outsourcing IT support has also transferred executive responsibility for technology across the business. It has not. Your suppliers may each be performing their contracted responsibilities effectively, while significant gaps remain between those responsibilities.
Someone still needs to understand the overall technology estate, its business dependencies and the relationships between its suppliers. Someone needs to establish priorities when competing technical demands arise, determine which risks require executive attention and ensure that information from different sources is sufficiently complete and consistent to support informed decisions.
In larger organisations, that responsibility usually belongs to an established technology leadership function, supported by internal teams and specialist advisers. In smaller and growing businesses, it often falls to the CEO, CFO or COO, sometimes without the available time, technical background or supplier relationships necessary to perform the role effectively.
This is where an experienced fractional CIO can make a material difference.
The value is not in replacing the MSP, conducting every technical investigation or claiming expertise in every application the organisation uses. It is in providing executive technology leadership that connects those individual activities, establishes accountability and ensures that the technical response is aligned with the needs of the business.
A fractional CIO who already understands the organisation, its critical systems, supplier relationships and commercial priorities is better positioned to coordinate the relevant specialists, challenge incomplete assurances, identify material gaps and present the executive team with a consolidated view of the situation. They can distinguish matters that require immediate technical action from those that demand a commercial or operational decision, ensuring that neither is overlooked.
Importantly, that understanding should be established before an incident occurs. The middle of a crisis is not the ideal time to discover that nobody knows which supplier manages a critical application, who is authorised to instruct that supplier or whether the organisation has an effective route for escalating a security concern.
Fractional leadership should not be confused with an around-the-clock incident response service. The business still needs appropriate operational monitoring, security expertise, support arrangements and escalation procedures. The role of the fractional CIO is to help ensure that those capabilities work together within an operating model that provides clear ownership, appropriate authority and a reliable basis for executive decision-making.
The distinction matters because the organisation is not simply buying additional technical capacity. It is establishing a leadership capability that may otherwise be missing.
The next incident may already be developing inside your business
PHP2Shell provides a particularly visible illustration of the risks that arise from third-party technology dependencies, but I think there is another lesson here that will become increasingly important as artificial intelligence becomes embedded in everyday business applications.
You may not be developing AI yourself. Your business may never have commissioned a machine learning project, employed a data scientist or formally approved the deployment of an autonomous agent. Nevertheless, it is increasingly likely that AI functionality is being introduced into the software your organisation already uses.
CRM systems, finance platforms, HR applications, customer service tools and productivity suites are incorporating AI capabilities through their normal product development cycles. Some provide relatively contained assistance, such as summarising information or preparing content, while others can retrieve data from connected systems, initiate workflows and take actions with varying degrees of autonomy.
The boundary between software that supports a human decision and software that makes or executes that decision is becoming increasingly important. So too is the distinction between an application using AI internally and an AI agent operating across multiple business systems with permissions to access information or perform activities.
Consider an agent embedded within a trusted enterprise application. It might retrieve customer information from the CRM, access documents held in another platform, interact with an external model provider and use a connected service to complete a task. Each component may be provided by a reputable supplier, and each may operate in accordance with its technical design, but the combined capability can create dependencies and risks that the organisation has never consciously assessed.
Who understands the information that agent can access, the permissions it has been granted and the circumstances under which it can act? Who has determined whether those permissions are appropriate for the business process involved, or whether sensitive information may be exposed to another supplier as part of the activity? What happens if the agent processes malicious instructions embedded in an email or document, a connected service is compromised or a software update materially changes the capability available to its users?
These are not necessarily conventional software vulnerabilities. An agent may be behaving exactly as its developer intended, while exercising permissions or taking actions that the organisation never intended to authorise. A business can therefore acquire new technology risk without anyone in its executive team making an explicit decision to acquire new technology.
The parallels with last week’s events are difficult to ignore. If an issue emerges involving an AI capability, the organisation will still need to establish whether it is affected, which suppliers and systems are involved, what information or operations might be at risk and what immediate action is appropriate. It may need to suspend an integration, restrict an agent’s permissions, investigate historical actions or contact customers whose information has been exposed.
The complexity is that the activity may span several applications, external services and business functions, with responsibility distributed across suppliers and internal teams. Each individual participant may be able to explain its own component, while nobody can explain the complete chain of activity or take responsibility for coordinating the response.
For your customers, the distinction between an internal application, an external model provider and a third-party integration is unlikely to be particularly meaningful. Their concern will be what happened to their information, what consequences they may face and what your business intends to do about it. The fact that several independent suppliers contributed to the service does not remove your organisation’s accountability for the outcomes it delivers.
This is why AI governance cannot be reduced to an acceptable-use policy or delegated entirely to a technical team. It requires visibility of the AI capabilities operating within the business, clarity over their purpose and authority, controls appropriate to the risks they introduce and an understanding of how incidents will be identified, investigated and managed.
The business executives responsible for individual processes remain accountable for the outcomes of those processes, including where AI is involved. The CIO, whether permanent or fractional, is well placed to coordinate the technology governance, supplier assurance and incident management arrangements that allow those executives to discharge their responsibilities.
This is not an argument for creating unnecessary bureaucracy around AI adoption. It is an argument for making sure that new capabilities are introduced with an understanding of what they do, what they depend upon, what risks they create and who has authority to control them.
Confidence is built before the incident
Looking back at last week, the important distinction between organisations was not simply whether they used PHP or whether they were ultimately affected by PHP2Shell. It was whether they possessed the capability to understand their potential exposure, coordinate an appropriate response and communicate a position supported by evidence.
An organisation with an established understanding of its technology estate, clearly defined supplier responsibilities, effective incident procedures and accountable executive technology leadership would still have faced uncertainty. It would still have needed specialist technical expertise, waited for suppliers to respond and assessed developing threat intelligence. It might still have discovered weaknesses that needed remediation or gaps in its understanding that required attention.
The difference is that it would have had an established means of managing those uncertainties.
Compare that with an organisation where the CEO first learns about the issue through LinkedIn, asks the finance director to contact the MSP, discovers that the MSP does not manage the website and then spends the following two days identifying who owns the other systems. That organisation might eventually reach precisely the same technical outcome, with every relevant patch applied and no compromise identified. However, the route to that outcome would have depended on hurried discovery, improvised coordination and decisions made without a reliable overall picture of the business.
Both organisations might ultimately be safe. Only one began from a position of control.
This is one of the strongest arguments for establishing executive technology leadership before the organisation believes it needs it. The benefits are often least visible when everything is working as expected, because competent suppliers, clear responsibilities and effective governance can make technology feel almost effortless. Their real value becomes apparent when the business needs to make decisions quickly, particularly when the information available is incomplete and the consequences of getting those decisions wrong may be significant.
For some organisations, that leadership requires a permanent CIO and a supporting technology function. For others, particularly growing businesses with increasingly complex technology dependencies but insufficient scale to justify a full-time executive appointment, a fractional CIO can provide a proportionate and effective alternative.
You may already have excellent suppliers and a capable internal team. You may have invested appropriately in cybersecurity, resilience and support. None of those investments removes the need for someone who understands how the individual capabilities fit together, identifies the gaps between them and connects technical decisions to the organisation’s commercial priorities.
The objective is not to eliminate uncertainty or guarantee that an incident will never occur. Neither is realistic. It is to ensure that when uncertainty arises, the organisation has the leadership, information and relationships necessary to respond coherently, take proportionate action and make decisions with confidence.
What did last week tell you about your business?
If PHP2Shell did not affect your organisation, that is a good outcome. If your suppliers responded quickly, provided meaningful assurances and addressed any exposure, that is encouraging too. But I would encourage every CEO and Board to think about what actually happened between the initial warning and the point at which the organisation felt comfortable that it had responded appropriately.
Was it immediately clear who needed to assess the potential exposure and which suppliers should be contacted? Did someone have an overall view of the business, rather than simply collecting individual responses? Were incomplete assurances recognised and challenged, and could the organisation distinguish between confirmed facts and matters still under investigation? When customers started asking questions, was there a consistent, evidence-based position that could be communicated without unnecessarily exposing commercially sensitive information?
Most importantly, who was responsible for coordinating the whole exercise, and who was able to explain the outcome to the executive team?
If those questions have reassuring answers, your organisation probably has some useful foundations in place. If they do not, it is worth considering whether the issue lies in the individual technologies and suppliers you use, or in the absence of an effective operating model connecting them.
The answer is not necessarily another security product, another assessment or a different IT supplier. It may simply be that the organisation needs stronger executive ownership of technology and the risks associated with it.
The next event might be another critical software vulnerability. It might involve a compromised SaaS supplier, a major service outage, an embedded component in a connected product or an AI agent behaving in ways nobody anticipated. The technical details will change, and the people best equipped to resolve the immediate problem may be different every time.
The executive questions, however, will remain remarkably consistent. What do we know? What does it mean for our business? What are we doing about it? And who is accountable for ensuring that the right decisions are made?
At DigitalTeddy, I work with CEOs and Boards to connect technology, business risk and executive decision-making. Through fractional CIO leadership, technology assessments and Board advisory support, I help organisations understand their dependencies, establish accountability and turn uncertainty into informed action.
If last week’s events left you wondering who would coordinate the response in your organisation, that is a conversation worth having before the next incident arrives.