The problem doesn't end at the contract boundary
I've had some interesting conversations with suppliers who, once we started examining their contractual obligations and downstream dependencies, discovered that their exposure was considerably greater than they'd appreciated.
Not necessarily because they'd been careless or deliberately cut corners. Sometimes they'd agreed to commitments without fully understanding what those commitments meant, particularly where delivering the service depended on other organisations.
In a few cases, the discovery came as quite a surprise to them.
This is one of the more interesting aspects of third-party and nth-party risk management. It's also potentially quite frightening.
We spend considerable time examining our immediate suppliers, negotiating contractual protections, checking their certifications and completing risk assessments. All perfectly sensible activities.
But what happens when the service we're buying depends on organisations we know very little about, have never assessed and may not even realise are involved?
And perhaps more importantly, what happens when our supplier has promised something that those organisations aren't obliged, or aren't able, to deliver?
When the supplier discovers the problem
Imagine a supplier signing a contract that includes security requirements, incident notification periods, audit rights, data-processing restrictions and service recovery commitments.
Nothing particularly unusual about that.
But the supplier doesn't deliver everything itself. It depends on a cloud provider, perhaps an external security operations service, a specialist software company and various other subcontractors.
Each has its own contract, operating arrangements and limitations.
Now imagine the supplier has agreed to notify its customer of a security incident within a relatively short period. Reasonable enough, until somebody discovers that a critical downstream provider has a considerably longer notification obligation.
The supplier might not even have a reliable mechanism for obtaining the information it needs to determine whether the notification requirement has been triggered.
The original contractual commitment hasn't changed. The supplier simply might not be capable of meeting it.
Similar problems arise with audit rights, data-location restrictions, access controls, disaster recovery and other obligations. A supplier can promise access to evidence it has no contractual right to obtain, or commit to recovery objectives that depend on another organisation's much less demanding service levels.
I've worked with suppliers who discovered these sorts of discrepancies during our discussions. We worked through what they'd actually agreed, what their subcontractors were obliged to provide and what could realistically be done about it.
They're not always comfortable conversations.
But simply issuing a finding and demanding remediation isn't particularly constructive when the underlying contractual or operational arrangement makes the commitment impossible to fulfil.
Sometimes the contract needs clarifying. Sometimes the supplier needs to change how it operates, introduce additional controls or renegotiate its downstream arrangements. Occasionally, the original commitment simply wasn't realistic and the parties need to agree something different.
I'd much rather work towards an arrangement that can be delivered than insist on impressive contractual wording that everybody quietly knows is unworkable.
A contractual promise isn't the same thing as an operational capability.
That distinction matters rather more when something goes wrong.
Cascading obligations aren't automatic
This is where contractual flow-down, or cascading obligations, becomes important.
Under Article 28 of the GDPR, a processor engaging another processor must impose appropriate corresponding data-protection obligations on that subprocessor, providing an equivalent level of protection for the personal data.
It doesn't necessarily require the same wording in every contract. Nor does it mean that all the original agreement's commercial and operational obligations automatically apply to everyone further down the chain.
Those commitments have to be understood and, where necessary, reflected in the relevant downstream arrangements.
There's a considerable difference between saying that obligations should flow down and establishing that they actually do.
An organisation may have an excellent agreement with its immediate supplier. The clauses have been negotiated, Legal is satisfied and the supplier has completed its assessment.
But what has the supplier agreed with the organisations on which it depends?
Has it secured the necessary audit and information rights? Do incident notification arrangements give it enough time to meet its own commitments? Are recovery obligations aligned? Does it know which subprocessors can access the information and under what conditions?
And what happens if one of those arrangements changes?
This is particularly interesting because the customer will often have no direct contractual relationship with the downstream organisation. Its practical remedies may depend on its immediate supplier being able to exercise rights under a separate contract.
There may be perfectly legitimate limitations on what can be negotiated with a large cloud provider or specialist service. The answer isn't always to insist on contractual rights that nobody can realistically obtain.
It may be to understand those limitations, adopt compensating measures, adjust the service design or make an informed decision about the remaining exposure.
What doesn't help is assuming that because the requirement appears in our contract, it has somehow become enforceable and operational throughout the supply chain.
Three suppliers. One point of failure.
The other aspect of nth-party relationships that I find particularly interesting is how apparently independent suppliers can share the same underlying dependencies.
We assess suppliers individually.
Supplier A has satisfactory security controls. Supplier B holds the appropriate certifications. Supplier C has a well-established business continuity programme.
All good.
But what if A, B and C depend on the same cloud platform, identity provider, DNS service or specialist technology company?
We may believe we've diversified our exposure when we've actually concentrated it.
A significant incident at that common provider could disrupt all three suppliers at once. Each might have reasonable security arrangements in isolation, yet our own organisation could still experience a substantial interruption.
The issue isn't necessarily poor security at any of the suppliers we've assessed.
It's the dependency they share.
And we've seen some rather striking examples of what happens when critical dependencies fail.
Change Healthcare: one incident, widespread consequences
In February 2024, a ransomware attack on Change Healthcare disrupted claims processing, payments and other essential functions across the US healthcare system.
The consequences extended far beyond the organisation that had been attacked.
In a survey of nearly 1,000 hospitals conducted in March 2024, the American Hospital Association reported that 94% of respondents experienced financial impacts, while 74% reported effects on direct patient care.
Those are substantial consequences arising from the failure of a service on which other organisations depended.
Individual hospitals could have perfectly reasonable internal security arrangements and still find themselves unable to operate important parts of their business.
Their own security controls weren't necessarily the problem.
The dependency was.
CrowdStrike: when the security control becomes the problem
A few months later, in July 2024, a faulty CrowdStrike content update caused Windows systems to crash around the world.
Microsoft estimated that approximately 8.5 million Windows devices were affected, representing less than 1% of Windows machines globally.
The proportion sounds relatively modest.
The consequences weren't.
Airlines, healthcare providers, financial institutions and other organisations experienced widespread disruption.
This wasn't a cyberattack. It was an operational failure involving technology specifically intended to protect the systems on which it was installed.
Different causes, similar lessons.
One incident involved a malicious attack on a critical service provider. The other resulted from a defective update to a widely deployed security product.
In both cases, dependencies that made perfectly good commercial and technical sense under normal circumstances became sources of significant disruption.
I don't think the conclusion should be that relying on large, established providers is inherently unwise. Their scale, expertise and investment can provide considerable advantages.
But those advantages don't eliminate concentration risk.
And having several suppliers isn't necessarily diversification if they're all dependent on the same underlying technology.
The economics of dependency
There's an interesting academic perspective on this.
In a 2020 paper published in Operations Management Research, Shaun Wang and Ulrik Franke examined the economics of enterprise IT downtime, including how disruption can propagate between interconnected organisations.
Their model considers not only the direct costs suffered by the organisation experiencing the initial failure, but also the costs imposed on other businesses that depend on its services.
It's an economic model rather than an empirical study of the two incidents above, but it illustrates an important point.
The organisation where a failure originates isn't necessarily the organisation that bears all, or even most, of its consequences.
That complicates decisions about investment, resilience and contractual risk allocation.
The supplier may consider its recovery arrangements adequate for its own operations. Its customers may have quite different expectations, and those customers may themselves support critical services for other organisations.
The consequences can travel considerably further than the original contract.
I'm not suggesting we should attempt to map every supplier relationship indefinitely. Beyond a certain point, the effort becomes disproportionate and the information may be impossible to obtain or maintain.
But for critical services, I would want to understand the material dependencies, common points of failure and what would happen if a significant provider became unavailable.
That may require working with suppliers rather than simply sending them another questionnaire.
Now add international personal-data transfers
Consider the same relationships from a privacy perspective.
A supplier might be headquartered in Europe, host its primary databases there and provide perfectly accurate assurances about data residency.
So far, so good.
But its support team operates elsewhere. Security monitoring is provided by another organisation. Analytics, software maintenance, backups or specialist processing may involve further providers in different jurisdictions.
Suddenly, knowing where the main database resides doesn't tell us nearly enough about where the information goes, who can access it or what arrangements govern that access.
This isn't a particularly obscure issue. Yet discussions about data residency can become surprisingly fixated on the physical location of a server.
Under the UK GDPR, making personal data accessible to a separate organisation overseas can constitute a restricted international transfer, even if the data remains on servers in the UK.
For example, giving an overseas support company remote access to a UK-hosted system may trigger the transfer rules.
By contrast, an employee of the same legal entity accessing company systems while temporarily overseas would not ordinarily constitute a restricted transfer under the ICO's guidance, although the organisation still needs appropriate security measures.
The distinction matters. The legal entities involved, who initiates the transfer and the relevant data-protection regime all need to be understood.
The UK and EU have various mechanisms for international transfers, including adequacy arrangements, Standard Contractual Clauses, the UK's International Data Transfer Agreement and the UK Addendum.
The European Commission renewed the UK's adequacy decisions in December 2025, helping preserve the arrangements for relevant transfers from the EEA to the UK.
But having an appropriate transfer mechanism isn't the end of the exercise.
A signed agreement doesn't stop an administrator having excessive privileges. It doesn't remove unnecessary access, prevent data being copied into an unsuitable environment or establish that every downstream processor is operating the controls we've been promised.
And if the supplier doesn't know where its subcontractors process or access personal data, producing another contractual assurance may not make us much wiser.
This is where Legal, Privacy, Security, Architecture and supplier management need to work together. They each understand part of the problem, but it's the relationship between those parts that matters.
Perhaps we don't need to transfer the information at all
One of the more effective approaches to reducing international transfer exposure is also one of the least complicated in principle.
Don't transfer information that doesn't need to be transferred.
Does an overseas support team require unrestricted access to a production database? Could it operate using a smaller dataset, temporary access, masked information or an approved support workflow?
Could testing be performed with synthetic data? Could a particular function be processed locally, with only the necessary result made available elsewhere?
Sometimes the answer is no. There are genuine operational reasons for particular data flows and access arrangements.
But it's worth asking.
Pseudonymisation can be valuable, although pseudonymised personal data generally remains subject to data-protection requirements. And reducing access doesn't remove the need for a lawful transfer mechanism where one is required.
What it can do is reduce the volume, sensitivity and accessibility of information exposed through the arrangement.
That can make a much more meaningful difference than adding another page to the contract.
I've long thought that privacy by design and security by design work best when they're treated as ordinary engineering disciplines rather than compliance exercises carried out once the architecture is already established.
Understanding what information is genuinely needed, who requires it and how it's processed should be part of designing the service.
Fixing an unnecessary data flow is often better than writing another procedure explaining how to manage the risk it creates.
AI adds another layer to the black box
And now, inevitably, we arrive at AI.
I've been interested in the development and adoption of AI for some time, not least because it brings together technology, governance, privacy, ethics and some rather difficult questions about accountability.
The economics, energy consumption and sustainability of widespread AI deployment deserve scrutiny in their own right. But whatever our views on those subjects, organisations are incorporating AI into services and processes at a considerable pace.
That creates some interesting problems for supplier governance.
Consider a SaaS provider introducing an AI capability. The supplier may use an external model provider, which in turn relies on infrastructure and other services. Data may be processed differently from the original product, and the model or supporting architecture may change without the customer necessarily appreciating what's happened.
We're back to subprocessors, data flows, international transfers and obligations that need to be understood across organisational boundaries.
But there is another complication.
I've encountered professionals who appear to assume that decisions made by AI are inherently more impartial because a machine is making them.
I'm not convinced.
AI systems are influenced by their training data, model design, optimisation objectives and the context in which they're used. They can reproduce existing biases, introduce new ones or produce results that appear plausible without being reliable.
Take recruitment screening.
An employer might believe that automating the initial assessment of applicants will produce more consistent and objective decisions.
Perhaps it will. But what evidence supports that conclusion?
What information is the system using? How was it evaluated? Could irrelevant characteristics, or proxies for them, influence the outcome? How does it handle applicants whose careers don't follow a conventional pattern? And can a rejected candidate obtain a meaningful explanation or challenge the result?
If the technology comes from a third party, the customer may have limited visibility of the model, its training data, subsequent changes or the organisations supporting its operation.
That doesn't automatically make the product unsuitable. Nor does every AI application require the same level of scrutiny.
But where decisions materially affect people, the organisation using the system needs sufficient assurance about how it behaves, its limitations and the controls necessary to govern its use.
A supplier's statement that its AI is fair, responsible or compliant is a starting point for examination, not a substitute for it.
And there's the additional privacy question: what information are we providing to the model, where is it being processed and what happens to it afterwards?
A conventional supplier questionnaire may tell us that the company has a privacy policy, an information security management system and documented AI principles.
Useful, certainly.
But it may tell us very little about the particular AI capability we've just enabled.
The assessment was completed. Has anything changed?
All of this brings me back to an issue I've encountered repeatedly in security governance and supplier assurance.
We sometimes place rather too much emphasis on completing assessments and not enough on whether the risks remain understood and appropriately controlled.
A supplier was assessed last year. The questionnaire was completed, the certificate examined, the contract reviewed and the risks recorded.
The file is closed.
Since then, the supplier may have introduced new subprocessors, changed its architecture, moved part of its service overseas or added AI capabilities that involve new forms of processing.
The original assessment hasn't necessarily become worthless. It's still evidence of what was examined at the time.
But it is historical evidence.
The business and technology may have moved on.
This is where I think ongoing, risk-based assurance is more useful than relying entirely on periodic reassessments.
That doesn't mean watching every supplier constantly or requiring them to report every minor operational change. We'd rapidly create a great deal of work without necessarily becoming any better informed.
It means identifying which relationships matter, which changes could materially affect our exposure and how those changes should trigger a proportionate review.
For critical suppliers, I'd be interested in changes to significant dependencies, service architecture, security incidents, resilience arrangements, material subprocessors and the way information is accessed or processed.
And, importantly, whether the organisation is capable of acting on what it learns.
There's little value in detecting a material change if nobody owns the resulting decision.
Completing the assessment isn't the outcome. Understanding and managing the risk is.
That may sound obvious, but the distinction can get lost when assurance programmes are measured mainly by the number of assessments completed, findings issued and overdue actions closed.
Those measures have their place. They don't necessarily tell us whether our business is less exposed than it was before.
The boundaries disappear when you follow the problem
What interests me about these issues is how quickly the traditional boundaries between disciplines disappear once you examine how a service actually works.
A contractual commitment reveals an unexpected dependency. That dependency introduces a concentration risk. The underlying provider operates in another jurisdiction, raising questions about data access and international transfers.
An examination of the data flows identifies processing that isn't necessary. Meanwhile, a new AI feature introduces another external provider and a different set of risks.
And somewhere along the way, the original supplier discovers that it has promised something it may not be capable of delivering.
These aren't separate problems simply because different departments are responsible for them.
Legal can draft a well-constructed contract. Procurement can negotiate a good commercial arrangement. Security can complete an assessment, and Privacy can examine the processing requirements.
Each may have done its job properly.
But if nobody understands how those arrangements fit together, significant risks can remain hidden between the organisational boundaries.
I'm not advocating endless due diligence or suggesting that every subcontractor needs to be assessed individually. Organisations have to make sensible decisions about proportionality, commercial realities and the resources available.
Nor do I expect every risk to be eliminated. Some dependencies are unavoidable, and some risks can reasonably be accepted.
What I do expect is that organisations understand their material exposures, recognise the limitations of the assurances they receive and make commitments that can actually be delivered.
When problems emerge, particularly ones that involve several organisations, the most productive response is often to work through them together rather than simply allocate blame.
The contract matters. The transfer mechanism matters. Certifications, assessments and documented controls all have value.
But none of them tells the whole story unless we understand the business, the technology and the relationships that sit behind them.
The problem doesn't end at the contract boundary. Neither do our responsibilities.
Further reading and references
Supply-chain dependencies, operational failures and systemic risk
- American Hospital Association (2024) — Change Healthcare Cyberattack: Survey of Hospital Impacts. A useful illustration of the financial and operational consequences experienced by organisations dependent on a compromised service provider.
- CrowdStrike (2024) — Falcon Content Update: Preliminary Post-Incident Review. The supplier's technical account of the July 2024 update failure, explaining how a defect in content validation resulted in widespread system crashes.
- Microsoft (2024) — Helping Our Customers Through the CrowdStrike Outage. Provides Microsoft's estimate of affected devices and discusses the wider consequences of interconnected technology services.
- Wang, S. S. and Franke, U. (2020) — Enterprise IT Service Downtime Cost and Risk Transfer in a Supply Chain. Operations Management Research, 13, 94–108. An economic model examining the direct and indirect costs of IT service disruption across interconnected organisations.
Data protection, contractual obligations and international transfers
- ICO — Contracts and Liabilities Between Controllers and Processors. The legal requirements for controller–processor agreements, including downstream obligations under Article 28.
- ICO — A Guide to International Transfers (updated January 2026). Particularly useful for the distinction between data location, remote access, legal entities and the circumstances constituting a restricted transfer.
- European Commission — Adequacy Decisions. Includes the December 2025 renewal of the UK's EU adequacy decisions and the wider framework for international personal-data transfers.
- European Data Protection Board — Recommendations 01/2020 on Supplementary Measures for International Transfers. Explores the limitations of contractual transfer instruments and the circumstances in which additional technical and organisational safeguards may be necessary.
AI governance and fairness
- ICO — AI Fairness, Bias and Discrimination. Examines how AI systems can produce discriminatory outcomes and the considerations involved in assessing fairness.
If you made it this far you may have noticed this article has changed post-publication, mea culpa. I pasted the wrong version ...
Personal commentary. Views are the author’s own.