Cross-border technology contracts are the connective tissue of the global digital economy. They govern outsourcing relationships, SaaS deployments, cloud infrastructure, IP licensing, and data processing arrangements spanning dozens of jurisdictions. Yet despite their critical importance, these contracts remain a persistent source of disputes, many of which are entirely avoidable.
From ambiguous IP clauses that cost companies millions to liability caps that crumble under scrutiny, the pitfalls in global tech contracting are well-documented but poorly learned. This article examines the most common mistakes and offers practical guidance for avoiding them.
1. Vague Scope and Deliverable Definitions
The pitfall: Imprecise language around deliverables, timelines, and acceptance criteria is the single most frequent source of disputes in technology contracts. When a contract says "the system" or "the deliverables" without defining exactly what is included (source code, documentation, training data, model weights, configurations), the stage is set for conflict.
The case study: The TCS v. DBS dispute (2024 UK High Court) illustrates this risk at scale. A digital transformation project generated reciprocal claims exceeding GBP 200 million, with TCS claiming approximately GBP 110 million in delay damages and DBS counterclaiming roughly GBP 109 million. Ambiguity in project scope and liability cap language was central to the dispute.
The fix:
- Define deliverables with exhaustive specificity. Enumerate what is included and what is excluded
- Establish measurable acceptance criteria and testing protocols
- Include formal change management procedures for evolving requirements
- Specify milestone-based payments tied to verified deliverables, not elapsed time
2. Ambiguous IP Ownership
The pitfall: Without clear delineation of background IP (pre-existing assets), foreground IP (new deliverables), and jointly developed IP, companies risk losing control of their most valuable technology. Different jurisdictions have divergent default rules on whether IP vests in the employer, the individual creator, or the commissioning party.
A practical example: A US firm outsourcing ML algorithm development offshore may face uncertainty over whether training datasets or tuned model weights belong to them or the provider, especially when the provider's local laws assign ownership to the creator by default.
The joint ownership trap: Joint IP ownership sounds equitable but creates friction. Neither party can grant exclusive licences or assign shares without the other's consent, leading to deadlocks and exploitation of ambiguity.
The fix:
- Define ownership explicitly for every IP category: background, foreground, and joint
- Include assignment obligations and recordation assistance clauses
- Align with local employment agreement requirements in the provider's jurisdiction
- Avoid joint ownership where possible. Use reciprocal licences with use restrictions instead
- Engage transfer pricing specialists early for intercompany IP structures
3. Cross-Border Data Transfer Blind Spots
The pitfall: Nearly 100 data localisation measures exist across 40+ countries, and the regulatory landscape is in constant flux. Companies that fail to map data flows before contracting face compliance risks that can render contracts unperformable.
Key regulatory developments to watch:
- US DOJ rules (effective July 2025): Strict limits on exporting sensitive personal data to high-risk jurisdictions, extending even to anonymised and de-identified data
- India's DPDPA: Blacklist approach (transfers allowed unless destination is restricted), but no restricted countries list published yet
- EU GDPR: Transfer restrictions via adequacy decisions, SCCs, and BCRs
- China, Saudi Arabia, UAE: Strict localisation with mandatory security assessments
The Privacy Shield precedent: When the EU-US Privacy Shield was invalidated by the Schrems II decision, every organisation relying on it was immediately non-compliant. Transfer frameworks can be struck down overnight.
The fix:
- Map all data flows and identify applicable jurisdictions before contracting
- Include compliance assurances and audit rights in data processing clauses
- Build regulatory change mechanisms allowing contract adjustment when laws evolve
- Specify data storage locations, encryption standards, and breach notification procedures explicitly
- Consider privacy-enhancing technologies for cross-border collaboration
4. Liability Caps That Do Not Protect
The pitfall: Many contracts default to capping liability at fees paid in the prior 12 months, which may be entirely inadequate for catastrophic data loss or major business disruption. Worse, ambiguous cap language can drastically reduce recovery in a dispute.
The case study: In TCS v. DBS, a central question was whether a GBP 10 million liability cap applied per claim or as a single aggregate cap across all claims. The High Court ruled it was a single aggregate cap, dramatically limiting the claimant's potential recovery. The court also found that "anticipated savings" constituted excluded "loss of profits," an interpretation that the claimant had not anticipated.
The fix:
- Negotiate explicit carve-outs from liability caps for data breaches, IP infringement, confidentiality breaches, and wilful misconduct
- Use unambiguous language distinguishing different loss categories
- Ensure caps reflect the magnitude of potential losses, not just fee multiples
- Align liability caps with mandatory regulatory liabilities (e.g., GDPR fines can exceed any contractual cap)
- Include SLA escalation mechanisms, including termination rights, for persistent failures
5. Inadequate Dispute Resolution Clauses
The pitfall: Vague jurisdiction clauses (e.g., "the courts of the United Kingdom." Which courts? England? Scotland?) create enforcement nightmares. Choosing domestic litigation over international arbitration for cross-border contracts often makes judgments unenforceable in the counterparty's jurisdiction.
A practical example: A German SaaS company licensing to an Indian reseller that obtains a German court judgment will face significant obstacles enforcing it in India. International arbitration under the New York Convention, ratified by 170+ countries, offers far more reliable cross-border enforcement.
The fix:
- Opt for international arbitration in neutral venues (ICC, SIAC, LCIA, HKIAC)
- Specify the language of proceedings explicitly
- Include provisions for emergency and interim relief
- Consider multi-tier dispute resolution: negotiation, then mediation, then arbitration
- Evaluate enforcement track records in the counterparty's jurisdiction before selecting a forum
6. Multi-Jurisdictional Compliance Gaps
The pitfall: Companies with GDPR compliance programmes assume they are covered for India, California, and other jurisdictions, but critical gaps exist.
| Dimension | GDPR (EU) | DPDPA (India) | CCPA (California) |
|---|---|---|---|
| Legal basis | Six bases (including legitimate interests) | Primarily consent | Notice-based |
| Cross-border transfers | Restricted (SCCs, adequacy) | Allowed unless blacklisted | No restrictions |
| Penalties | Up to 4% global turnover | Up to ~$30M per violation | $2,500–$7,500 per violation |
| Consent model | Explicit opt-in | Consent with specific requirements | Opt-out mechanism |
A critical gap: The DPDPA does not recognise "legitimate interests" as a processing basis. Companies that have built GDPR compliance around this ground must develop entirely separate consent-based workflows for Indian data subjects.
98% of organisations report consent management as their top compliance burden when operating across multiple jurisdictions.
The fix:
- Map each jurisdiction's requirements independently. Never assume one framework covers all
- Include jurisdiction-specific data processing addenda in contracts
- Build regulatory change clauses permitting contract adjustment as privacy laws evolve
- Monitor for framework invalidation risks
7. Open Source Licensing Landmines
The pitfall: The copyleft "virality" risk is the most dangerous and least understood licensing issue in technology contracting. AGPL-licensed code, in particular, can require disclosure of an entire product's source code if the product is made available over a network, even without traditional "distribution."
The case study: In Artifex v. Hancom (2017), Hancom used Ghostscript (dual-licensed AGPL/commercial) in its office suite without acquiring a commercial licence or releasing source code. Artifex successfully sued for both copyright infringement and licence violation.
Google maintains a company-wide ban on AGPL-licensed code, a signal of how seriously sophisticated technology companies treat this risk.
Common mistakes:
- Not maintaining a Software Bill of Materials (SBOM)
- Failing to audit transitive dependencies (dependencies of dependencies)
- Assuming SaaS deployment avoids GPL obligations (AGPL closes this gap)
- Not including open-source compliance warranties in vendor contracts
The fix:
- Maintain a comprehensive, up-to-date SBOM for all products
- Implement automated licence scanning in CI/CD pipelines
- Include contractual representations that deliverables do not incorporate copyleft-licensed code (or require disclosure)
- Treat AGPL-licensed components as high-risk for any networked service
8. Vendor Lock-In Without Exit Rights
The pitfall: Lock-in occurs through three mechanisms: contractual (multi-year commitments, auto-renewal, steep termination penalties), technical (proprietary formats, non-standard APIs, incomplete export functionality), and financial (egress fees, escalating pricing, upfront payment structures).
Companies that fail to negotiate exit rights at contract formation find themselves trapped, unable to switch providers without unacceptable cost or data loss.
The fix:
- Negotiate data portability rights: standard format exports (CSV, JSON, XML), at least one comprehensive export per term at no cost, and a 30–90 day post-termination access window
- Include termination for convenience with 60–90 day notice after an initial period
- Require vendors to provide complete technical documentation for data structures and integrations
- Negotiate API access maintenance during transition periods
- Cap annual price increases contractually
- Include termination triggers for material SLA breaches, security incidents, or loss of compliance certifications
9. Tariffs and Currency Risk: The New Variable
The pitfall: Broad-based tariffs introduced in 2025–2026 have added a new dimension of risk to cross-border technology transactions. Hardware, embedded software, and even cloud infrastructure costs are affected. Currency fluctuations compound the problem, particularly for long-term contracts denominated in a single currency.
The fix:
- Include tariff adjustment clauses that allocate risk and permit renegotiation if tariffs materially affect costs
- Designate payment currency explicitly
- Incorporate exchange rate adjustment mechanisms for contracts exceeding 12 months
- Consider pricing benchmarked to a neutral index or basket of currencies
10. Lessons from Major Technology Disputes
| Case | Dispute | Key Lesson |
|---|---|---|
| TCS v. DBS (2024) | GBP 200M+ claims over digital transformation | Liability cap language must be unambiguous; loss categories must be carefully distinguished |
| Artifex v. Hancom (2017) | AGPL licence enforcement | Open-source licence violations are enforceable as both copyright infringement and breach of contract |
| NHS IT Programme (UK) | GBP 10 billion failed modernisation | Scope ambiguity + vendor mismanagement + inadequate governance = catastrophic failure |
| US v. Google (2024) | Illegal monopoly maintenance | Exclusive dealing arrangements carry antitrust risk |
A Contracting Checklist for Global Tech Deals
For organisations entering cross-border technology contracts, here is a practical minimum checklist:
Before signing:
- Map all data flows and identify applicable regulatory jurisdictions
- Define IP ownership for every category (background, foreground, joint)
- Conduct an open-source audit of all deliverables
- Verify enforceability of dispute resolution clauses in all relevant jurisdictions
In the contract:
- Exhaustive deliverable and acceptance criteria definitions
- Explicit carve-outs from liability caps for data breaches, IP infringement, and wilful misconduct
- Jurisdiction-specific data processing addenda
- Regulatory change clauses allowing contract adjustment
- Termination for convenience with reasonable notice
- Data portability and exit rights
- Tariff and currency adjustment mechanisms
- Open-source compliance representations and warranties
After signing:
- Continuous compliance monitoring across all applicable jurisdictions
- Regular SBOM updates and licence audits
- Periodic SLA performance reviews with documented escalation
- Annual contract health checks to identify regulatory or market changes requiring amendment
Conclusion
Global technology contracting is not just a legal exercise. It is a strategic discipline that requires alignment across legal, technical, commercial, and regulatory functions. The contracts that fail are not typically those missing obscure clauses; they are those built on imprecise language, untested assumptions, and a belief that one jurisdiction's standards will suffice for all.
In a world of diverging data protection regimes, escalating AI regulation, tariff volatility, and increasingly assertive enforcement, the margin for error in cross-border technology contracts is narrowing. The time to get these right is before the signature, not after the dispute.