Data Processing Agreements: Travel Visas Between Companies

Opening Scene

Countries with strong diplomatic ties often maintain formal travel agreements: reciprocal visa arrangements that spell out exactly what a citizen of one country is permitted to do in the other, and which government remains accountable if something goes wrong. Companies that share personal data with vendors, cloud providers, or partners need an equivalent instrument, and privacy law requires one explicitly: the data processing agreement.

In Plain English

A data processing agreement, or DPA, is a legally required contract between a data controller — the organization that decides why and how personal data is processed — and a data processor — a third party that processes that data on the controller’s behalf, such as a cloud provider, analytics vendor, or payment processor. The DPA spells out exactly what the processor may do with the data, what security measures it must maintain, how quickly it must report a breach, and crucially, that it cannot pass the data to a further sub-processor without the controller’s knowledge. Without a valid DPA in place, sharing personal data with a third party is itself a compliance violation, regardless of what that third party actually does with the data.

The Old Way

Before data processing agreements were a standard, legally mandated part of vendor relationships:

Companies routinely shared personal data with vendors and partners under general commercial contracts that said little or nothing specific about how that data had to be protected.
Accountability when a vendor mishandled shared data was genuinely murky, since there was rarely a clear contractual chain establishing who was responsible for what.
Sub-processing — a vendor quietly passing data along to its own vendors — often happened with no visibility or consent from the original company at all.

Requiring a specific, detailed contract for every processing relationship closed exactly that accountability gap.

What’s Changing (and Why AI Is the Reason)

DPAs have become a standard, non-negotiable part of vendor onboarding at most sizable organizations, checked automatically before any new tool touching personal data gets approved.
This vendor-accountability work connects directly to the third-party risk practices covered later in this series, and to the broader vendor security posture assessed in this content library’s dedicated access control and data security series, since a DPA is only as good as the processor’s actual ability to meet it.
AI vendors — companies providing foundation models, embedding services, or analytics APIs — have introduced a genuinely new wrinkle, since standard DPA language rarely anticipated a processor using shared data to improve its own general-purpose models, which is why AI-specific DPA clauses have become an urgent negotiating point.

The Metaphor, Fully Extended

A Formal Travel Agreement Between Two Countries	A Data Processing Agreement Between Two Companies
The home country deciding who may travel and why	The data controller deciding why and how personal data is processed
The host country hosting the traveler under agreed terms	The data processor handling data on the controller’s behalf under agreed terms
A treaty clause barring the traveler from being redirected elsewhere without notice	A DPA clause barring sub-processing without the controller’s knowledge and consent
A reporting obligation if something goes wrong during the visit	A breach notification clause obligating the processor to report incidents promptly

For Beginners: What to Actually Do

Learn the basic distinction between a data controller and a data processor, since it determines who is legally responsible for what.
Notice, next time you review any service’s privacy policy, whether it mentions its own sub-processors or vendors.
Understand that sharing data with a vendor without a DPA in place is a compliance failure on its own, independent of what the vendor actually does.

For Practitioners and Leaders: The Deeper Layer

Make DPA execution a mandatory, automated gate in vendor onboarding, before any tool touching personal data is approved for use.
Extend vendor due diligence beyond the DPA’s paper terms into the actual security posture covered in this content library’s dedicated access control and data security series, since a signed contract doesn’t guarantee real compliance.
For any AI vendor relationship, negotiate explicit contractual language covering whether shared data may be used to train or improve the vendor’s own models, since standard DPA templates often leave this ambiguous.

Quick Recap

A data processing agreement is a legally required contract between a data controller and a data processor governing how shared personal data is handled.
DPAs must specify permitted uses, security requirements, breach reporting timelines, and sub-processor rules.
Sharing personal data with a vendor without a valid DPA is itself a compliance violation.
AI vendors introduce new complexity, since standard DPA language often doesn’t address whether shared data can train the vendor’s own models.

Where This Fits in the Series

Article 8 covered building privacy into systems from the start. Article 10 follows the data itself as it physically crosses borders between countries, examining the specific rules governing cross-border data transfers.