Data that leaves the organizational environment enters an environment governed by someone else's policies, audited by someone else's auditors, and protected by someone else's controls. The question of what happens to it is not answered by the contract. The contract describes obligations. The reality describes what actually occurs.
The Journey Most Organizations Have Not Mapped
When a vendor receives data from your organization, a chain of data handling decisions begins that extends well beyond the vendor relationship. The vendor stores the data on cloud infrastructure they do not own. They process it using software tools developed by third parties. They may transmit portions of it to subcontractors who provide specialized services. Those subcontractors may use their own sub-subprocessors. Each link in the chain involves a data handling decision made by an organization that has no direct relationship with the data's original subject — and in many cases, no direct relationship with the organization that originated the transfer.
The data processing agreement that governs the first transfer in this chain is your direct contract with your vendor. It specifies what the vendor may and may not do with your data. What it does not and cannot fully specify is what the vendor's technology providers, subcontractors, and their downstream partners do with the data. The legal chain of processor agreements extends from your DPA through your vendor's agreements with their subprocessors. The practical chain of data handling extends through organizations and jurisdictions that may not appear anywhere in the documented processing chain.
The DPA governs the first transfer. The data's journey extends significantly beyond the first transfer. Most organizations have mapped the first. Few have mapped the rest.
What the Subprocessor List Actually Tells You
GDPR Article 28 requires that processors inform controllers of any intended changes concerning the addition or replacement of subprocessors. Most organizations interpret this as a right to be notified when subprocessors change — and it is. It is also, when read carefully, an acknowledgment that the subprocessor chain extends beyond the direct vendor relationship and that the controller is entitled to know what that chain looks like.
The subprocessor lists that vendors publish range from comprehensive to perfunctory. A comprehensive subprocessor list names each subprocessor, the service they provide, the data they process, and the jurisdictions in which processing occurs. A perfunctory list names cloud providers and a generic category of sub-processors without specificity. The difference matters when you are trying to answer the question of what happens to your data, because the answer depends on whether you know who is handling it.
Even comprehensive subprocessor lists have a limitation that is rarely discussed: they reflect the vendor's disclosed subprocessor relationships at publication time. They do not reflect subprocessor relationships that have been added since publication, subprocessors that the vendor does not consider material to your specific data processing, or subprocessors of subprocessors — the fourth-party chain that begins where the vendor's disclosure ends.
The Jurisdiction Question
Data that enters a vendor's environment enters the jurisdictional framework that governs the vendor's operations and infrastructure. That jurisdictional framework may be different from the one that governs your organization. The vendor is US-based, which means their operations are subject to US government access frameworks including FISA. The vendor uses cloud infrastructure in regions that include jurisdictions with data access laws that create different obligations. The vendor's subprocessors are in additional jurisdictions.
For organizations subject to GDPR, the question of where data is processed and under what jurisdictional framework is a compliance question with specific legal implications. The Schrems II decision requires that organizations assess the actual protection available to data transferred outside the EEA, taking into account the law and practices of the recipient country. This assessment cannot be completed without knowing where the data actually goes — which requires knowing the full subprocessor chain, including the jurisdictions in which each subprocessor operates.
Most organizations have answered the jurisdiction question for their direct vendor relationships. They have not answered it for the full processing chain. The transfer impact assessment covers the first transfer. The data travels through additional jurisdictions in the remaining transfers that the assessment did not cover.
The Security Question
Beyond the legal and jurisdictional questions, the security question is the one with the most direct operational consequences. Your vendor has been assessed. Their security controls have been evaluated against your requirements. You have made a governance decision about the acceptable risk of sharing data with this specific vendor under these specific conditions.
You have not assessed the security posture of the vendor's cloud infrastructure provider's configuration of the services the vendor uses. You have not assessed the security posture of the vendor's subcontractors. You have not assessed whether the security requirements in your DPA with the vendor are flowing down into the vendor's contracts with their subprocessors with equivalent rigor. The security governance perimeter you have built ends at the direct vendor relationship. The data's security depends on the security posture of every organization in the chain.
Building Actual Visibility
The organizations that have made the most progress on this problem have approached it as a data flow mapping problem rather than a contract management problem. They have traced specific data categories — customer personal data, payment information, health records — from their own systems through each vendor relationship to the point of ultimate storage or deletion, documenting each organization in the chain, each jurisdiction encountered, and each security standard applicable at each point.
This is labor-intensive for the initial mapping. It is significantly less labor-intensive for ongoing maintenance if the mapping infrastructure is built correctly — with automated subprocessor change monitoring, jurisdiction tracking integrated into the vendor onboarding process, and contractual requirements for subprocessor disclosure that are actually enforced through vendor assessments.
The answer to the question of what happens to your data after it leaves your environment should be a map, not a statement about contract obligations. The map shows the journey. The contract describes the intent. They are both necessary. They are not substitutes for each other.
Know where your data goes. Every link in the chain. Not because the regulation requires the documentation, but because you cannot govern what you cannot see.
Map the data journey, not the contractual chain. The data travels further than the contract follows it.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.