Outsourcing Software Development: Contract, IP and GDPR Checklist

Most outsourcing problems that end up with lawyers start as gaps in the contract: nobody wrote down who owns the code, who holds the cloud accounts or what happens when the engagement ends. This checklist covers the clauses to agree before development starts. It is a practical guide, not legal advice — have your lawyer review the final agreement.

1. Intellectual property: get a written assignment

Paying for code does not automatically make it yours. In the US and the UK, copyright in software written by an independent contractor generally stays with the contractor unless there is a written assignment. Your contract should assign all rights in the deliverables to you, and say when that happens — commonly on payment of each invoice.

• Assignment of all IP in deliverables: source code, designs, documentation, tests and infrastructure code.
• A licence for any pre-existing tools or libraries the vendor brings, so you can keep using them after the engagement.
• A waiver or non-assertion of moral rights where local law allows it.
• Confirmation that individual developers have assigned their rights to the vendor, so the chain of title is complete.

2. Open-source software

Almost every modern product is built on open-source packages, and that is fine — as long as the licences fit your business. Permissive licences (MIT, BSD, Apache 2.0) rarely cause problems. Strong copyleft licences such as GPL or AGPL can require you to publish your own source code in some distribution or hosting scenarios. Ask for a dependency and licence list at each release and agree which licences need your approval.

3. Personal data and GDPR

If the vendor will access personal data of people in the EU or UK — production databases, user records, support tickets — they act as your processor. GDPR Article 28 requires a written data processing agreement (DPA) that covers, among other things:

• Processing only on your documented instructions, for a defined purpose and duration.
• Confidentiality obligations for everyone with access.
• Appropriate security measures (Article 32) — access control, encryption, logging.
• Your prior authorisation for sub-processors, with the same obligations passed down.
• Help with data subject requests, breach notification and data protection impact assessments.
• Deletion or return of personal data when the engagement ends, and your right to audit.

If personal data leaves the EU/EEA for a country without an EU adequacy decision, you also need a transfer mechanism under GDPR Chapter V — usually the European Commission’s Standard Contractual Clauses (2021) plus a transfer risk assessment. For UK data, use the UK International Data Transfer Agreement or the UK Addendum to the EU clauses. The simplest risk reduction is architectural: give the vendor anonymised or synthetic data for development and keep production access to a minimum.

4. Confidentiality

Sign a mutual NDA before sharing your roadmap or code, and make sure the main contract carries confidentiality obligations that survive termination. Define what counts as confidential, the exceptions (public information, independently developed work) and how materials are returned or destroyed.

5. Accounts, access and handover

• Code lives in a repository owned by your organisation from day one, not the vendor’s.
• Cloud, domain, app store, analytics and third-party accounts are registered to your company; the vendor gets role-based access.
• Secrets are kept in a password manager or secret store you control — never in the code.
• Documentation is a deliverable: setup instructions, architecture notes, deployment runbooks.
• Offboarding is defined: access is revoked and credentials rotated when people leave the project.

6. Scope, acceptance and change

Whatever the pricing model, write down how work is accepted and how changes are handled. Fixed-scope contracts need clear acceptance criteria and a change-request process; time-and-materials contracts need reporting, budget caps or alerts and the right to reprioritise. Our comparison of fixed price vs time and materials covers when each model fits.

7. Warranty, support and liability

• A warranty period after release during which defects are fixed at no extra cost.
• Support terms if you need them: response times, hours of coverage, how incidents are reported.
• Limitation of liability that is proportionate to the contract value, with sensible carve-outs (confidentiality, data protection, IP infringement).
• Professional indemnity insurance, if your risk profile or customers require it.

8. Termination and exit

Plan the exit while everyone is still friendly. Agree a notice period, what is delivered on termination (code, documentation, data, credentials), transition assistance if you move to another team or in-house, and payment for work in progress. A short non-solicitation clause is common in both directions; make sure it is reasonable in length and scope.

Quick test: if the vendor disappeared tomorrow, could another team clone the repository, deploy the product and log into every service within a day? If not, fix that first.