GDPR Compliance for Belarusian IT Vendors Working With EU Clients

Here’s a pattern we’ve been seeing for the past two years.

A Belarusian IT company wins the technical conversation with a European client. Strong portfolio, solid references, the chemistry is right, the price is competitive. Everyone on the call thinks the deal is close to done. Then the conversation moves to legal and compliance — and somewhere between the proposal and the signed contract, the deal goes quiet. Sometimes the EU client comes back with a polite “we’ve decided to go with a vendor closer to home.” More often they just stop replying.

The blocker is usually the data protection conversation. Sometimes formally — the GDPR review fails some specific test. More often informally — the EU client’s internal compliance team flags Belarus as a third country, the procurement process gets harder, the deal slips a quarter, and the contract ends up in Warsaw or Bucharest.

This article walks through what’s actually happening on the other side of that compliance review. What EU clients are really asking. Where the friction sits for a Belarus-based vendor, specifically. And what the practical setup looks like in 2026 — the one that gets through procurement instead of getting parked there.

Standard caveat first. We’re a recruitment agency, not a law firm. We hear this conversation from both sides of every placement, but for the legal mechanics of your specific contract you need a qualified data protection lawyer. What this article gives you is the lay of the land.

The starting fact that most people misunderstand

Belarus is not on the EU adequacy list. This single fact drives most of what follows in this article, and it surprises many Belarusian IT companies the first time they encounter it.

Under the GDPR, personal data of EU residents can move freely inside the European Economic Area, plus to a small list of countries the Commission has decided offer “adequate” protection — the UK, Switzerland, Japan, South Korea, Israel, a few others. Belarus is not on that list. So any transfer of personal data from an EU client to a Belarusian processor is a transfer to a third country, and Chapter V of the GDPR kicks in. You need an additional legal basis. Almost always that means the European Commission’s Standard Contractual Clauses — and since the Schrems II judgement in 2020, a Transfer Impact Assessment on top.

This is the part where Belarusian IT companies sometimes push back: “But we have Belarusian Personal Data Protection Law compliance. Law No. 99-Z of 2021. Doesn’t that count?”

It counts for what Belarusian law requires of you domestically. It does not substitute for the EU-side mechanics. The Belarusian law was built broadly on GDPR principles, but it hasn’t been recognised as adequate by the Commission, and EU clients still treat Belarus as a third country. Having local compliance is necessary; it just isn’t sufficient. The EU client needs their own transfer paperwork in place regardless of what you’ve done locally.

This isn’t unique to Belarus. Most countries outside the EEA are in the same position. The point is that hearing “we have a privacy policy that mentions GDPR” doesn’t carry the weight some Belarusian vendors think it does in a European procurement conversation.

What EU clients actually ask — and what they’re really worried about

From conversations with our placement clients on both sides, the questions that come up most often during procurement:

“Where is the data hosted?” — they want to know if EU personal data ever physically leaves the EU.
“Where are your engineers located?” — because a Belarusian engineer accessing data sitting in an EU data centre is itself a transfer under GDPR, even if the data doesn’t move.
“Do you have Standard Contractual Clauses in place?” — at this point this is table stakes, not a differentiator.
“Have you done a Transfer Impact Assessment for Belarus?” — increasingly common in 2025 and 2026, used to be rare.
“What does Belarusian law say about government access to personal data?” — the Schrems II concern, applied directly to your jurisdiction.
“Are you GDPR-compliant?” — the question that doesn’t quite mean what it sounds like. What they actually mean is: can you sign our Data Processing Agreement, pass our security review, and not create a problem for our compliance team.
“Do you have a Data Protection Officer?” — sometimes legally required, often expected even where it isn’t.

What they’re actually worried about underneath these questions usually isn’t the formal law. It’s a reputational risk. Audit trail risk. The possibility that a data subject brings a complaint, a regulator opens an investigation, and a Belarusian vendor’s documentation becomes the EU client’s problem — not the vendor’s. The EU client is the data controller. They carry the liability under GDPR. Your job in procurement is to convince them that working with you doesn’t increase their risk surface in a way they can’t defend later.

The Schrems II problem, in plain English

In July 2020 the Court of Justice of the European Union issued the Schrems II judgement, which changed the practical conversation around third-country transfers. The headline finding was that the EU–US Privacy Shield was invalid. The broader finding, which matters more for everyone else, was that SCCs alone aren’t enough.

The court held that the EU exporter has to assess whether the recipient country’s laws and practices allow public authority access to personal data in ways that would conflict with the rights guaranteed by EU law. If they do, the exporter needs supplementary measures to bring the protection back up to an essentially equivalent level — or they shouldn’t be transferring the data at all.

The European Data Protection Board published recommendations on supplementary measures the following year, and those recommendations now sit at the centre of every serious procurement review involving a third-country vendor. For a Belarus-based vendor, the honest TIA conversation includes the Belarusian Personal Data Protection Law as a domestic framework, the operational realities of state access to data held by Belarusian companies, and the specific supplementary measures the vendor takes to mitigate identified risks.

Encryption in transit and at rest, with key management held outside Belarus. Strict access controls and logging. Pseudonymisation of personal data wherever the use case allows. Data minimisation — engineers shouldn’t have access to data they don’t need for the task. Clear documentation of who can access what, and an audit trail that shows it.

Here’s the part that separates a useful TIA from a useless one. A TIA that says “Belarus poses no concerns, no supplementary measures required” is the TIA that fails a senior compliance review on the EU side. A TIA that says “here are the realistic concerns about state access, here are the specific mitigations we have in place, here’s why this particular data set can be transferred under these specific safeguards” — that’s the document EU compliance teams will actually accept. Honesty in the assessment is what gets it approved.

The contract layer — SCCs, DPAs, and what foreign counsel expects

The contractual stack a Belarusian vendor needs for EU work is fairly standard at this point. Three documents do most of the work.

Standard Contractual Clauses (2021)

The European Commission’s updated SCCs were adopted in June 2021 and have been the working transfer mechanism since. They come in modular form — controller-to-controller, controller-to-processor, processor-to-processor — and the Belarusian vendor signs whichever module matches the role they’re playing. Most often that’s the processor or sub-processor. The Commission keeps the official SCC text and guidance up to date.

Data Processing Agreement (Article 28 GDPR)

The EU client, as controller, will want a DPA defining the scope of processing, the purposes, the categories of data, the security measures, sub-processor rules, breach notification mechanics, and audit rights. Sometimes the DPA is a separate document; sometimes it’s incorporated into the main services agreement as an annex. The Belarusian vendor’s job is to read it carefully before signing — not after.

Sub-processor chain documentation

Anyone touching the personal data on your behalf counts as a sub-processor — cloud providers, third-party tools, downstream contractors, all of them. The DPA will ask you to name them, obtain the client’s sign-off, and notify the client when the list changes. Vendors who skip the documentation step end up in awkward conversations several months in, when an audit turns up a relationship nobody told the client about.

One mistake we see often. EU procurement teams present their standard DPA to the Belarusian vendor, and the vendor signs it without carefully reading the operational obligations. Then a year later, something happens — a small data incident, a sub-processor change, an audit request — and obligations the vendor can’t actually deliver come into focus. Notification timelines that are unrealistic. Audit rights that would require disclosure beyond what the vendor can disclose. Negotiate at the signing stage. Don’t be afraid to mark up the DPA. EU clients respect a vendor who reads what they’re signing more than one who just signs it.

The technical and organisational setup that actually works

Past the paperwork, there’s the operational stack the EU client’s security team will want to see. The practical defaults for a Belarusian IT vendor working with EU customers in 2026:

EU-hosted infrastructure as the default — AWS Frankfurt, Azure West Europe, Google Cloud Belgium. This single architectural decision removes a meaningful portion of the transfer conversation, because the data physically remains in the EU and only the access component is cross-border.
Access control and audit logging, identifying who accessed what data, when, and for what purpose, retained in accordance with contractual and jurisdictional requirements, and available to the EU client on request during audit.
Encryption in transit (TLS) and at rest, with key management held in the EU where the use case permits. Encryption is one of the core supplementary measures identified in the EDPB recommendations.
Pseudonymisation and data minimisation. Engineers working on production data should be working on the minimum necessary subset, pseudonymised where feasible. Production data on development laptops is among the fastest routes to a failed security review.
A designated DPO where Article 37 GDPR requires one — large-scale systematic monitoring, large-scale processing of special category data. Even where designation is not strictly mandatory, having one named and reachable signals seriousness to the EU client.
A documented breach notification procedure aligned with the 72-hour clock. The procedure must be written, tested, and known to the operational team — not assembled in the moment an incident occurs.
A maintained, disclosed, and updated sub-processor list, with change notification mechanics agreed with the client in advance.
For HTP-resident companies, much of this is already standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contractual conversation more straightforward. For non-HTP companies, the gap is typically wider, and that is where setup work tends to concentrate before serious EU engagements can be signed.

For HTP-resident companies, much of this is already part of standard enterprise practice. The High-Tech Park framework supports paperless contracting, English-language commercial relationships, and elements of English commercial law — all of which make the EU-facing contract conversation smoother. For non-HTP companies, the gap is usually wider, and that’s often where setup work concentrates before serious EU contracts can be signed.

The part nobody talks about openly: the sanctions overlay

Here’s the section that distinguishes an honest article from a marketing piece. Some EU clients have internal procurement policies that go beyond what GDPR strictly requires. They won’t process personal data through vendors based in countries on certain sanctions lists, regardless of whether the GDPR-compliant mechanics are in place. This isn’t a GDPR question. It’s a procurement policy question. And it’s increasingly the actual reason Belarusian IT vendors lose European deals.

The formal GDPR conversation can be passed. The internal policy filter is harder, because it’s not a legal test — it’s a risk-appetite test set by the EU client’s own compliance leadership. Sometimes the bar is unreachable from Belarus regardless of how good the vendor’s documentation is. Other times it’s manageable, but requires the vendor to think about structure rather than just compliance.

The structural responses Belarusian vendors actually use in 2026 cluster into three patterns.

Belarus-only with strong documentation

The vendor contracts directly with the EU client from Belarus, with SCCs, DPA, TIA, and the full operational stack. Works for smaller EU clients without restrictive procurement policies, or for clients where the relationship pre-dates the policy tightening. Cost-effective. Won’t work for tier-one enterprises with strict third-country policies.

Belarus plus an EU entity

The vendor establishes a subsidiary or branch in an EU jurisdiction — Poland, Lithuania, Cyprus are the common choices — that contracts with EU clients directly. The Belarusian entity becomes an intragroup sub-processor under the EU subsidiary’s primary contract. Significantly easier to clear procurement. More expensive to set up and maintain. Doesn’t eliminate the underlying GDPR mechanics — the intragroup data flow still requires SCCs and a TIA — but it changes the commercial-facing structure to something EU procurement teams find easier to accept.

Belarusian vendor as a sub-supplier under an EU prime

The EU client signs a contract with an EU-based prime contractor, and the prime contractor subcontracts the work to the Belarusian vendor. The compliance umbrella belongs to the prime. The contract paperwork largely lives in the relationship between the prime and the end client. This works well when the EU client needs an EU-headquartered counterparty on the front of the contract but is comfortable with the actual delivery happening from a third country further down the chain.

None of these three structures makes the underlying compliance questions go away. What they do is take friction out of procurement. The honest read for a Belarusian vendor: when a pipeline keeps stalling at the compliance step, the problem isn’t always the paperwork — sometimes it’s the structure itself. And if that’s the case, no amount of additional documentation fixes it. The fix has to be structural too.

Common mistakes Belarusian IT vendors make

The patterns we see consistently.

Treating compliance as a website privacy policy

“We have a GDPR-compliant privacy policy on our site.” This is necessary but is not what an EU client’s procurement review is asking about. They’re asking about an operational system — documented, auditable, defensible under scrutiny. The privacy policy is the cover page. The substance is the operational stack behind it.

Signing the EU client’s DPA without reading the operational obligations

EU procurement DPAs sometimes come loaded with obligations a Belarusian vendor can’t actually deliver as written. Notification timelines are pinned to specific local laws. Audit rights that run afoul of Belarusian confidentiality rules. Direct data-subject notification requirements that don’t match how the vendor actually operates. Sign without reading, and the problems don’t show up right away — they surface twelve months in, during an audit, when it’s too late to renegotiate. Read first, push back where it doesn’t fit, then sign. That order matters.

No documented Transfer Impact Assessment

In 2026, not having a TIA is increasingly the line item that loses the procurement check. EU clients have stopped treating it as nice-to-have paperwork — they treat it as a file they expect to see. A Belarusian vendor without one is at a specific, well-defined, and easy-to-close disadvantage. There’s no good reason to leave it open.

Engineers accessing real client data without controls

Production data on personal laptops. Database dumps shared over messaging apps. Real EU customer records were used in development environments because seed data felt like too much work. Every audit catches some version of this. The fix is technical and organizational — controlled environments, pseudonymized dev data, and real access logging.

Undisclosed sub-processors

Your cloud provider. Your email tool. Your monitoring service. Your analytics platform. Every one of them might be touching EU personal data on your behalf, and every one of them should be on a sub-processor list that your EU client has seen and approved. Sub-processors that nobody told the client about are one of the fastest ways to fail an audit — and the conversation when they’re discovered is always worse than the one you’d have had upfront.

Treating Belarusian local compliance as a substitute for GDPR mechanics

Covered earlier, but worth saying again because it’s the misunderstanding that costs the most deals. Complying with the Belarusian Personal Data Protection Law meets the requirements Belarus imposes on you. It doesn’t handle what the GDPR requires of the EU client sending data your way. SCCs, TIAs, Article 28 DPAs — none of that gets ticked off by a Belarusian compliance certificate. The two regimes run alongside each other, and you need both.

A short setup checklist

Built to be saved and forwarded internally.

Standard Contractual Clauses (2021 modular version) prepared and in place with EU clients.
Data Processing Agreement template reviewed by counsel, with non-negotiable terms identified.
Documented Transfer Impact Assessment for Belarus, available on request, refreshed annually.
EU-hosted data infrastructure as the default, where the use case permits.
Access control and audit logging with retention aligned to contract requirements.
Encryption stack documented — algorithms, key management, scope.
Pseudonymization and data minimization practices for development and testing environments.
DPO designated where required by Article 37; reachable contact details published.
Breach notification procedure documented, tested, and known to the team.
Sub-processor list maintained and disclosed to clients, with change notification mechanisms agreed.
All client-facing documentation in English, structured for procurement review rather than internal use.

FAQ

Do we need to establish an EU entity to work with EU clients?

Not strictly. EU clients can contract directly with a Belarusian vendor under SCCs and a properly documented compliance setup. In practice, the answer is more nuanced. For smaller EU clients without restrictive procurement policies, Belarus-only is workable. For tier-one enterprises with strict third-country policies, an EU subsidiary or a sub-supplier-to-EU-prime structure is often the practical route. The decision is commercial more than legal.

Is the Belarusian Personal Data Protection Law equivalent to GDPR?

The Belarusian law was modeled broadly on GDPR principles, but it has not been recognized as adequate by the European Commission. From the EU client’s perspective, Belarus remains a third country, and the standard transfer mechanics apply regardless of local compliance. Domestic compliance discharges domestic obligations. It does not substitute for the EU-side framework. The two regimes operate in parallel, and both need to be in order.

What does a Transfer Impact Assessment for Belarus actually look like?

A document — usually 8–15 pages for a typical vendor — that identifies the personal data being transferred, assesses the risks under Belarusian law and practice (including state access concerns), and documents the supplementary measures used to mitigate those risks. Encryption, pseudonymization, access controls, contractual safeguards. An honest TIA acknowledges risks; it doesn’t pretend there are none. EU compliance teams trust honest assessments more than reassuring ones.

Can we just sign the EU client’s DPA without changes?

Sometimes. The problem is that EU procurement DPAs sometimes contain obligations that don’t align with the operational realities of a Belarus-based vendor. Notification timelines tied to specific local laws. Audit rights that conflict with local confidentiality. Direct data-subject notification requirements. Read carefully before signing. Negotiating the DPA at the signing stage is normal practice and won’t cost you the deal — signing one you can’t deliver against will cost you the relationship later.

Do we need a DPO?

Article 37 of the GDPR is the place to look. It makes designation mandatory in three situations: you’re a public authority, your core business involves large-scale systematic monitoring of people, or your core business involves large-scale handling of special category data. Most Belarusian IT service vendors don’t fall into any of those buckets, so formal designation isn’t legally required. That said, plenty of EU clients expect one anyway — and naming a trained DPO with a real, reachable contact line signals you take the topic seriously, which matters in procurement regardless of what the strict legal reading says.

What about the EU AI Act — does it apply to us?

The AI Act, in force since 2024 with phased application through 2027, applies to providers and deployers of AI systems whose output is used in the EU, regardless of the provideris location. If you’re building AI features that EU clients use, you’re likely in scope for at least some obligations. The compliance work is separate from GDPR, but increasingly comes up in the same procurement conversation. Worth raising with counsel as a distinct workstream.

How does HTP residency affect our GDPR conversation?

HTP residency doesn’t change the GDPR position — Belarus is still a third country regardless. But the HTP framework supports English-language contracts, elements of English commercial law in commercial matters, and paperless contracting, all of which make the EU-facing contractual conversation smoother. Most of the Belarusian IT companies that successfully serve EU customers are HTP residents, and that’s not a coincidence.

Are we losing EU deals because of GDPR or because of sanctions?

Honestly, often both, and the two get tangled in the same procurement conversation. The formal GDPR review can be passed with the right documentation. The internal policy filter — some EU clients have written policies that exclude Belarus-based vendors regardless of GDPR documentation — is harder. If your pipeline consistently stalls at the compliance step, the structural responses (EU subsidiary, EU prime contractor relationship) may be more useful than additional documentation. Diagnose which it is before you spend on the fix.

The bottom line

EU clients raise GDPR questions for a straightforward reason: they’re the data controller, they carry the liability under EU law, and their compliance team needs documentation that supports sign-off without exposing them to risk they can’t defend later. Most Belarusian IT vendors who lose EU deals at the compliance stage do so for one of three reasons: the documentation isn’t there, the operational stack isn’t structured for external review, or the corporate setup makes the EU client’s compliance team’s job harder than it needs to be.

Most of this is solvable. SCCs and a DPA template can be put together in a quarter. A TIA written honestly takes a few weeks. The operational stack — EU hosting, access controls, encryption, pseudonymized dev data — is enterprise-standard work, well understood by HTP-resident engineering teams. The structural side is more involved and more expensive, but it’s also where the most stubborn pipeline blockages get cleared.

At Recruitment.by we work with Belarusian IT companies on the people side of all of this — building teams that can deliver on EU contracts, supporting HTP residency for vendors building the right structure, joining the HTP for those who haven’t yet, and providing HR consulting for the organizational side of compliance setup.