Businesses are facing increasing scrutiny on cyber resilience, yet many still rely on generic policies and tick-box vendor management rather than negotiating robust contracts and testing whether the agreed processes work in practice.
Supply chain risk often only emerges during an incident, which is the worst time to have to dig through historic contracts and assess the implications for the business. Even once located, provisions are often vague or misaligned with operational reality. For years, organisations have focussed on regulatory exposure and litigation risk whilst supply chain resilience and its complex dependencies have received less attention.
The time available to identify, assess and contain an issue is also shrinking, as frontier AI models materially accelerate cyber risk by increasing the speed, scale and sophistication of vulnerability discovery and exploitation. Supply chain risk management is therefore more important than ever, especially given the increasing complexity of supply chains and interconnected systems.
The problem is not just the clause, but whether it works
Many organisations still approach cyber risk as a documentation exercise by concentrating on cyber policies, vendor questionnaires and security schedules. Whilst these are all important, that focus risks failing to address a tougher question: can requirements be implemented in practice across a complex and interconnected supply chain?
Recent events have demonstrated the potentially significant consequences of a cyber-attack or outage impacting the supply chain, including operational disruption, financial loss (e.g. arising from production downtime or loss of trading), damage to reputation and customer detriment.
Modern businesses typically rely on a matrix of managed service providers, cloud platforms, software vendors and open-source components comprised of a web of subcontractors that sit beyond immediate visibility. A commitment in a master services agreement may look robust on paper, but its value depends on whether it has been flowed down effectively, understood operationally and tested under realistic incident conditions.
This is not simply an IT issue. It sits at the intersection of technology, procurement, risk, legal and operations. If each function works in isolation, important gaps remain hidden until an incident brings them to light.
Incident notification: when 48 hours is already too late
Incident notification is a good example. For years, contracts have included relatively formulaic notification obligations; indeed, our research shows that just over a third of cloud contracts within a representative sample required notification “without undue delay” (or similar) and around half required notification within 24 or 48 hours. This approach was typically driven by regulatory reporting requirements such as the 72-hour deadline under GDPR/UK GDPR. However, this standard approach no longer addresses the rapidly evolving threat landscape.
In a serious cyber incident, time matters. The earlier you find out about an issue, the more swiftly you can respond. A prompt alert may allow a customer to isolate and disconnect systems, switch to alternative processes or take other immediate steps to contain the risk and prevent a wider operational crisis. In that context, a first notification after 48 hours is like calling the fire brigade 2 days after seeing naked flames. Shorter notification timescales (e.g. 2 to 4 hours) may become the new reality.
However, simply shortening the contract deadline does not by itself solve the problem. In the first few hours, suppliers may still be trying to determine the root cause, which services are affected and what information is reliable enough to share – or what they may be willing to share, while considering the potential for future claims.
The real test of a notification clause is therefore not how strict it appears on paper, but whether it produces timely, accurate and actionable information during a live incident.
Organisations also need to test notification processes with critical suppliers before anything goes wrong. What can be said in the first hour, even if facts are incomplete? Who is available out of hours? Which customers and services are affected? More detailed legal drafting provides useful hooks but will not create resilience on the day by itself.
Supplier assurances are not the same as supplier resilience
The same point applies to contractual cyber and resilience assurances more broadly. Supply-chain risk remains one of the biggest areas of exposure because many incidents arise from a smaller component or dependency, potentially buried deep in the technology stack.
Security schedules, business continuity and disaster recovery commitments, flow down obligations and audit rights are therefore crucial. However, paper promises can also create false comfort if they do not translate into operational reality.
For example, a provider might sign up to customer security policies without the operational capability to implement all the requirements, creating an unidentified chink in the armour. Contractual commitments can often be vague and may not address the specific protections required. Indeed, our research revealed that around 80% of cloud contracts included business continuity and disaster recovery clauses, but they were often generic; for example, whilst 58% included data back-up obligations, only 30% specified the frequency.
That is why organisations need to ask multi-layered questions about the third parties they rely on, and then put assumptions to the test based on different risk scenarios. For example, what specific security and resilience measures would be needed to avoid disruption in the event of a cyber-attack, supplier insolvency or power outage at a key data centre? Can they be flowed down to subcontractors? And most importantly, will they work in practice if the worst does occur?
What good looks like in practice
Operational resilience ultimately turns on the ability to anticipate, withstand and recover from disruption. That requires more than policies and promises; it requires visibility, testing and remediation.
The first priority is therefore mapping. Organisations should understand the people, technology, data and third parties that support their critical systems and services. This means looking beyond immediate suppliers to assess deeper dependencies, concentration risks and interconnections. Only when you have a clear picture of the potential points of failure can you start to prioritise the critical resources for keeping the lights on.
The second priority is testing. Scenario exercises with suppliers can expose weaknesses that no paper assurance will reveal: incomplete information flows, unknown fourth-party dependencies, unrealistic assumptions about recovery times, or uncertainty about responsibility for key decisions. Contracts should support this by requiring meaningful cooperation, assistance and participation in testing. Penetration testing and vulnerability identification also matter, so that weaknesses can be fixed before they are exploited.
This leads to the third priority – remediation. Patch and vulnerability management is now business critical. Firms need to triage and remediate vulnerabilities more quickly and at scale, presenting a resource challenge, not just within the organisation, but throughout the supply chain. Prioritisation and timing matter. The focus should be on critical services and key dependencies, with emergency pathways where speed is essential.
A holistic approach: the resilience lens
The most important shift may be cultural. Businesses need to manage their supply chain and view contracts through a resilience lens, not just a procurement or liability lens. The purpose of a notification clause, a security schedule or a recovery time objective is not simply to allocate legal risk after the event, but to help ensure that critical controls function in the real world.
Assurance alone is no longer enough. Regulators, customers and boards are increasingly less interested in whether controls exist in theory, but whether they work in practice.
Priscilla Hetherton is a legal director in the Technology & Outsourcing team and James Moss is director of cyber investigations at Addleshaw Goddard
