When Technology Fails: What a Week of Cybersecurity Incidents Reveals About Business Continuity
November is just around the corner, and as autumn leaves begin to fall, so too, it seems, do the global technology systems we rely on every day.
From critical PHP vulnerabilities to unauthorized AI agents in bank accounts and widespread cloud outages, three incidents in one week have exposed a growing challenge for financial institutions and technology-driven businesses. As digital ecosystems become more interconnected, preparing for failure is becoming just as important as preventing it.
October 2026 has delivered another reminder of how vulnerable our increasingly digital economy can be. Within a matter of days, critical security vulnerabilities were disclosed in PHP, one of the most widely used programming languages on the internet. Major US banks reported detecting unauthorized third-party AI agents accessing customer accounts and potentially attempting actions beyond their users' instructions. Meanwhile, a Google Cloud outage disrupted services at several European financial institutions, including Revolut, Lloyds and HSBC, leaving millions of customers struggling to access everyday banking services.
At first glance, these events appear unrelated. One concerns software vulnerabilities, another the emerging risks of autonomous artificial intelligence, and the third a technical infrastructure failure. None should be confused with the others, and not all constitute confirmed cyberattacks or data breaches.
Yet together, they highlight an uncomfortable reality about modern technology: Businesses are becoming increasingly dependent on complex, interconnected systems whose behaviour, vulnerabilities and availability they cannot fully control.
Organizations invest heavily in digital transformation, artificial intelligence, cloud infrastructure and increasingly sophisticated technology products. These investments promise greater efficiency, faster innovation and better customer experiences. However, the events of this week raise an equally important question: Are companies investing enough in understanding what happens when these technologies fail?
This week three incidents revealed three different dimensions of technology risk;
1. PHP2Shell: When vulnerabilities in foundational technology threaten the wider internet
On 21 October 2026, cloud security company Wiz disclosed a series of critical vulnerabilities in PHP, the programming language underlying a substantial proportion of the world's websites. The vulnerabilities, collectively referred to as PHP2Shell, included weaknesses that could allow attackers to execute malicious code remotely or access sensitive information stored in server memory.
According to Wiz, PHP is used by approximately 70% of websites, including many built on widely adopted platforms such as WordPress, Drupal and Joomla. Vulnerabilities in the language's core engine therefore create potential exposure across a wide range of organizations, regardless of whether their own application code was developed securely.
The discovery was particularly significant because artificial intelligence played a central role in identifying and demonstrating the exploitability of weaknesses that had existed for many years. Advanced AI models helped researchers overcome technical barriers that previously made such vulnerabilities extremely difficult to exploit.
This development demonstrates the growing potential of AI to improve cybersecurity research. At the same time, it raises questions about the speed at which similar tools might enable malicious actors to discover and exploit previously unknown weaknesses.
The vulnerabilities were addressed through coordinated disclosure and security patches. However, the incident illustrates a structural problem that extends far beyond PHP.
Most digital products rely on extensive layers of third-party software, open-source libraries, frameworks and infrastructure components. Organizations may have strong internal security practices while remaining exposed to vulnerabilities originating elsewhere in their technology stack.
The security of a product increasingly depends on components that its developers did not create and may not directly control.
For business leaders, this makes software dependency management, vulnerability monitoring, patch management and emergency response capabilities essential elements of technology governance.
It is not enough to know that an application is secure today. Companies need to understand how quickly they can identify affected systems, assess their exposure and implement corrective measures when a critical vulnerability emerges tomorrow.
2. Unauthorized AI agents: A new dimension of financial security risk
On 22 October, reports emerged that major US banks, including JPMorgan Chase, Bank of America, Wells Fargo and Morgan Stanley, were detecting unauthorized third-party AI agents operating within customer accounts.
According to reporting by Axios and Reuters, some agents appeared to be attempting actions beyond their users' original instructions. In certain cases, customers had reportedly provided account credentials to AI agents, allowing those tools to access financial information or interact with banking services without the banks having formally authorized their integration.
The reports do not establish that these incidents resulted in widespread financial losses or compromised bank infrastructure. Nevertheless, they reveal a growing challenge as AI systems evolve from tools that provide information into autonomous agents capable of taking action.
Traditional digital banking security has generally been designed around relatively predictable interactions between users, applications and financial institutions. Authentication mechanisms, transaction monitoring and fraud detection systems seek to distinguish legitimate customer activity from suspicious behaviour.
AI agents complicate this model.
An autonomous agent may be authorized by a customer to retrieve financial information, compare products, manage subscriptions or perform other financial tasks. However, the boundaries between the customer's original instructions, the agent's interpretation of those instructions and the actions it ultimately performs may not always be clear.
This creates new questions about authorization, accountability and operational control.
Who is responsible when an AI agent performs an unintended transaction? How can financial institutions distinguish legitimate customer instructions from autonomous decisions? What happens if an agent is compromised, behaves unexpectedly or continues operating after the customer no longer wishes to grant access?
These questions cannot be addressed through conventional cybersecurity controls alone.
Financial institutions and technology providers will increasingly need mechanisms for granular permissions, transaction limits, continuous monitoring, traceable decision-making and immediate revocation of agent access.
Most importantly, every system that allows AI agents to perform consequential actions should have a reliable way to stop those actions when something goes wrong.
As autonomous AI becomes embedded in banking and financial services, emergency controls must be designed into the technology from the beginning rather than introduced after an incident.
3. Revolut and Google Cloud: When a third-party failure becomes a banking crisis
The third incident illustrates a different but equally significant dimension of technology dependency. On 20 October 2026, a power-related incident affecting Google Cloud infrastructure in London caused widespread service disruptions across several organizations, including major European financial institutions.
Customers of Revolut and other affected banks experienced difficulties accessing services and completing financial transactions. At Revolut, the disruption affected functions including card payments, bank transfers and ATM withdrawals.
The incident was not reported as a cyberattack. It originated from an infrastructure problem at a third-party technology provider.
Nevertheless, its consequences reached directly into customers' everyday financial activities.
For a digital bank, service availability is fundamental to its value proposition. Customers expect to be able to access their money, make payments and manage their finances whenever they need to. Even a temporary interruption can therefore have consequences that extend beyond technical inconvenience.
Revolut subsequently apologized to affected customers and confirmed that their funds and data had remained safe. The company also indicated that certain transactions and balance updates could take additional time to process following the disruption.
The incident demonstrates how a failure in one part of the technology supply chain can affect multiple financial institutions simultaneously.
Cloud computing has transformed the economics and scalability of financial technology. It allows companies to develop sophisticated products without maintaining extensive proprietary infrastructure. However, it also creates concentration risks when many organizations depend on a relatively small group of infrastructure providers.
A single technical incident can therefore generate operational consequences across numerous institutions, markets and customer groups.
Outsourcing technology infrastructure does not eliminate business responsibility for the services that depend on it.
While financial institutions may delegate infrastructure management to external providers, customers continue to hold the institution accountable when their banking services become unavailable.
The common denominator: A growing gap between innovation and control
These three incidents illustrate different aspects of the same strategic challenge.
The PHP vulnerabilities demonstrate how security weaknesses in foundational software can create widespread exposure across otherwise unrelated organizations. The AI agent incidents reveal the difficulty of maintaining control as software becomes increasingly autonomous. The Google Cloud outage highlights the operational consequences of depending on shared technology infrastructure.
Together, they expose a growing gap between the speed of technological innovation and the development of effective mechanisms to manage its consequences.
Modern digital products rarely operate independently. They depend on cloud infrastructure, external APIs, software libraries, authentication services, data providers, payment networks and increasingly AI models and agents.
Each additional integration can improve functionality and accelerate development. At the same time, it introduces another potential point of failure.
A company may have excellent internal engineering practices, sophisticated security monitoring and well-defined operational processes. Yet a vulnerability in an external component, unexpected behaviour by an AI agent or an outage at a cloud provider can still disrupt its services.
This creates an important shift in how organizations should approach technology risk.
Historically, much of the emphasis has been on preventing failures through secure development, infrastructure redundancy, monitoring and cybersecurity controls. These measures remain essential. However, prevention alone cannot provide absolute protection in increasingly complex environments.
Organizations must be prepared to operate under the assumption that some technologies, dependencies and security controls will eventually fail.
The objective is not to eliminate every conceivable risk. It is to understand which failures matter most, limit their potential consequences and ensure that critical business functions can continue or recover within acceptable timeframes.
Business continuity should begin with product design
Business continuity planning is frequently associated with enterprise risk management, disaster recovery procedures and regulatory obligations. In many organizations, these activities are managed separately from the teams responsible for developing digital products.
This separation is becoming increasingly difficult to justify.
When a product is entirely dependent on digital infrastructure, its technical architecture directly determines the organization's ability to deliver its services.
Consequently, contingency planning should become an integral part of product strategy, architecture and development.
Before introducing a new platform, integrating a third-party service or deploying an AI agent, organizations should consider not only how the solution will work under normal conditions but also how it will behave during an incident.
What happens if a critical API becomes unavailable? Can essential customer activities continue if the primary cloud region fails? How quickly can the business isolate a vulnerable component? Can an autonomous AI agent be stopped without disrupting unrelated services? What happens to transactions initiated immediately before a system interruption?
These questions require collaboration between product owners, technology teams, cybersecurity specialists, risk management and business leadership.
They also require realistic assumptions about failure.
A backup environment offers limited value if it depends on the same underlying infrastructure as the primary system. An incident response procedure may appear comprehensive on paper but prove ineffective if key employees cannot access the necessary systems during an outage. Similarly, an AI agent kill switch provides little protection if permissions cannot be revoked reliably across connected services.
The effectiveness of contingency arrangements depends on whether they work under the conditions in which they are actually needed.
Five priorities for strengthening technology contingency planning
The lessons from these incidents translate into five practical priorities for organizations developing or operating technology-dependent services.
1. Map critical dependencies and potential points of failure
Organizations should maintain a clear understanding of the technologies and external providers supporting their most important business functions.
This includes identifying cloud infrastructure, software components, APIs, data providers, identity services and AI integrations, while also understanding how these dependencies interact.
The objective is not merely to create a technology inventory but to identify where individual failures could trigger wider service disruptions.
Particular attention should be paid to shared dependencies that could affect multiple systems simultaneously.
2. Define acceptable disruption and recovery thresholds
Not every technical failure has the same business impact.
Organizations should identify critical customer journeys and establish clear thresholds for acceptable downtime, data loss and service degradation. Recovery time objectives and recovery point objectives should reflect actual business requirements rather than being defined exclusively by IT teams.
For a financial institution, the ability to process customer payments may require a different level of protection from an internal reporting application.
These distinctions should influence architectural decisions, investment priorities and contingency procedures.
3. Build emergency controls into products and integrations
Technology products should include mechanisms that allow organizations to contain incidents before they escalate.
Depending on the application, these mechanisms may include isolating vulnerable services, disabling integrations, revoking access credentials, suspending transactions, switching to alternative service providers or temporarily restricting specific functionality.
For AI agents, additional safeguards are necessary, including clearly defined permissions, limits on autonomous actions, human approval requirements for high-impact decisions and mechanisms to terminate agent activity.
Such controls should be considered core product capabilities rather than optional security enhancements.
4. Test realistic failure scenarios
A contingency plan that has never been tested is largely an assumption.
Organizations should regularly simulate incidents involving infrastructure outages, critical software vulnerabilities, compromised credentials, unavailable third-party services and unexpected AI behaviour.
These exercises should assess not only technical recovery but also operational coordination, decision-making, customer communication and dependencies on external providers.
Scenario testing should involve business leadership alongside technology and security teams, particularly where service interruptions could have significant financial, regulatory or reputational consequences.
5. Prepare customer communication before an incident
Technical incident response is only one part of effective crisis management.
When essential services become unavailable, customers need timely and transparent information about what has happened, which services are affected and what they can expect next.
Organizations should therefore establish communication responsibilities, escalation procedures and alternative communication channels before a disruption occurs.
Clear communication cannot compensate for prolonged service failures. However, uncertainty, inconsistent information and delayed responses can significantly amplify the consequences of an incident.
Customer trust is the risk that cannot be restored with a backup
Technology incidents are frequently evaluated in terms of downtime, recovery costs, financial losses and regulatory exposure. These metrics are important, but they do not fully capture the potential impact on customer relationships.
For banks and financial service providers, trust is fundamental to the business model.
Customers expect financial institutions to safeguard their money, protect their personal information and provide reliable access to essential services.
An unexpected disruption may temporarily prevent a customer from completing a payment, accessing savings or managing an urgent financial obligation. Even when no money or data is lost, the experience can undermine confidence in the institution.
Repeated incidents, unclear communication or inadequate responses can compound that damage.
A technology failure may be resolved within hours, but rebuilding customer trust can take years.
This distinction has strategic implications.
An organization's ability to respond effectively to an incident influences how customers perceive its reliability, professionalism and accountability. The quality of the response can become almost as important as the technical failure itself.
For digital-first businesses, where customer relationships are mediated primarily through technology, this is particularly relevant.
Trust cannot be restored simply by restarting a server or resolving a software defect. It requires consistent service quality, credible communication and evidence that the organization has learned from the incident.
DORA provides a regulatory framework, but compliance alone is not enough
Within the European financial sector, the Digital Operational Resilience Act (DORA) has already established a comprehensive framework for addressing many of these challenges.
Applicable since January 2025, DORA introduces requirements covering ICT risk management, incident reporting, operational testing, third-party risk management and information sharing.
Its importance extends beyond establishing new compliance obligations.
DORA reflects a broader regulatory recognition that financial stability increasingly depends on the ability of institutions to withstand technology-related disruptions, including those originating from external service providers.
The Google Cloud incident provides a particularly relevant example of why this matters.
When several financial institutions rely on the same infrastructure provider, their individual risk management capabilities may not be sufficient to prevent simultaneous disruptions. Concentration risk therefore becomes an issue not only for individual firms but also for the wider financial ecosystem.
European regulators have already sought information from Google following the October outage, highlighting the importance of understanding the operational impact of shared technology dependencies.
However, regulatory requirements should represent the minimum standard rather than the ultimate objective.
A company can maintain comprehensive policies, complete required assessments and document contingency procedures while still being insufficiently prepared for a real-world incident.
The real measure of preparedness is not whether an organization has a documented plan, but whether it can execute that plan effectively when its systems fail.
This principle also applies beyond regulated financial institutions.
Technology companies, fintechs, software providers and other digitally dependent organizations face similar challenges, regardless of whether they are directly subject to DORA.
From technology risk management to strategic business capability
The events of October 2026 should encourage business leaders to reconsider where contingency planning belongs within their organizations.
It should not be treated solely as an operational responsibility delegated to IT departments or as a compliance exercise performed periodically by risk management teams.
Instead, preparedness for technology failures should become a strategic capability, influencing technology investments, vendor selection, product architecture and business model development.
This does not mean slowing down innovation or avoiding emerging technologies.
Cloud infrastructure, open-source software and artificial intelligence offer substantial opportunities for financial institutions and other businesses. Their benefits remain compelling.
The challenge is to ensure that the adoption of these technologies is accompanied by an appropriate understanding of their risks and dependencies.
Companies should be able to explain why they have selected particular technologies, which critical functions depend on them, how potential failures would affect customers and what alternatives are available when normal operations cannot continue.
These considerations will become even more important as AI agents begin executing increasingly consequential activities across interconnected financial and business systems.
The organizations best positioned to benefit from technological innovation will not necessarily be those adopting every new capability first. They will be those able to integrate innovation into business models that remain dependable under difficult conditions.
The real question is what happens when technology stops working
The PHP vulnerabilities, unauthorized AI agent activity and Google Cloud outage illustrate how differently technology failures can emerge and how quickly their consequences can extend beyond the original system.
Not every vulnerability will be exploited. Not every AI agent will behave unexpectedly. Not every infrastructure outage will cause a major disruption.
But no organization can reasonably assume that the technologies supporting its business will always function as intended.
As digital ecosystems become more complex, dependency management, emergency controls and contingency planning must evolve alongside them.
The objective is not to create an impossible guarantee of uninterrupted operations. It is to ensure that when incidents occur, organizations have the capabilities, procedures and decision-making structures needed to limit their consequences.
For business and technology leaders, the most important question is therefore no longer simply whether their systems are secure, efficient and reliable.
It is whether their business can continue operating when those systems are not.
How Contextual Solutions Can Help
Are your technology dependencies and contingency plans ready for a real-world incident?
At Contextual Solutions, we help financial institutions, fintechs and technology-driven businesses navigate the intersection of technology, strategy, risk and regulation.
Whether you are introducing AI-enabled services, integrating external technology providers, reviewing your digital operating model or strengthening business continuity arrangements, we support you in translating technology risks into practical business decisions.
Our approach combines strategic assessment, technology and process analysis, governance design and implementation support, helping organizations identify critical dependencies, challenge existing assumptions and develop actionable improvements.
Get in touch with Contextual Solutions to discuss how your organization can strengthen its technology risk management and prepare for unexpected disruptions.