Why the DPA requirement doesn't disappear with EU-based engineers
Article 28(3) of GDPR spells out what happens the moment a processor touches personal data on a controller's behalf: there has to be a written contract covering the scope, nature, purpose, and categories of data involved. Nothing in that article carves out an exception for processors sitting inside the EU. The obligation is triggered by the processing relationship itself, not by geography.
Buyers tend to conflate two separate questions. The first is whether a controller-processor contract is required at all, and the answer is always yes once a processor is in the picture. The second is whether an international-transfer safeguard, an SCC or an adequacy check, applies, and that only comes up when data moves into a country outside the EU/EEA framework. Nearshore vendors who market themselves as "GDPR by default" are usually right about the second question. They aren't exempt from the first.
What the DPA must actually cover
Article 28(3) sets a minimum list of terms the contract has to include:
- Subject matter and duration of the processing
- Nature and purpose of the processing
- Type of personal data and categories of data subjects involved
- The processor's obligations, including documented instructions from the controller, confidentiality commitments, and security measures under Article 32
- Rules on engaging sub-processors
- Assistance with data subject rights requests
- Deletion or return of data when the contract ends
- Audit rights for the controller
Whether you need one at all with a staff augmentation vendor comes down to how the engagement runs. If the engineers work inside your own systems, under your instruction, using your accounts and infrastructure, you likely remain the sole controller with no separate processing relationship to document. If the vendor's own systems touch client data instead, through its own time-tracking tools, code repositories that include personal data, or ticketing systems with names and emails, then the vendor is a processor and a DPA with that vendor entity is required.
Nearshore vs. offshore: what actually changes
Nearshore inside the EU removes the transfer paperwork, not the processor contract. Place the work in Poland or Romania and the Article 28 DPA obligation stays exactly where it was, but the extra layer of Chapter V transfer machinery drops away: no Standard Contractual Clauses, no transfer impact assessment, no adequacy check. An EU-to-EU data flow already sits inside the framework, the same as any domestic processor arrangement.
Move the work to a country without an EU adequacy decision, India or the Philippines for example, and you need the DPA plus an Article 46 transfer mechanism such as SCCs. Running a transfer impact assessment alongside the SCCs is standard practice for these transfers, even though it isn't spelled out in Article 28 itself.
Bench composition matters here too. HighCircl's nearshore engineering bench spans six EU member states, Poland, Hungary, Slovakia, Slovenia, Romania, and Spain, alongside Serbia, which is an EU candidate country rather than a member state and holds no European Commission adequacy decision. A Poland or Romania placement skips the SCC step for the reasons above. A Serbia placement is a third-country transfer under Chapter V and needs the same SCCs and transfer assessment as any non-adequate country, on top of the Article 28 DPA every processor needs regardless of where it sits. Data-residency pressure under GDPR and the EU AI Act is one of the reasons procurement teams are checking this distinction more closely in 2026.
