Organisations invest considerable time and effort in drafting their data sharing agreements. The contract goes through legal review, the clauses are debated, the schedules are filled out, and the document is finalised. Once the technical team has connected the systems, the data begins to move in ways that do not resemble the contractual obligations that were agreed upon.
This is the contract to reality gap, and it is where the real risk lies. Not in the wording of the contract, but in what happens once the API is activated, the integration is running, and no one is verifying whether the data flows align with the contractual requirements.
The Agreement Is Not Compliance
Data sharing agreements (DSAs) between independent controllers are not a statutory requirement under the UK GDPR. In contrast, Data Processing Agreements (DPAs) are required under Article 28 when a controller engages a processor. DSAs are a governance tool representing good practice and evidence of compliance with the accountability principle, as described in the ICO's Data Sharing Code of Practice. They do not, however, provide a lawful basis for sharing. Each controller must individually establish their own lawful basis for the sharing arrangement pursuant to Article 6.
This distinction is important as many organisations view the signing of the DSA as the end point of compliance. The DSA represents what should occur, but compliance depends on what does occur.
What The Contract States vs What The Data Does
The most instructive example of this disconnect is the Cabinet Office's use of Real-Time Bidding Advertising (RTBA). The Cabinet Office had been utilising RTBA since 2014 – a process that involves sharing personal data, including special category data inferred from browsing behaviour, in real-time auctions to multiple entities.
At the time of the investigation, the Cabinet Office acknowledged it did not believe any personal data was being processed. A DPIA was not performed, and the lawful basis for the processing had not been identified. The processing was not documented in the Record of Processing Activities (ROPA).
The ICO's investigation concluded that relying solely on contractual agreements was insufficient due to the lack of technical controls governing the sharing, security, and deletion of bid request data received by third parties. The contracts were in place; however, the technical controls were not.
This pattern repeats at various scales across organisations of all sizes. A DSA stipulates that only basic contact information will be exchanged. The API returns a complete user object containing contact information, purchase history, and account metadata, because the development team created the integration utilising the standard endpoint and relied on the front-end application to filter what the user sees. The complete dataset is still transmitted across the network. Regardless of the language in the DSA, this represents a data minimisation failure, as client-side filtering does not prevent the transmission; it simply hides it.
How I Begin Assessing Data Sharing Arrangements
When I begin reviewing a data sharing arrangement, the DSA is the last item I examine. My first hour is spent with the technical team, and it generally follows a similar path.
I request the API documentation (i.e. Swagger or Postman collections) to determine specifically what the endpoints transmit. I review the Identity and Access Management (IAM) protocols: whether the integration utilises OAuth 2.0 or shared API keys and whether the principle of least privilege is applied at the service account level. I also wish to understand whether legacy systems or unapproved tools are processing the shared data outside of the controls stipulated in the contract.
Next, I map the actual data fields being transmitted against the necessity documentation that supported the DPIA – the Data Protection Impact Assessment that should define what data the integration requires and why. Not categories of data – the specific fields. If the contract states "name and email address" but the API response contains 40 fields, the integration needs to be reconfigured to utilise server-side filtering prior to entering production.
At this stage, the difference between a legal-background DPO and a technical DPO is practical. A legal review confirms the contract includes the correct clauses. A technical review confirms the data actually transmits in the manner described in the contract.
The Sub-Processor Problem
Identifying the entire sub-processor chain of a SaaS vendor – especially where generative AI services are involved – is one of the harder problems to solve in 2026. Article 28(1) of the UK GDPR requires controllers to use only those processors that provide "sufficient guarantees" of suitable technical and organisational measures. Without knowledge of the entire processing chain, this obligation cannot be met.
In practice, I ask for a formal sub-processor list and reference it to the SaaS vendor's SOC 2 Type II or ISO 27001 certification. When a vendor resists providing transparency, the discussion is direct: without performing a complete chain audit, I am unable to satisfy the accountability principle, and my recommendation to the board will be to stop the integration or find a more transparent alternative. This usually produces the requested documentation.
Deletion Is Not A Statement; It Is Evidence
Receiving a letter or e-mail from a third party stating that data has been "deleted in accordance with the agreement" is not sufficient for auditing purposes. Verification of deletion requires evidence, not assurances.
In cloud environments, I seek evidence of crypto-shredding (irreversible destruction of the encryption keys specific to the shared dataset within the provider's Key Management System). I request a certificate of sanitisation or automated audit logs to demonstrate that deletion jobs completed successfully across all production and backup environments. When the risk warrants it, I request a data discovery scan from the partner to prove that no residual data remains in secondary databases or archived systems.
The Intra-Group Trap
The 2025 Capita enforcement action – £8 million against the parent company and £6 million against the subsidiary – made it clear that the ICO does not view intra-group data sharing as inherently lower-risk. The regulator's position was explicit: intra-group outsourcing arrangements must be provided on an arm's-length basis and subject to the same scrutiny as any third-party relationship.
Many organisations have yet to absorb this. Internal sharing between subsidiaries frequently operates without formal agreements, without documented legitimate interests assessments, and without the access controls that would be standard for an external partner. The result is lateral movement vulnerability: a breach in one subsidiary can enable privilege escalation throughout the organisation because the internal boundaries were never formally defined or enforced.
Since the DUAA 2025 codified intra-group sharing for administrative purposes as an example that may constitute a legitimate interest under Article 6(1)(f), some organisations have interpreted this as a relaxation. That interpretation is not correct. The codification confirms that a legitimate interest may exist; it does not relieve the requirement for a documented assessment, including the balancing test. Recognised legitimate interests – the narrow categories that are exempt from the balancing test – do not include commercial intra-group sharing.
What This Means In Practice
The Data Sharing Code of Practice is currently under review as a result of the DUAA 2025, with no published timeline for the revised code. Five narrow public-interest categories (crime prevention, safeguarding, emergency response, national security, and disclosures to public-task bodies) now benefit from the removal of the balancing test under the new recognised legitimate interests provisions. For commercial data sharing between private organisations, the legal framework is substantively unchanged.
The DSA remains necessary, but it is not where the risk concentrates. The risk lies in the gap between what the contract specifies and what the systems actually do. Closing this gap requires a person who can read the API documentation, validate the access controls, audit the sub-processor chain, and confirm that deletion occurred – not simply someone who can confirm the contract clauses are in order.