Data protection is where the TSA gets serious.

Where data protection disputes begin.

A TSA almost always involves personal data. Employee records sit in the seller's HR system while payroll runs. Customer contact files flow through the seller's email platform while the Newco builds its own. Vendor master data lives in the seller's procurement application while the buyer issues purchase orders. Each of these data flows is regulated under GDPR in the European Economic Area, under UK GDPR in Britain, under similar regimes in California, Brazil, and a growing list of jurisdictions. The TSA cannot pause these obligations.

Disputes typically begin at one of four pressure points. A subject access request lands and the parties disagree about who must respond. A regulator asks a question and the parties disagree about who is on the hook. A security incident occurs and the parties disagree about whether it triggers a notifiable breach. A new processing activity is requested and the parties disagree about whether the data processing agreement covers it.

In each case, the underlying root is the same. The TSA schedules did not specify the data protection role of each party with the precision a regulator would expect. The remedy is to define the roles, document the flows, and run the dispute through governance with clean evidence. The pattern overlaps with the broader carve-out data separation under GDPR playbook.

Controller, processor, or joint controller.

The first technical question in every TSA data protection dispute is the role of each party with respect to each data set. The seller is the controller for some data, the processor for other data, and a joint controller for a narrow slice of activity. The buyer holds the mirror image roles for the same data sets. The contract has to map this clearly. The map is rarely complete at signing.

Payroll is the classic example. The Newco is the controller of its own employee data. The seller, providing payroll under the TSA, is the processor. The data processing agreement that sits behind the TSA needs to record this clearly, list the categories of data, specify the processing activities, fix the security measures, and provide for sub processor consent. When the data processing agreement is thin, every operational question becomes a dispute. When the agreement is sound, most questions answer themselves.

The buyer that pressure-tests the data processing agreement in pre-signing avoids most disputes during execution. The pre-signing review work covers this in the cybersecurity Day One workstream and feeds into the broader pre-signing review service.

Subject access and regulator requests.

Subject access requests under GDPR have a one month response window, extendable to three months in narrow cases. When a request arrives at the Newco about a former employee whose record still sits on the seller's HR system, the Newco is technically the controller and must respond. The seller, as processor, must support the response by extracting the data, applying the redaction rules, and delivering the export within a timeline that lets the Newco meet the regulator deadline.

The dispute pattern is consistent. The seller treats subject access support as a low priority because the seller is not on the regulator hook. The Newco runs the clock and pushes the seller for an export that does not arrive. When the response finally lands, the format is wrong, the redaction is missing, or the data set is incomplete. The Newco either misses the regulator window or files a thin response that creates downstream risk.

The disciplined buyer addresses this in three steps. Negotiate explicit subject access support obligations in the data processing agreement, with named timelines and a service credit if the seller misses them. Track every request in a shared register that both sides can see. Escalate any miss into governance with the regulator deadline attached. The pattern overlaps with the broader TSA billing disputes framework, because subject access support is sometimes invoiced separately and the invoice itself can become contested.

Breach notification timing and content.

Breach notification is the most consequential dispute category in TSA data protection. GDPR requires the controller to notify the regulator within 72 hours of becoming aware of a personal data breach where the breach is likely to result in risk. The processor must notify the controller without undue delay. The TSA has to translate these obligations into operational language with named contacts, defined channels, and a clear definition of awareness.

Disputes arise on three axes. Did the seller notify the buyer within the agreed window. Was the information complete enough for the buyer to make its regulator notification decision. Did the parties agree on whether the incident met the notification threshold. Each axis has a different remedy. A late notification is a contract breach with a defined credit. An incomplete notification is a process failure that triggers a remediation plan. A disagreement on threshold is an escalation through governance with legal counsel attached.

The buyer that runs a quarterly breach simulation with the seller catches the process failures before a real incident exposes them. The simulation is also a deterrent. A seller that has rehearsed the call tree, the evidence package, and the joint communication treats the real call differently. The breach playbook is part of the TSA breach notification strategy work.

Cross-border transfers and standard contractual clauses.

Carve-outs frequently move data across borders. Newco employee data sits in the seller's US data centre while a European Newco operates as the controller. Customer data in the seller's APAC support tool serves a European Newco. The TSA has to provide a lawful basis for these transfers, almost always through the European Commission standard contractual clauses or the UK international data transfer agreement. The clauses must be live on Day One and reviewed throughout the TSA as services migrate.

Disputes arise when the underlying transfer changes. A seller decides to move the hosting region for cost reasons. A subprocessor is added without consent. A jurisdiction loses its adequacy decision. The buyer that monitors transfer changes through the governance committee catches the issue early. The buyer that delegates monitoring to the seller often finds out only when a regulator asks.

Two practical defenses are worth building in. First, require notice of any change in hosting location or subprocessor with a defined objection window. Second, run a quarterly transfer review that lists every cross-border flow, the lawful basis, and the responsible owner. The review is short and dull when nothing has changed. When something has changed, it surfaces in writing.

Closing the dispute and the data flow.

Every data protection dispute closes in two places. The first is the contract record. An amendment to the data processing agreement, a side letter, or a documented change order in the change control board records the resolution and binds both parties for the remainder of the TSA. Verbal resolutions on data protection do not survive the next regulator question. The second is the operating record. The fix has to land in the actual data flow, the actual access controls, or the actual response template. A resolved dispute that did not change anything operationally is a dispute that will recur.

At exit, the data protection workstream has its own deliverable. Every personal data set in the seller's systems is either migrated to Newco systems, returned to Newco custody, or deleted under a documented protocol. The data processing agreement provides for this. The buyer's exit checklist runs through it line by line. Without that discipline, residual data lives on at the seller and remains the Newco's responsibility as controller.

Specialist support across the data protection dispute lifecycle is part of the TSA Dispute Resolution practice when the buyer needs experienced help on a contested matter. The work coordinates with privacy counsel, internal data protection officers, and the seller's legal team.

More on disputes and governance.