Working with an engineer in India: hours, contracts and data transfers

Working with an independent engineer in India means agreeing three things up front: which hours you'll share, what the contract says about ownership and confidentiality, and how personal data may lawfully reach someone outside your country. None of them is hard, but each is easier before the work starts than in the middle of it.

I'm a senior software engineer in Mumbai, and I work with teams in the US, the UK, the EU, the Gulf, Japan and South Korea. This is what I agree with each of them. It's engineering experience, not legal or tax advice: the contract and data sections end with your counsel, and anything about tax belongs with your accountant.

How many working hours will we share?

India is UTC+5:30, and the clock changes you'll notice are on your side. The UK moves its clocks on the last Sunday in March and the last Sunday in October, according to GOV.UK; the EU's summer-time Directive sets the same Sundays for member states; and in the US, NIST gives the 2026 daylight-saving period as 8 March to 1 November. Each change moves our shared window by an hour.

The useful question isn't how many hours overlap but what they're for. Shared hours go to decisions: a stand-up, a demo, a design review. Everything else runs on writing: a daily or weekly update you can read on your schedule, recorded walkthroughs, and decisions written down with their reasons. A team on the West Coast can work well with someone in Mumbai if the writing is good; a team in Dubai can work badly with someone next door if it isn't.

Holidays matter too. I keep your public holidays in my calendar, and for Japan, Korea and the Gulf I plan around the long ones in advance.

What should the contract cover?

I can work under your master services agreement with a statement of work per project, or under mine. Either way, these are the clauses I make sure exist:

• Scope, deliverables and acceptance. What done means, in writing, before the build starts.
• Price and payment. Fixed price per scope or milestone, or a monthly retainer, with the currency stated.
• Intellectual property. Assigned to you on payment, with the code in your repository from the first day, so there is never a question about who owns it.
• Confidentiality. An NDA before we discuss details, or a confidentiality clause in the agreement.
• Data protection. A data processing agreement whenever I handle personal data on your behalf. Under the GDPR, Article 28 sets out what a contract with a processor must contain, and the UK GDPR has the same requirement.
• Security. How credentials are issued, what I may access, and how access is revoked at the end.
• Termination and handover. Notice periods, and what you receive when the engagement ends: the runbook, the documentation and a handover session.
• Governing law and disputes. Usually your jurisdiction, chosen by your counsel.

Whether any of this changes how you treat me for employment-status purposes, and how invoices from India are treated for tax, are questions for your accountant. I won't guess at them here.

Is my access from India a data transfer?

Usually, yes, and it's better to plan for that than to argue it away. Two things are easy to get wrong.

First, keeping the data in your own infrastructure doesn't by itself avoid a transfer. The European Data Protection Board's Guidelines 05/2021 say that remote access from a third country, even just displaying personal data on a screen for support or administration, is considered a transfer. It still helps a great deal to work inside your systems: the data stays stored where you control it, access can be narrow and logged, and it's revoked in one place. But the transfer rules still apply.

Second, India has no EU adequacy decision. The European Commission's list of adequacy decisions includes countries such as Japan, the Republic of Korea and the United Kingdom, but not India. So a transfer to me needs an appropriate safeguard under Article 46 of the GDPR.

Which safeguard do EU and UK clients use?

EU and EEA clients generally use the Standard Contractual Clauses adopted by the Commission in Implementing Decision (EU) 2021/914. They come in modules; where you are the controller and I am your processor, the relevant one is Module Two, controller to processor. Your counsel decides whether a transfer impact assessment or supplementary measures are needed.

UK clients have their own instruments. The ICO lists the International Data Transfer Agreement (IDTA) and the International Data Transfer Addendum to the EU clauses among the appropriate safeguards, alongside a transfer risk assessment, which UK legislation now calls a "data protection test".

Other markets have their own rules on sending personal data abroad: Saudi Arabia's Personal Data Protection Law, Japan's APPI and Korea's PIPA among them. The market pages list the regime that applies in each and link the regulator.

In every case, confirm the right mechanism with your counsel; I'll sign whichever one they choose and implement the technical measures it calls for.

What does India's own law say about your data?

India's Digital Personal Data Protection Act, 2023 has a specific exemption for this situation. Section 17(1)(d) says that much of the Act, including most of the duties in Chapter II and the rights in Chapter III, doesn't apply where personal data of people outside India is processed under a contract with a person outside India by a person based in India. The exemption keeps sub-sections (1) and (5) of section 8 in force, and section 8(5) requires reasonable security safeguards to prevent a personal data breach. In short: your law governs your users' data, and I still have to protect it. As with everything here, confirm the position with your counsel.

What does a good working rhythm look like?

The one I use:

1. A written brief and a short call to agree what you need, by when, and what success looks like.
2. A small, fixed-price first step with a written outcome: an audit, an assessment or a scoping sprint. You see how I work before committing to more.
3. Scope in writing: deliverables, timeline, price and what's out of scope.
4. Build in the open: work on a staging URL, a written update every week, a demo whenever there's something to see, and calls in your working hours.
5. Handover or keep going: documentation, a runbook and a handover session, then a retainer if you want ongoing help.

How I do this

Every engagement I take starts with the hours, the contract and the data question settled in writing, before any code. If you're a founder without a technical lead, a fractional CTO role or an architecture review is the usual first step; for a new product, the MVP Sprint begins with a scoping week. The market page for your country has the overlap table, the contract terms I work under and the data-protection rules I design for.