Protecting your IP and data when you outsource software development

You protect your IP when outsourcing software development in two places: the contract and the day-to-day setup. The contract says you own everything the team creates. The setup lets you prove and enforce that, because the code, the accounts and the data stay in systems you control. Most IP problems start in the gap between the two.

This is practical guidance from a delivery team, not legal advice, so have a lawyer in your own country review your contracts.

Sign an NDA before you share the details

A non-disclosure agreement (NDA) covers the conversations that happen before a contract exists: your product idea, your data model, your customer list, your pricing. Ask for one before you share anything you'd mind a competitor seeing. A serious partner won't hesitate, and we sign one before you share anything sensitive with us.

Check three things in it: what counts as confidential, how long the duty lasts, and that it covers the partner's staff and any subcontractors, not just the company.

Put IP assignment in the service agreement

An NDA keeps things secret. It doesn't make you the owner of the code. Ownership needs its own clause in the main contract, assigning all rights in the work to your company.

Don't assume that paying for the work makes you the owner. Under US copyright law, for example, work commissioned from an outside party is only a 'work made for hire' if it falls into one of nine listed categories and both sides sign a written agreement saying so. If it fails any of those tests, the person who created it is ordinarily the author. The rules differ by country, which is why an explicit assignment clause matters wherever you are.

A good IP clause covers:

• Source code, designs, documentation, test scripts, infrastructure definitions and data models, not just 'the software'.
• Work in progress, so you own unfinished work if the engagement ends early.
• When ownership passes to you, for example as the work is created or as each milestone is paid.
• A promise that the partner's staff and subcontractors have assigned their rights to the partner, so the partner can pass them on to you.
• A list of anything the partner already owned before the project, with a licence for you to keep using it.

Our clients own 100% of the code, designs and IP, and that is written into the service agreement from the start. Whoever you work with, ask to see the exact clause before you sign.

Keep the code in repositories you own

The simplest protection is practical. Create the code repositories in your own GitHub, GitLab or Bitbucket organisation and add the partner's engineers as members. Do the same for the cloud accounts, domain names, app store accounts and issue tracker.

If the partner builds in its own accounts and promises to transfer everything at the end, you depend on that promise and on the transfer going smoothly. If the work lives in your accounts from day one, there is nothing to hand back. Our squads work this way: they join your Slack, Jira and GitHub, with clear access and responsibilities for each person.

Give each person only the access they need

Access control is where good contracts meet daily habits. A checklist for any outside team:

• Named accounts for every engineer, with no shared logins, so every action can be traced to a person.
• Single sign-on and multi-factor authentication on the repository, cloud console and tracker.
• Least privilege by default: developers get the environments they work in, not admin rights to production.
• Masked or made-up test data for development and testing, with real customer data only where there is no alternative.
• Admin access granted for a specific task and removed automatically afterwards.
• A regular access review that compares who has access with who is still on the project.

Temporary admin access is easier to run than it sounds. At one fund manager, 80% of staff held permanent Admin or Editor access to environments they only needed for seasonal reporting. We replaced those rights with a just-in-time request flow that grants privileged access for 4-hour windows through automated Slack approvals.

Plan offboarding before anyone leaves

Access tends to grow quietly and is rarely taken away. When someone leaves the project, or the engagement ends, remove their access the same day. Keep a written offboarding list:

1. Remove the person from the repository, cloud accounts, tracker, chat and shared drives.
2. Revoke personal access tokens and SSH keys linked to their account.
3. Rotate any password, secret or API key they could have seen.
4. Check that their work is merged, documented and owned by someone else.
5. Ask the partner to confirm in writing that copies of your code and data have been deleted from its devices.

When a whole engagement ends, use a fuller process. Our software project handover checklist covers code, infrastructure, credentials and knowledge transfer.

Keep secrets out of the code

Passwords, API keys and certificates should never sit in the repository, in configuration files or in chat messages. Store them in a secrets manager, such as the one your cloud provider offers, and let the deployment pipeline fetch them when it needs them. Add secret scanning to every pull request, so a key that slips into the code is caught before it is merged. Our post on DevSecOps in the delivery pipeline shows where these checks fit.

Agree how personal and customer data is handled

If the team will handle personal data, agree in writing how it is processed. Under laws such as GDPR this is usually a data processing agreement. Whatever the format, it should answer four questions:

• Which data the team can see, and in which environments.
• Where the data is stored, and in which countries.
• How long it is kept, and how it is deleted.
• How quickly the partner must tell you about a security incident.

The safest data is data the team never receives. Masked copies of production data cover most development and testing needs.

Check open-source licences

Most modern software is built on open-source packages, and each one comes with a licence. Permissive licences such as MIT mainly ask you to keep the copyright and licence notices. Strong copyleft licences such as the GPLv3 go further: if you distribute software that includes the code, you must make the complete source code, including your larger work, available under the same licence. That matters if you sell or ship the software to customers.

Ask the partner to keep a list of every package and its licence, check new packages against the licences your company accepts, and flag any copyleft licence before it is added. Dependency scanning tools can run these checks on every pull request.

Where to start

Before your next outsourcing contract, check four things. An NDA is signed before details are shared. The service agreement assigns all IP to you. The repositories and cloud accounts are in your company's name. Someone on your side owns the offboarding list. Those four close most of the gaps.

If you are about to bring in a new partner, our post on onboarding a software development partner covers the first weeks. To have an NDA signed before you share any project details, get in touch.