GDPR and data residency when your software partner is outside the EU

Does the GDPR allow outsourcing development outside the EU?

Yes. The GDPR does not ban working with engineers outside the EU or EEA. It regulates what happens to personal data: Chapter V says personal data may only be transferred to a third country if the protection travels with it. A third country is any country outside the EEA, and only some of them have an adequacy decision from the European Commission recognizing their law as equivalent.

For a country without adequacy, a transfer needs an appropriate safeguard, such as Standard Contractual Clauses, or must fit a narrow derogation. Bosnia and Herzegovina, for example, is a third country under the GDPR without an adequacy decision, so work involving EU personal data relies on contractual safeguards. The UK runs a parallel regime under the UK GDPR, with its own International Data Transfer Agreement and an Addendum to the EU clauses.

What counts as a transfer in a software project?

A transfer is broader than copying a database abroad. European regulators treat remote access from a third country to data stored in the EU as a transfer, which covers an engineer querying production, reading support tickets, or pulling logs that contain user details. Hosting in Frankfurt or Dublin does not by itself take a project out of scope if people elsewhere can see the data.

Source code on its own is rarely personal data. The exposure usually comes from database dumps, crash reports, analytics exports, seed files built from real customers, and screenshots or recordings shared while debugging. Mapping those flows early is what turns a compliance question into an engineering task.

Which documents should be in place?

When the partner processes personal data on your behalf, the GDPR expects a written contract and, for third-country work, a documented basis for the transfer. In practice that means three documents, kept consistent with each other.

• A data processing agreement under Article 28: what data the partner may process, for which purposes, under whose instructions, with what security measures, which sub-processors, and what happens to the data when the engagement ends.
• Standard Contractual Clauses: the Commission's 2021 clauses, with the module that matches the relationship (controller to processor is the common case), plus the UK Addendum when UK data is involved.
• A transfer impact assessment: a documented look at whether the destination country's law and practice would undermine the clauses, and which supplementary measures (encryption, pseudonymization, access controls) close any gap.

Transfer impact assessments became standard after the 2020 Schrems II judgment, which confirmed that signed clauses alone are not enough if local law prevents the importer from honoring them. The exporter, usually you, is responsible for the assessment, but a good partner will supply the facts it needs about their own access, systems and legal environment.

How do you keep personal data inside the EU/EEA?

Contracts make a transfer lawful; architecture keeps it small. The aim is that most engineering work never touches real personal data, and the work that does is narrow, logged and revocable.

1. Host production and backups in an EU/EEA region, and check where managed services such as logging, error tracking and email delivery store their data.
2. Grant least-privilege access: no standing production access, short-lived credentials, role-based permissions, and break-glass procedures that leave an audit trail.
3. Develop and test against anonymized or synthetic data, generated by scripts in the repository instead of copied from production.
4. Scrub personal data from logs, traces and error reports at the source, so observability tools do not quietly become a transfer channel.
5. Encrypt data at rest and in transit, and keep the keys under your control where the risk calls for it.
6. Review access regularly and remove it promptly when people change roles or the engagement ends.

Be precise about anonymization. Data that can be re-identified, for example by joining it with another table, is pseudonymized rather than anonymous and is still personal data under the GDPR. Fully synthetic data generated from a schema avoids that question entirely and makes test fixtures easier to share.

How does SigmaBit handle GDPR and data residency?

SigmaBit has offices in Zenica and Tuzla, Bosnia and Herzegovina, which is a third country under the GDPR, so we address it head-on rather than leaving it to the end of procurement. Data protection is part of every engagement from day one, as a starting point and not a footnote.

• We work under contractual safeguards, including the European Commission's Standard Contractual Clauses, and the UK International Data Transfer Addendum where relevant.
• We can accommodate EU/EEA data-residency requirements for projects that need them.
• We work under non-disclosure agreements and clear contractual terms, and clients own the intellectual property we develop for them.

Our privacy policy covers how we process personal data ourselves, and the about page explains how our teams are organized. If your project has residency or transfer requirements, raise them when you contact us so they shape the architecture and the contract from the first conversation.

Is this legal advice?

No. This article is general information about how the GDPR usually applies to software engagements, not legal advice. Requirements depend on your role, the data involved and the countries concerned, and guidance from regulators changes over time, so confirm your transfer arrangements with your data protection officer or legal counsel.