Who is the data controller and who is the processor when you hire a nearshore developer?

In a typical nearshore staff-augmentation engagement, the hiring company remains the GDPR data controller: it decides why and how personal data is processed. The nearshore engineer works inside the client's own systems under the client's instruction, so the engineering partner, like HighCircl, is not usually a separate data processor unless its own systems handle that data.

Controller and processor, as GDPR actually defines them

GDPR Article 4(7) defines the controller as whoever decides the purposes and means of processing personal data. Article 4(8) defines the processor as whoever processes that data on the controller's behalf, under the controller's instruction. Which one a nearshore engineering partner is in your engagement depends on how the work is structured, not on how the vendor markets itself.

Why staff augmentation usually keeps you as the sole controller

In a typical embedded staff-augmentation setup, the nearshore engineer logs into your GitHub org, your cloud accounts, and your ticketing system, and works under your day-to-day direction. Because the engineer isn't running separate systems that independently process your data, there's usually no second controller-processor relationship to document. The engineer functions as an extension of your own team for GDPR purposes, and you stay the sole controller.

That changes if the vendor hosts your data on its own infrastructure, an outsourced dev shop running its own servers, or a vendor-owned time-tracking tool that stores names and emails belonging to your team or your customers. At that point the vendor is processing data on your behalf through its own systems, which makes it a processor, and Article 28 obligations attach. Whether a written agreement is required in that case, and what it has to cover, is a separate question, answered in do you need a data processing agreement when hiring nearshore developers.

Where geography changes the picture, and where it doesn't

The controller-processor split above doesn't move with geography. It holds the same way whether the engineer sits in Warsaw or anywhere else. What geography adds is a separate question on top: moving personal data outside the EU/EEA, to a country without a European Commission adequacy decision, triggers an Article 46 transfer mechanism such as Standard Contractual Clauses, regardless of who is controller and who is processor.

That distinction matters for HighCircl's own bench. Poland, Hungary, Slovakia, Slovenia, Romania, and Spain are EU member states, so a placement there sits inside the EU/EEA transfer framework by default. Serbia is an EU candidate country, not a member state, and holds no European Commission adequacy decision. A placement in Serbia is a third-country transfer under Chapter V and needs the same SCC and transfer-assessment treatment as any other non-adequate country, on top of whatever DPA the underlying processing relationship already requires.

Related Sources

  1. GDPR (Regulation (EU) 2016/679), Articles 4 and 28
  2. European Commission, adequacy decisions

Author Image

HighCircl Editorial Team

The HighCircl editorial team writes about hiring software engineers, nearshore development, and engineering team building. Our articles draw on direct experience sourcing and placing senior developers across Poland, Hungary, Slovakia, Serbia, Slovenia, Romania, and Spain — and on candid conversations with the CTOs and engineering leads who hire them.

HighCircl is a nearshore engineering network that delivers matched candidate shortlists in 72 hours. Every piece of content we publish is informed by real engagement data: actual developer rates, real hiring timelines, and what separates engineering teams that scale cleanly from those that stall.

Take Me to the Experts

Access our network of industry-leading software engineers.

Start Now