UK GDPR and Outsourced Software Development: A Checklist for UK Companies

Everything below depends on this question. Writing a calculation engine or a user interface on dummy data does not involve personal data. Connecting to your live customer database, reading production logs, or fixing a bug using a real customer record does.

Many projects touch personal data more than the owner realises:

• test databases copied from production
• support tickets and screenshots that contain names or addresses
• error logs with email addresses or IDs
• analytics and monitoring tools that record user sessions
• email and chat exports shared to explain a requirement

Map where personal data would be exposed, then remove as much as you can. Anonymised or synthetic data in development, with production access limited to named people for a limited time, is the most effective single control in this whole list.

When you decide why and how personal data is used, you are the controller. A software supplier that handles that data on your instructions is a processor. The ICO's guidance on contracts between controllers and processors explains the split. As controller you remain responsible for choosing a processor that offers sufficient guarantees and for checking compliance on an ongoing basis. Signing a contract does not move that responsibility to the supplier.

If the supplier also decides for its own purposes how to use your data, for instance to train its own products, the relationship changes. Rule that out in the contract.

UK GDPR requires a written contract. The ICO page on what needs to be included lists the mandatory terms. Tick each one off against your draft.

• The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of people.
• Processing only on your documented instructions. The ICO says email counts, provided it can be saved.
• A confidentiality commitment for everyone who handles the data.
• Appropriate security measures.
• Sub-processors used only with your authorisation, and bound by equivalent terms.
• Help with data subject requests, for example when someone asks for a copy of their data.
• Help with your own obligations on security, breaches and impact assessments.
• Return or deletion of data at the end of the contract, at your choice.
• Audits and inspections, and information to show compliance.

Note that the ICO's processor guidance carries a notice that it is under review following the Data (Use and Access) Act 2025, so check the current page when you draft. The Act is on legislation.gov.uk.

A UK business sending personal data to a supplier in India makes a restricted transfer. India is not covered by UK adequacy regulations, so you need an appropriate safeguard. The ICO's international transfers guidance covers the options. For an ordinary services contract that means either:

• the International Data Transfer Agreement (IDTA), or
• the UK Addendum to the EU Standard Contractual Clauses.

Both have been available since 21 March 2022. You also need to assess the transfer. The Data (Use and Access) Act 2025 reworded this: the ICO says the transfer risk assessment is now called the data protection test in legislation, and the provisions took effect on 5 February 2026. In plain terms you must be able to show, reasonably and proportionately, that the protection your data receives in India after transfer is not materially lower than under UK data protection law. The ICO's transfer risk assessment page explains what to document.

Practical items to record: where the data is stored (a UK or EU cloud region keeps data off Indian servers entirely, though remote access by Indian staff is still a transfer), who can access it, how access is authenticated, and what the supplier does if a government body asks for it.

Your supplier will use cloud hosting, email, error tracking and perhaps freelancers. Each one that touches your data is a sub-processor.

• Ask for the list before signing, and for notice of any change.
• Require the supplier to flow the same data protection terms down to each one.
• Check that the supplier stays fully liable to you for their sub-processors' compliance, which the ICO notes is the legal position.
• Ban the use of freelancers or other subcontractors on your data without written approval.

The NCSC publishes supply chain security guidance that is useful when you want a structured way to question a supplier.

UK GDPR requires security that is appropriate to the risk, and the ICO's security guidance is the starting point. For a development project, ask your supplier to show you, in writing:

• developers use company-managed machines with disk encryption, and work on your data only inside agreed environments
• access to production is granted by name, uses multi-factor authentication and is removed when the task ends
• secrets and keys are kept out of source code
• code is reviewed before release, with a record of who approved it
• backups are encrypted, and restore has been tested
• the product is designed to collect only the data it needs, which the law calls data protection by design and by default

If the new system will process personal data in a way likely to put people's rights at risk, for instance large-scale monitoring or sensitive data, you may need a data protection impact assessment before you build. The ICO explains when in its DPIA guidance.

Agree the operating rules before anything goes wrong.

• Breach notice. As controller you must tell the ICO about a notifiable personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. See the ICO's guide to personal data breaches. Your contract should make the supplier tell you quickly, with a named contact available out of hours.
• Requests from individuals. Agree how the supplier helps you find, correct or delete a person's data, so that you can answer within the legal time limit.
• Exit. On termination the supplier returns or deletes data as you choose. The ICO accepts that backups may not be wiped instantly if the data is put beyond use and later overwritten, but get that in writing.
• Evidence. Keep the signed contract, transfer safeguard, assessment and sub-processor list together. If the ICO ever asks, you will want one folder.

DipanshuTech is a software company in Greater Noida. We do not hold any security certification that we can cite here, so we do not claim one; instead we work from your contract and your checklist. We sign an NDA on request, keep source code and accounts in the client's name, and prefer to build on synthetic data so that live personal data stays with you. If you want to see how we approach British projects, read our UK software development page or the UK overview.

Is an Indian software developer a data processor under UK GDPR?

If they handle personal data on your behalf, yes. You then need a written Article 28 contract, and because the supplier is outside the UK you need a transfer safeguard such as the IDTA or the UK Addendum as well.

Do we need a transfer risk assessment if developers only see test data?

If the test data contains no personal data, UK GDPR does not apply to it and no transfer arises. Be certain it is genuinely synthetic or fully anonymised, because copies of production data with names removed can still identify people.

Who is liable if our outsourced developer causes a breach?

Both of you can be. The controller stays responsible for choosing a suitable processor and for notifying the ICO. A processor that breaches its obligations can be liable too. Your contract should deal with indemnity and insurance, which a solicitor should check.

How long do we have to report a breach?

Notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of a notifiable breach, as set out in the ICO guidance.

If you are preparing to appoint a development partner and want to see how a supplier answers these questions, talk to us. Bring your checklist and we will answer it in writing before any work starts.