The TSA data processing addendum is where a carve-out settles who is responsible for personal data while the seller keeps running the systems that hold it. Strong TSA negotiation treats the addendum as a risk document, not boilerplate, because a weak version leaves the buyer exposed to a breach it cannot control. The seller wants narrow duties and slow notice. The buyer wants tight security, fast notice, and a clean handover at exit.
A TSA exists because the seller keeps operating systems the buyer is not yet ready to run. Many of those systems hold personal data, including payroll records, employee files, customer contacts, and benefits information. For the months the TSA runs, the seller is touching the buyer data inside the seller own environment, which is exactly the situation a data processing addendum is meant to govern.
The risk is asymmetric. A data incident inside the seller systems can trigger regulatory exposure, notification duties, and reputational harm for the buyer, yet the buyer has limited visibility into how the seller actually protects that data. The addendum is the buyer main tool for setting the standard it cannot otherwise enforce by walking the floor.
Sellers often present the addendum as a standard form that simply needs signing. That framing favors the seller. The standard form usually sets soft security language, slow notice, broad rights to appoint sub-processors, and vague exit duties, all of which transfer risk to the buyer without the buyer noticing.
A buyer treats the addendum as part of the same negotiation as scope and pricing, because the data terms decide who carries the cost of the most damaging realistic failure during the transition.
The first task is to name who is the controller and who is the processor for each service. The roles drive the duties, and a single blanket label rarely fits a TSA that spans payroll, HR, finance, and customer facing systems. The buyer maps the data flows service by service before it accepts any role language.
For most employee data the buyer is the controller of its own people data and the seller acts as a processor following the buyer instructions. For some shared functions the parties may be joint controllers, which changes the allocation of duties and liability. Getting this wrong can leave the buyer carrying obligations that should sit with the seller.
Where the seller acts as processor, the addendum must require the seller to process only on documented buyer instructions and to stop any processing the buyer has not authorized. This matters because a seller running a shared platform may otherwise reuse or retain data in ways the buyer never intended.
Clear roles also make the rest of the addendum easier to negotiate, because security, notice, and exit duties all flow from who holds responsibility for the data in each service.
Security language is where the standard form is weakest. The buyer pushes for specific measures rather than a promise of appropriate safeguards, including access controls, encryption where relevant, logging, and a commitment to keep the buyer data segregated within shared systems. The more concrete the standard, the easier it is to hold the seller to it.
Breach notice is the clause that most often fails the buyer. The buyer carries its own regulatory deadlines, which can be as short as 72 hours from awareness, so it needs the seller to report fast and in detail. A standard of without undue delay and within a fixed number of hours, with enough information for the buyer to assess and report, beats vague wording that lets the seller wait.
Sub-processors deserve the same scrutiny. The seller often relies on third-party vendors to deliver the service, and each one is another place the buyer data can leak. The buyer wants a list of sub-processors, a right to object to new ones, and a commitment that the seller flows the same duties down the chain.
Audit and cooperation rights round out the protection, giving the buyer a way to verify the seller posture and to demand support if a regulator or a data subject comes asking.
Many carve-outs move data across borders, because the seller shared service centers and the buyer new operations may sit in different countries. The addendum needs a transfer mechanism that holds up under the relevant law, and the buyer confirms that the seller has the right safeguards in place rather than assuming they exist.
The liability terms in the main TSA interact with the data duties. A buyer that negotiates a strong addendum can still be exposed if a low fee based cap swallows the cost of a data breach. The buyer reads the addendum together with the limitation of liability clause, and pushes for data and security to sit outside the general cap or under a higher separate sub cap.
Indemnities also matter here. Where the TSA includes indemnities for data breach or regulatory claims, the buyer checks whether those promises are themselves capped and stripped of consequential loss, because an indemnity that looks generous can deliver little once the limitations apply.
Reading the data terms, the cap, and the indemnities as one package is the only way to know what real protection the buyer holds if the seller mishandles the data.
The data processing addendum belongs on the pre-signing checklist, not the post-close cleanup list. While the deal is live the buyer holds leverage, because the seller wants to close. Once the TSA is signed the buyer is asking for a concession on data terms with nothing left to trade.
Exit duties are the part most often left vague, yet they decide what happens to the buyer data when the service ends. The addendum should require the seller to return or delete the buyer personal data, certify the deletion, and stop processing once the service stops. These duties should align with the exit plan so the data is settled before the buyer migrates off the seller systems.
None of this asks the seller to take on open ended risk for a function it is exiting. It asks the data terms to reflect the real exposure, so the party running the systems carries the duty to protect the data inside them.
A disciplined buyer settles the addendum as part of a pre-signing review, alongside scope, pricing, and the liability terms, while it still holds the leverage to move them.
During a TSA the seller keeps running systems that hold the buyer personal data, so the parties are processing that data on each other behalf. A data processing addendum sets the legal terms for that processing, including roles, security, breach notice, and what happens to the data at exit.
It depends on the service. For payroll and HR the buyer is usually the controller of its own employee data and the seller acts as processor. For some shared functions the parties may be joint controllers. The addendum should name the role for each service rather than apply one label to everything.
The buyer needs notice fast enough to meet its own regulatory deadlines, which can be as short as 72 hours from awareness. A standard of without undue delay and within a fixed number of hours is stronger than vague wording, and the seller should also provide enough detail for the buyer to assess and report the incident.
The addendum should require the seller to return or delete the buyer personal data at exit, certify the deletion, and stop processing once the service ends. This belongs in the exit plan so the data obligations are settled before the buyer migrates off the seller systems.
How a buyer protects sensitive information shared during the transition.
Read the article →Which indemnities a buyer needs and how the cap can quietly undo them.
Read the article →Where to set the cap and which carve-outs belong outside it.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
We set the roles, the security standard, the breach notice, and the exit duties while you still hold leverage. Fixed-fee proposal in 48 hours. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →